You can’t assure quality… In fact, I’d even go as far as to say that testing itself doesn’t actually improve quality, let alone assure it.
Testing provides information which allows for the improvement of quality only if acted upon by the stakeholders, and then worked on by developers, but testers themselves don’t actually do the work physically to improve the quality.
Testers might contribute to quality by investigating the software to discover information about bugs, problems, possible improvements, risk, etc. We contribute by providing that information to the stakeholders who then decide whether they want to do something about the things that we discover and if so then the programmers/coders work on new code to enhance and fix the software and then we investigate it more.
But in no way can we assure quality. The definition of “assure” is: “to make sure or certain”.
Can we ever be certain that there is no bugs in our software? No.
With modern complex software, with thousands of lines of code that interact with thousands more lines of code, we don’t have enough time to test every single combination and scenario. That’s why we should take a risk based approach to testing within the time frame and context that we are given. But even with less complex software, we can’t be completely sure that there are no bugs or problems (in the sense that its exactly what the customer wants and needs).
Can we be certain that every stakeholder is going to be completely happy with using any software? No.
Everyone has different perspectives, wants and needs. And these change on a regular basis. My favourite colour today is blue and right now I am listening to the Foo Fighters because I really want to listen to their album today. Tomorrow, I might prefer the colour green and might want to listen to Ludovico Einaudi’s music…
So even if we strive for perfection (which in itself is impossible), what that means to us today might differ tomorrow.
Don’t get me wrong, I am not saying that you shouldn’t have a focus on quality. I think it’s essential to put quality at the forefront of your software. Your software needs to be valuable for your stakeholders. I’m purely talking about getting rid of silly terminology that harbours false beliefs and misconceptions. Pick a better word instead of “assurance”, such as “confidence”. Then again “QC” (for quality confidence) might get misunderstood as “Quality Control” :S