QA, Testing... what's the difference?
Submitted by Antony Marcano on Thu, 23/09/2004 - 21:22.
general software testing | project management | test management
[textile]I believe that much of our time is wasted by using inconsistent terminology... I also believe that we sometimes put "ticks in boxes" for a (false) sense of security... so what has this got to do with QA, Testing and so-called "QA Testing"?
I summarised this today as follows:
* Quality Assurance - Prevention of faults by inspecting & testing the process
* Quality Control - Detection of faults by inspecting & testing the product
If you are in Software Testing, you probably spend most of your time testing products (the software, documents etc) - i.e. Quality Control... how many of you are testing the process?... Just because you're a software tester, are you qualified to test the process?
How do you Inspect and Test the Process...
You might inspect the process by auditing what people are doing and ensure they are within guidelines, frameworks or following your (agile) processes... also, making sure that, when cutting corners, the benefits and the risks have been considered... You might test the process by, for example, error seeding to see how effective the testing (Quality Control) processes are.
How do you Inspect and Test the Product(s)...
As you generate artifacts through the SDLC, these can be inspected (e.g. on the fly as in Pair Programming) and/or tested (e.g. with automated acceptance tests)...
The term "Quality Control" comes from more mature industries that would discard a product or correct its faults (if possible) if it fails certain tests... it isn't really "Control" because all it does is provide information... it is the information that facilitates decision making - hence providing controls... In some industries, these decisions are more easily determined from the outcome of tests... we all know that this isn't always so clear with software...
So how did this happen?
How has the term "QA Testing" come about if the two activities of "QA" and "Software Testing" are clearly not the same? Here is my theory...
Some people refer to Software Testing as QA because a lot of other people do - so why not? It doesn't really matter does it? As long as we all know what we are talking about... If this is done concsiously and all participants are clear that they aren't doing a complete QA job (just by testing) - then that is actually OK IMHO.
Others, however, use the term "QA" synonymously with "Software Testing" because they may not know any better (see my remarks about Phil Crosby's Quality and S-E-X analogy).
Most people would agree that, in building anything, QA is a good thing (as in managing the delivery of appropriate quality and risk - not enforcing dogmatic processes)...
So, we all want a tick in the "I am doing QA" box... Many do this by saying "QA" instead of "Software Testing" - remember Software Testing is one aspect of "Quality Control" in the SDLC... perhaps because we don't know any better? Perhaps our experience is that testing is what QA is all about?...
Then there was "QA Testing"
It seems that the term "QA Testing" was born from those who knew no better, referring to teams performing non-developer testing as "QA Teams"... so as to distinguish between developer-testing and (errmm...) Tester-Testing? Perhaps because in some (or even many) organisations, the "QA Testers" were former users rather than software engineers... This in itself, I believe, came about again - through assumptions made about testing... by the manager who "has a play" with the application and thinks that this is all there is to testing because that is his/her experience... again see my remarks about Phil Crosby's Quality and S-E-X analogy - I am considering referring to the enlightened tester as "Tantric Testers" :-)
My Conclusion
Unfortunately, all of these assumptions that people make, based on limited experience, seems to have resulted in many people putting a tick in the "I am doing QA" box when in fact they aren't really doing QA...
I believe in accepting realities... If I am not doing something I could be doing to improve the quality of my work - then there is usually a good reason for it!
I won't sweep it under the carpet though... I will be honest and open about what I am not doing and why... but I will never put my head in the sand and pretend that there aren't risks... if we know the risks, we are forewarned... if we are forewarned, we are forearmed... in my experience, that makes for a more successful software development project.
JMHO!
I summarised this today as follows:
* Quality Assurance - Prevention of faults by inspecting & testing the process
* Quality Control - Detection of faults by inspecting & testing the product
If you are in Software Testing, you probably spend most of your time testing products (the software, documents etc) - i.e. Quality Control... how many of you are testing the process?... Just because you're a software tester, are you qualified to test the process?
How do you Inspect and Test the Process...
You might inspect the process by auditing what people are doing and ensure they are within guidelines, frameworks or following your (agile) processes... also, making sure that, when cutting corners, the benefits and the risks have been considered... You might test the process by, for example, error seeding to see how effective the testing (Quality Control) processes are.
How do you Inspect and Test the Product(s)...
As you generate artifacts through the SDLC, these can be inspected (e.g. on the fly as in Pair Programming) and/or tested (e.g. with automated acceptance tests)...
The term "Quality Control" comes from more mature industries that would discard a product or correct its faults (if possible) if it fails certain tests... it isn't really "Control" because all it does is provide information... it is the information that facilitates decision making - hence providing controls... In some industries, these decisions are more easily determined from the outcome of tests... we all know that this isn't always so clear with software...
So how did this happen?
How has the term "QA Testing" come about if the two activities of "QA" and "Software Testing" are clearly not the same? Here is my theory...
Some people refer to Software Testing as QA because a lot of other people do - so why not? It doesn't really matter does it? As long as we all know what we are talking about... If this is done concsiously and all participants are clear that they aren't doing a complete QA job (just by testing) - then that is actually OK IMHO.
Others, however, use the term "QA" synonymously with "Software Testing" because they may not know any better (see my remarks about Phil Crosby's Quality and S-E-X analogy).
Most people would agree that, in building anything, QA is a good thing (as in managing the delivery of appropriate quality and risk - not enforcing dogmatic processes)...
So, we all want a tick in the "I am doing QA" box... Many do this by saying "QA" instead of "Software Testing" - remember Software Testing is one aspect of "Quality Control" in the SDLC... perhaps because we don't know any better? Perhaps our experience is that testing is what QA is all about?...
Then there was "QA Testing"
It seems that the term "QA Testing" was born from those who knew no better, referring to teams performing non-developer testing as "QA Teams"... so as to distinguish between developer-testing and (errmm...) Tester-Testing? Perhaps because in some (or even many) organisations, the "QA Testers" were former users rather than software engineers... This in itself, I believe, came about again - through assumptions made about testing... by the manager who "has a play" with the application and thinks that this is all there is to testing because that is his/her experience... again see my remarks about Phil Crosby's Quality and S-E-X analogy - I am considering referring to the enlightened tester as "Tantric Testers" :-)
My Conclusion
Unfortunately, all of these assumptions that people make, based on limited experience, seems to have resulted in many people putting a tick in the "I am doing QA" box when in fact they aren't really doing QA...
I believe in accepting realities... If I am not doing something I could be doing to improve the quality of my work - then there is usually a good reason for it!
I won't sweep it under the carpet though... I will be honest and open about what I am not doing and why... but I will never put my head in the sand and pretend that there aren't risks... if we know the risks, we are forewarned... if we are forewarned, we are forearmed... in my experience, that makes for a more successful software development project.
JMHO!
