Today, many developers I know heartily embrace agile development methods, especially scrum. Its an increasingly popular approach that directly addresses the inherent non-linearities in software development - the human parts. Some see it right away and some take a little more time but agile has clearly crossed the chasm for software developers - not so with QA people.
Most QA people I’ve worked with are pretty strange, but so are product manager, developers, architects and for Pete’s sake don’t even think about marketing folk. Now that that accusation is safely couched let me re-iterate: QA people are weird. Good QA people - not devs who can’t cut it as devs - but real honest to goodness QA people have a personality that makes them want to stop the presses, damn the torpedoes and call bullshit - regularly. They seem to enjoy it even thrive on it. So much so that it encourages the team splitting dynamic between devs and QA. I’m not sure if we’ve created these people via broken process or if we attract them but in my experience QA and agile have a hard time with each other because the episodes that give QA people their joy should NOT happen on an agile project. But to keep them from happening dev and QA need to come together on the same crass functional team.
In many ways agile leaves the QA group behind by requiring developers to add testing to their primary activities. In a perfect world this means the software produced in a given sprint should actually work as designed. Instead of the status quo where QA is the quality feedback loop for a very significant number of bugs and overall quality. Another way of looking at this is that QA is a co-enabler of bad software development process. Its clear that development is a culprit by engaging in code and fix but it does require that they have a QA group to catch the swill produced and generate the bug list. Being good at this process is like being a good crack addict. Even if you do it with style and panache its still only a matter of time before your world comes tumbling down.
Mary and Tom Poppendieck describe the Lean and how it translates from the manufacturing world to software development - a comparison I’m generally very skeptical of - but I think there are some very interesting ideas. Lean defines “waste” as “anything the customer doesn’t value” and espouses the goodness of continual waste reduction over time. From my limited understanding of it, Lean comes from the Toyota Kaizen management style. From a Lean perspective, a process that creates excessive defects (waste) is a buggy process that needs to be fixed. Imagine sending every third car that rolled off the line to the scrap heap because “bugs” were detected. This is completely unacceptable of course but its what we do in software development. In a well run lean process QA would ensure quality is within tolerences by measurement but generally not find rework. Obviously in the physical world testing must often be destructive so you can’t test everything that comes off the line. In software its not which is why I think we’ve fallen into this mode.
If you have a QA heavy culture - otherwise known as a good QA team if you are a QA person - then you are probably enabling this buggy process. An ideal situation is to have QA teams verify that the software works right and have 0 bugs to report - imagine if this were normal. Then QA could spend more time on exploratory testing and making sure the features that are built are built properly - according to customer intent.
We need to spend less human effort “shooting bugs in a barrel”, and spend more effort figuring out if our product features are really mapping to customer need - thats a take on quality that I’d love to have in the products I use.
