Testing as an information service

Testing can control quality, but cannot assure it. Quality Assurance, as we know, is much more than just applying tests on the projects – its about choosing, customizing and applying a methodology that is best suited to the project considering  the project scope, complexity, technical risks and many other parameters involved. When we do QA, we think processes.

We associate testing with quality control – but when we do testing, are we really empowered to “control” the quality? After we report bugs, is it in our control to get them fixed? My experience states that the answer is “No”. Even when we do testing, we are not really contolling the quality – we are just reporting the state of application. This belief of mine found a strong support when I read similar views by Elisabeth Hendrickson who thinks of testing as an information service. Here is the snippet from her post Questions and Answers – 

” My new insight was the classic: Testing can tell us about the absence of quality, but cannot ensure it.  I still think that’s true, but that insight doesn’t guide what or how I should test.  It fails to inspire me.  It’s accurate, but not helpful.

My next realization was that Testing is an information service.  Testers provide information that decision makers can use to mitigate risk and make better decisions about software projects.  This insight explains why testers should not be the gatekeepers.  We provide information, not judgment.  We identify and explain risks.  We act as advisors.  We don’t make the news, we report it.  And we shouldn’t ever accept the role of quality police.”

She hits the point when she states,

I now see testing as an information service that answers questions for project stakeholders.  Or, bumper-sticker style: Project stakeholders have questions; testers have answers.

Excellent!