Blurring the Line Between QA & Dev Session 3: The Bugs We Don't Fix

I recently attended an OpenSpace event organized by the Software Association of Oregon (SAO). The event talked about a variety of topics teams encounter while developing in an Agile environment. Here are my notes from the third session, The Bugs We Don't Fix, hosted by Merlyn Albert-Speyer.
Initially I thought this discussion was going to be an enumeration of those annoying types of bugs that slip through testing, are reported by customers, and are eventually stored in the huge Indian Jones-like bug warehouse. We started with a short list of bugs that are reported, but ignored:

• Management says the bug is too low priority, and so the development team should ignore it
• The team simply has no time allocated to fix it, so it’s left un-done.
• Bugs that aren’t reported to development. (It’s another discussion to talk about why this happens)
• Someone said “one man's bug is another man's feature.”
• There was a case given where fixing the bug in a graphics engine caused the surrounding system to blow up. The system developers had built the system to accommodate the bug – fixing it caused more problems than leaving it.
• One person cited Joe Yoder’s anti-pattern “the big ball of mud.” Software that’s such a mess it’s too risky to tinker with it.

So, ultimately the bugs not fixed are a business value proposition, right? If there’s a bug then deal with it during refactoring, or other maintenance work.
Then Andrea Callison and Tom Pearson of phTech announced that they don’t have a bug database.
They work off a system that is honest with the users. If the development team simply can’t get the bug fix into the product, or won’t be able to release a patch to fix the bug, they return that bug to the user with an explanation why. They claim that users accept the explanation, appreciate it even. At least the development team has been honest in explaining why the bug won’t be addressed. After the bug is returned to the user (or user representative?) it’s the responsibility of the user to submit the new story to the development team for the next version of the software. As they say "anything that matters will come back" into the new product.
They also have some other interesting ideas

• MMF - minimal marketable feature
• Stories have a warranty period. They'll fix it for free if it's still in warranty (which I’m assuming means within the past couple of sprints)

Andrea said that James Shore, who was attending the SAO event, was the Agile coach for PHTech and helped with their implementation of Agile.
So, they are in effect saying that once the product has been released, it’s a blank slate. Any new changes will be submitted as new user stories to the development team. They only mentioned in passing that James Shore also has a method for reducing bugs during the sprint – a “no bugs” mentality.
This topic inspired some ScrumMasters who are hoping to get out from under the dead weight of the bug database. Still, while it’s not 100% Agile, my feeling is that the bug database is a useful reference. Additionally some people wondered whether multiple ongoing small projects handled in this manner will eventually lead to a degradation of the product? No one had clear data on this question.
In any case, dropping the bug database is a mind-blowing idea which I’ll have to investigate further.

Related articles

• Blurring the Line Between QA & Dev Session1: History of Blur (mxmossman.blogspot.com)
• Facebook Makes Change in Size of Embedded Flash Players Official (insidefacebook.com)

Blurring the Line Between QA & Dev Session1: History of Blur

Image via Wikipedia

I recently attended an OpenSpace event organized by the Software Association of Oregon (SAO).  The event talked about a variety of topics teams encounter while developing in an Agile environment. Here are my notes from the first session, History of Blur, hosted by Jon Bach & Ward Cunningham

Inspired by the theme of the event, the discussion talked about how to blur the divisions between QA and development.  Jon raised a question why are companies hiring developers as testers, when his opinion is that the key QA skill is how to think.  He also compared Dev and QA to someone writing email. When you’re writing you’re a developer, but the QA person wants to edit. Sometimes there’s not enough time for QA, and you hit ‘Reply All’ a little too quickly…

Jon’s background is from journalism and he likens QA (Quality Assistance – since he can’t assure quality, only help with it) to a reporter seeking the truth – interviewing, questioning, organizing & reporting.

Ward wondered whether Agile has done “damage” to QA?  He explained that Agile has “lifted” development making them more effective, but hasn’t done much for QA.  Still, by helping the developers become more effective, that means the “dumb bugs” are mostly out of the system, freeing QA for a higher level of testing.

The discussion was sort of rambling, but a basic topic was that developers have one set of mental attributes:  creating, introspective, a desire to solve problems while working to a plan.  QA have another: breaking (or, more accurately, finding the existing defects), extroverted, announcing problems right and left.  The antagonism occurs as the tester scores points by finding bugs in the developers’ code.  A key QA people skill is how to relate this info to the developer tactfully?  Also, pair programming is one way that developers can temporarily step into the QA shoes.

In my opinion, the antagonism between developers (creating) and QA (breaking) is fundamental and useful sometimes, but there needs to be a way to turn it off and on. When it’s “off” the team is pushing in the same direction, when it’s “on” they will be testing the software to its fullest.  It’s also important to note that team roles <> job titles <> individuals.  One person mentioned that "Working together is a matter of professional (pride)."

Sidebars included:

• Useful mnemonic for test strategy: SFDPOT (Structure, Function, Data, Platform, Operations, Time)
• An idea of the checks & balances of scrum – the triangle of scrum – Product Owner, Dev, QA
• A discussion of how everyone in the team thinks they’re the user’s champion. As Ward put it, it’s a competition to own the role of the customer.”
• A particular antipattern – the lack of Slack in an Agile environment.

The discussion concluded with a question: What’s the future of blur?  Ward posited that all roles (QA, Dev, Tech Writers, Support, Sales, etc) will have to work more closely together. “Each important problem is on someone's boundary.”