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.”