Dispelling the misconceptions #4 – “Quality Assurance”… You cant assure quality!

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


6 thoughts on “Dispelling the misconceptions #4 – “Quality Assurance”… You cant assure quality!

  1. Interesting and valid point. I have worked in the past years with CMMI and ITIL. The assurance that these standards give is to use the “successful” approach (actions, tasks, activities) of a project in any project (through the implementation of specific processes).
    We all can assume that rules can guarantee some degree of success but for sure they encourage mediocrity.


    1. Hi Claudiu! Thanks for the comment, and sorry for the delay in my response.

      Does CMMI and ITIL *assure* a successful approach? For every project? Under any/every situation? It’s an interesting question.

      I’d say that “success” is an interesting word that might be closely linked with quality, or it might not be. I guess I personally would link success directly to quality, but someone else might link success to the product being shipped out on time regardless of quality, or another person might link success to the amount of money that a product makes.


      1. Hi Dan,
        I will try to answer your question….

        Usually these standards suggest a set of actions or activities that, that if carried correctly, they would ensure success. What actually success means is very difficult to establish.

        Let me give you gust one example: ITIL – Event Management. It is process that monitors all events that occur through the IT infrastructure. If you are selling software as a service this is a must. But how to monitor? What are the best approaches for the technology that you use? What is the most reliable monitoring system? These are questions that the standard cannot answer.

        These standards focus a lot on the process on what to do and not at all on how you do it.
        For instance CMMI has as one of it’s evaluation points the possibility to trace all the artifacts from the final build to the requirements. Not a bad thing, a? But form the process perspective is you have a excel or “special technology (something like JIVA+SVN)” it does not matter.

        These standards are more a “standard of actions” rather then a approach on how to do things.

        They relay on the fact that together with a improvement process (mentioned in both standards) all your process will improve in time up to the point where you can have a good predication for the final quality level. In this case success would be translated to “predictable outcome”.

        I am not a big fan of these standards but we have to take into account their history: they appeared in software development as a need of the major contractors in thous days (CMMI – US Departament of Defence and ITIL – UK Government) to provided a more predictable outcome.

        And not to come back to your question the answer would be yes, if implemented and used properly, these standards can provided a more predictable outcome for every project, under any/every situation. But this comes at a price: mediocrity.


    1. Hey Damian,

      Thanks for the link! Thats an interesting discussion from your post on LinkedIn. I agree with everything you say in the post.

      It seems to me that the software industry has been borrowing terminology from the manufacturing industry in the sense where Quality Assurance (from manufacturing) is when someone physically checks a batch of the finished manufactured items for manufacturing errors. This was essentially assuring that the batch was ok to be shipped, so the terminology makes sense in that context.

      This doesn’t work with software though, as its not a manufacturing line. We rely so much more on communication, and everyone has different perspectives and interpretations on what things (words and sentences) mean…

      An example: I was recently at the LTGWorkshops and I heard a talk about “Convincing Strategies” that gave an example: “think about a dog in a yard… What colour is the dog? And what does the yard look like?”
      Guaranteed that the dog and yard that I am imagining is completely different from your dog and yard! At the workshop, the first thing that I thought about was the dog actually being buried in the yard, so couldn’t see its colour… We all base our interpretations and thoughts on our past experiences and our understanding of things.

      This is the exact same thing when we read a requirement. there are so many different variables. so many different ways to interpret each requirement for the software. So many different ways that the software can be built, with each person on the team having different experiences influencing their opinions and decisions. Its not like a manufacturing line where an amount of physical product go through the production line in the exact same way each time, without influence from opinions or different interpretations.

      For this reason, I think its important to move away from the terminology that has been borrowed from the manufacturing industry.

      Liked by 1 person

Please leave a comment!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s