Testing is NOT responsible for quality!
The value of testing is important and critical to the success of many projects. However, testing is NOT solely responsible for the quality of a project!
When we discuss the role of testing and quality in our internal training we emphasize the primary objectives of the tester as providing information and assessing (preferably via quantifiable measurements) quality (and specifically focusing on the quality traits or attributes that are most crtical to the success of the project).
But, there are still some managers who would like to believe that the testing group within an organization is responsible for quality. And there are even some testers who will tell you they are responsible for quality. I won't begin to speculate how this folktale came to be, or why it is perpetuated. But, it is a folktale (any belief or story passed on traditionally, esp. one considered to be false or based on superstition). Folktales usually persist in societies for a variety of reasons. There is no doubt that quality is important. But, quality is hard to define; quality is hard to measure, and it is hard to translate quality into value for the customer. There is no doubt that as a tester I can influence the quality; however, responsibility implies the ability to also control. How much control does a typical testing organization in a commercial software company actually have upon the quality of a project?
There are 3 simple tests to refute the conjecture that testing is responsible for quality.
- Can we test in quality?
- Can testing find all the defects?
- Will all the defects be fixed? (Here a defect implies deviation from explicit or implicit requirements or expectations, or unexpected behavior.)
The answer to these three questions is no! Unless you are an absolute novice to software engineering you will probably agree we cannot test in quality. Testing cannot find all the defects in any complex software project (and there is ample evidence of this). And anyone who has any experience on a project of significant size will admit that not all defects are fixed (including functional defects). So, as a tester I know I can't test in quality, I will never find all the defects, and I know that some of the defects I find will not get fixed (because I can't use electric cattle prods on developers and I am not going to go into the code and fix the bug myself), so how in the world can I be responsible for the quality of a product?
As a tester I am responsible for providing information regarding the percieved quality and/or risk of a project as assessed by a series of tests, observations, and experiments, and that information is provided to managment (who hopefully use it) to determine whether a commercial software product is released to the public.
So, who is ultimately responsible for the quality of a product? Often times folks will rally around the "everyone is responsible for quality" mantra. But, W. Mark Manduke wrote an nice article in STQE magazine a few years ago stating "When quality is declared to be everyone's responsibilty, no one is truly designated to be resonsible for it, and quality issues fade into the chaos of the crisis du jour." He concluded "...when management truly commits to a quality culture, everyone will, indeed, be responsible for quality."
Thus, ultimately the management team (the decision makers) is responsible and accountable for quality.