© 2001 Elisabeth Hendrickson, www.qualitytree.com
A former Boeing aircraft engineer and I were discussing software testing one afternoon. I expressed a certain amount of frustration about how test groups are called upon to ensure quality in the software industry. In response, the engineer simply said, "No matter how hard you try, you can’t test the wings back on an airplane." Simply put, that’s the difference between testing and quality. Testing can tell you when something isn’t right, but it can’t fix what’s wrong.
When I talk with individuals, most understand the difference. Yet the common behavior of software development groups shows that some people still believe that a test group really can ensure quality. The biggest indicator that this attitude persists lies in the name given to test groups: QA, Quality Assurance. Beyond that, there is an attitude, common in many organizations, that foists blame for bad releases on QA.
"Hey, QA, what happened? How could you let a release this bad ship?!?" The QA manager is unlikely to say what he or she is actually thinking, "Hmmm. It might have had something to do with the fact that you informed us that the schedule was cast in stone so there was no time to fix the bugs we did find. Or maybe it’s because we only had a third of the amount of time to test that we were supposed to have. Oh, yeah, and there were no other steps taken earlier in the process to improve the quality of the final product."
Quality problems originate long before the testers get their hands on the product. Even in an environment where testers are involved early, testers without training in quality techniques are unlikely to lend much to a quality effort. In short, naming a group QA seems to make some people in other groups think they are officially absolved of the responsibility to promote quality practices. "That’s QA’s job." I’ve heard more than one programmer, technical writer, and project manager utter those words.
Actually, quality is everyone’s job. It begins with the requirements and ends with a solid product shipping out the door: a product that meets, exceeds, or redefines the customers needs and expectations. There’s a certain feeling in the air when a quality product goes out the door. Everyone knows that the product is good. There’s almost an audible click when the final version passes the final acceptance test. When a team ships a quality product, everyone on the team should feel proud of their accomplishments.
Yet when what should be the audible click of the last piece falling into place becomes the screech of a product being dragged into the light of day against the will of the project team, don’t blame QA. Don’t blame each other. Don’t blame management. Don’t blame the process. Fix it. Fix the process, fix the problems, learn from mistakes, and don’t make the same mistake twice. The software market runs on Internet time, and is unlikely to tolerate two disastrous releases. Airplanes without wings cannot fly; neither can software without quality. And quality is everyone’s responsibility, not just QA’s.