In almost any field you can imagine, there has been a concerted effort to improve quality by proactively managing the process and systematically eliminating the errors that one would otherwise encounter again and again. I say almost, because even though there is no rocket science behind these techniques, most software organizations still don’t get it, and continue to waste gobs of money and work with massive risks.
The one indicator that strikes me as an ongoing reminder of this dysfunction is the job postings for quality assurance roles. In the vast majority of these roles, what is being sought is someone with competency in testing. Whether it is automation, test design or good old-fashioned random pounding on the keyboard, it all is centered around taking what is deemed as the product – the executable product – and either confirming that it works (bad) or beating it up to find out where it doesn’t work (better).
If we make a distinction between assurance and control (and we should), then all of these activities, even the test design and automation, are acts of quality control rather than assurance. The intent for these activities is to work out the kinks before we ship (or unfortunately too often, to confirm that the customer has worked out the kinks for us by reproducing their reported problems) rather than working out the kinks before we build.
Assurance is all about working out the kinks before we build, and that is where we really reap the benefits.
More and better testing (or quality control) will almost always find more defects, and that is a good thing. The reason this quality control will find more defects, unfortunately, is that by the time we are at this stage of our product development, we’ve already injected the vast majority of those defects, and we have been building on many of these flawed assumptions since day one.
We can easily improve our performance if we work to remove these defects as soon as we inject them, to avoid building on top of these flaws. If we recognize that many defects we inject are actually defects because we failed to do something (rather than did something that was incorrect), we can see how better and earlier focus on understanding the problem domain and the solution architecture are cost savings, not overhead activities.
Assurance is the practice of understand where we can best improve our performance. It is an oversight activity that proactively designs the way we will build our products to minimize costs, and builds feedback loops into the system that allow us to continue to get better over time. Building up your true assurance capabilities is guaranteed to result in a cost and risk savings for your projects, not an expense. It is a strategic function that might include focus on refining how to beat up on the code, but certainly is not limited to that area.
The approaches of Six Sigma and Lean are bringing the appropriate perspective of assurance into the software field, but the progress is slow, and most software teams persist in confusing assurance with testing. Until the majority of teams recognize that the approach to software development needs to be crafted rather than dogmatically followed, I expect we will continue to see most QA job postings focused on attacking the end product, which is merely quality control. – JB