Many people think Quality Assurance (QA) is only testing. This surprises me, after working many years as Quality Manager to prevent defects and improve products.
Apparently I’m not the only one who is surprised, and I’m very happy that Tom and Kai Gilb formulated the Real QA Manifesto.
To quote them:
We know how to do real QA much much better than testing alone, using smarter upstream engineering practices, based on design, prevention and upstream inspections.
There is lot’s of evidence that many defects can be found much earlier and cheaper then by testing alone, e.g. by doing reviews. And that by focusing on the root causes, people can learn from defects and prevent that similar mistakes are made in the future. This fits perfectly with Lean and Six Sigma, by preventing that defects are made and thus reducing lead time and waste.
I have implemented techniques like review and root cause analysis for several customers, it’s a small investment which pays back quickly. I am one of the first subscribers to the Real QA Manifesto (here’s a snapshot of the page with my signature). As an adviser I am able and willing to help management to achieve the Real QA Manifesto elements.
One thing still surprises me: Given all the evidence that defect prevention really pays off, and the fact that most engineers like to do Reviews and Root Cause Analysis once they understand how to do it and get benefits out of it, why doesn’t management promote and support Real QA more often?
Note: Post updated on August 29, 2017, links corrected to the manifesto. The original publication on the Gilb website is gone, but there’s an archived page with signatories :-).
..”why doesn’t management promote and support Real QA more often?”
I think because sometimes management does not “speak the same language” as engineers do, and some sort of disconnection exists between them.
Real QA brings hard to quantify advantages, and it is hard to sell it from a business perspective. It is hard to justify the added effort to management when you can not come with some numbers, and at the same time one can not have correct numbers until work is started in this direction. This makes a vicious circle that is hard to get out of.
Thanks Lucian!
I recognize the disconnection between management and engineers. In fact, in some of the improvements that I worked on my primary contribution was to get them to see how quality contributed to the bottom line, and to realize both short term and long term win-win opportunities.
You can use industry data to build a first business case. I’m currently reading The Economics of Software Quality by Capers Jones, this book provides a lot of data. I also published data on the business benefits of software review.
But I agree with you, you have to collect and analyze your own data to steer improvements. There are ways to get out of the vicious circle more quickly, e.g. the two step business case process that is decribed in my technical report for the SEI.
Ben Linders