Testing is NOT Quality Assurance!

07 Jul

Testing is not Quality Assurance.

Time after time we see testing referred to as Quality Assurance – indeed I read an article lately that said that the ISTQB definition of testing is essentially quality assurance (IEEE Software July/August 2009 – Reach for Standards, Good Ones by B. Meyer). I find this fascinating as it is one of the key issues that Testers have to address. As far as I am concerned Quality Assurance is a whole of a lifecycle approach. QA is about providing the tools, techniques, training and time to everyone in the SDLC that enables them to do the best job they can. QA is about implementing process and methodologies that allow us to fulfil our roles as best we can. The Business Analyst should have the training that allows them to complete the requirements elicitation and verification to the best of their abilities. The Project Managers should have the tools and the time available for them to facilitate the delivery of the project to the highest standard. The Developers should have the training, tools and environment that enables them to provide the best quality code, and the Testers should have the tools, training, time and techniques available to allow them to test the system to the best of their ability.


QA is the overarching process that applies to everyone. Testing is NOT Quality Assurance. Testing is making sure the system works – does what it is meant to do – and does not do what it is not meant to do (functional). Testing also allows us to assess how well the system works (non-functional). Testing is Quality Assessment! Testers can only “report” on the quality of the system, they cannot “assure” the quality of the system. It is the role of everyone in the SDLC to assure the quality.

Posted by Sharon Robson


Posted by on July 7, 2009 in Testing


10 responses to “Testing is NOT Quality Assurance!

  1. jwpegasus

    July 7, 2009 at 12:51 pm

    Couln’t agree more Sharon. Testing is definitely not QA. Is Testing more about Quality Control? In the earlier iterations of a project perhaps we can argue the focus is more on validation than on verification. As the project progresses we focus more on verification than validation

    • Sharon Robson

      July 7, 2009 at 1:10 pm

      Well – that is a BIG question. Control is about changing direction and making decisions based on knowledge. I have found that it is not often that Testers have the ability to implement quality “control”. I know from experience that a lot of projects don’t engage the test team early enough to allow any Quality “Control” to be applied. If we have early testing such as review of requirements (not just READING of requirements) then testing can assist in Quality Control by finding and feeding back defects in the requirements such as ambiguity or incomplete coverage of quality. If testing is allocated to the last 2 weeks of the project with the aim of finding defects, there is not much room or time for “control” in the Quality :-). It comes down to what the stakeholders want testing to do. Usually they want testing to do Quality Assurance or Quality Control but don’t allow the test team to do anything like that.

  2. jwpegasus

    July 7, 2009 at 1:20 pm

    A big question indeed. You are so right Sharon. To truly get Quality Control we need to apply at least the V model, preferably the W model. isn’t this why it is so important to differentiate between validation and verification? Oh yes please! early and continuous requirement validation and verification could give us so much more control over delivery of a fit-for-purpose product. Rush-to-code with tardy testing will never do that. BUT what about test-first agile?

  3. Brian Osman

    July 8, 2009 at 9:43 am

    Having testing being referred to as QA really annoys me because it assumes and implies that testing is now responsible for ALL quality aspects of the product! It implies (well to me anyway) that the rest of the project team, organisation have no part to play in contributing to quality – they ‘do it’, testers assure it and of course when it goes pear shape the fingers point in one direction!

    • John Watson

      July 9, 2009 at 10:10 am

      So right. No-one ever tested quality into a product.

  4. Sharon Robson

    July 9, 2009 at 9:50 am

    I think that is a very important point Brian, we really need to understand the role of the tester and the role of everyone else in the project in the quest for Quality! Sometimes it can be challenging for people to understand that testers can only find quality, or the lack there of, instead of “putting in in”.

  5. Sharon Robson

    July 9, 2009 at 9:54 am

    I don’t think that the lifecycle, such as V model or Waterfall enhances or inhibits quality control. I think that it is a lack of understanding about what testing can do. I believe that skilled practitioners in all disciplines within the lifecycle will assist in quality. Leaving quality to the testers and assigning them a timeframe at the end of the process inhibits any opportunity for testers to contribute early and ideally “prevent” defects. Agile approaches allow testers earlier involvement with this preventative approach. Test first development done with both testers and developers is a huge opportunity for quality to be built into the product.

  6. John Watson

    July 9, 2009 at 10:05 am

    Dead right! lifecycles by themselves do nothing. It is the disciplined and trained people using the lifecycles that make the difference. Sharon, I’m not sure if you misunderstood my use of the term “W model”. The W is definitely not W for waterfall. It is the model that encourages early and continuous involvement of those filling the tester role in validation and verification of the emerging requirements on at least an iteration by iteration but preferably a build by build basis.

  7. Sharon Robson

    July 10, 2009 at 9:09 am

    Hi John, yup – understood W model reference. As you said, lifecycles do nothing without the people. Verification and Validation is very important – not only of the requirements, but of the design and of the code ultimately.

  8. Frank Qu

    June 28, 2010 at 12:38 pm

    What a thorough and profound discussion! It reminds me of a time when I first learnt “Quality Control” concept from a well-known Japanese enterprise to enhance microchip yield rate that requires every foundry line workers to be part of the process or no control at all on “quality”. It’s the principle “participation by all or none”.

    Today’s software systems become bigger, more sophisticated and further ubiquitous across entire business and life spectrum, from mission critical to household. The number of components and units interacting with each other within and among systems has caught up in the magnitude to the number of transistor gates in a microchip not mentioning more complicated in design and logical patterns, which, in most case, mimics human brain. The same principle should stand. Everyone who are involved in SDLC should be considered as potential loophole source and need to be recruited in Quality Assurance process.

    In reality, I think, few decision makers in tech management and even PMs in project level know this very piece of history and understand why Japanese products got into worldwide market so successfully in the last century and why NASA’s space programs have noticeably been stand out with very few failures.


Leave a Reply

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

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

Google photo

You are commenting using your Google 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

%d bloggers like this: