QA. Huh? What? Who?
I suppose you've heard about QA. The term has been around longer than 24 years, probably at least as long as the ISO9000 standard first published in 1987.
The two most common definitions of the abbreviation are probably:
- Quality Assurance
- Quality Analyst
OK. They seem two quite different things. Assurance versus Analysis. One gives a positive declaration of confidence, a promise even; the other is an examination of something.
There is a third, Quality Assistance, which crops up in this Michael Bolton article. - but I’ve rarely heard this used in the wild.
So Quality Assurance gives the thumbs up to quality and Quality Analysts examine quality. OK. Lets dig a little deeper. Are they the same roles, do they actually do different things?
The quality assurance role is an often thankless position that is designed to find bugs before they find their way to the end customers and the QA team is known by their less flattering name of testers.
Less flattering name for Testers. Hmm. Something to mull on. Perception noted.
tl:dr: QA (and I’m guessing here, the A stands for Analyst), can wear many hats and provides feedback on areas to improve.
Two quite different definitions for the term ‘QA’. Which one do you think of when hearing ‘Lets hand it to QA’? Or as used in an interview I was conducting recently, the 'QA function'!
Of course. You think of testers. Or the test team. In general or common usage, this abominable abbreviation is a replacement for the title of tester for the majority of people.
This a part of the problem with using abbreviations. A lack of shared models of understanding creates confusion if you are not explicit. Either way, neither definition is an adequate representation of a tester. In fact, I would go so far as to say that the term ‘QA role’ is a non-sequitur. When everyone is responsible for quality we are all quality analysts and we can all give positive declarations of confidence. Whether those declarations are correct or not is something else.
If you are going to use the term to describe testers. Don’t. QA, whether that be assurance or analysis does not describe testing.
As a Developer you are in some way responsible for quality. Be it by writing unit tests, performing code reviews or adhering to coding standards.
As a Scrum Master you are in some way responsible for quality. Be it removing blockages so that development can continue, organising the team to be a well oiled and effective machine or simply keeping the JIRA board in an accurate state.
As a Product Owner you are in some way responsible for quality. Be it providing quick and accurate feedback, quick and accurate answers to questions from the development team or simply being available.
As a Tester, you are in some way responsible for quality. Be it providing unambiguous bug reports, informing relevant stakeholders of possible problems to enable them to make decisions or any number of other things.
Can you ‘assure’ quality as a Tester? Don’t be silly.
Eh? But what is Quality then?
I like this part of the dictionary definition of quality: the degree of excellence of something.
As a Developer you can write excellent code. More excellent than before because you have other people performing excellent reviews of your code, enabling you to improve the quality of your code.
As a Scrum Master you can organise and communicate excellently. You can do this more excellently than before as the fun and engaging retrospectives you organised revealed improvements to be made.
As a Product Owner you can provide excellent acceptance criteria. More excellent than before as you now have time to do so and you are being aided and abetted by your other two amigos.
As a Tester you can find excellent information to provide to all stakeholders. More excellent than before because you have identified excellent problems previously that have now been solved, enabling you to be faster and better.
As a team you can be excellent to each other!
Quality is doing something well and improving upon it. Adjusting, measuring, analysing, experimenting etc, to enable the contributors to the process the best chance of delivering fantastic output.
You can give assurances you are doing these things well through regular communication. In software development, that isn't a specific role, because the person in that role would need to be everywhere, all the time.
So what about testing?
Photo courtesy of INTVGene | Flickr | Some rights reserved.
I personally think this is the best definition of testing currently available.
Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.
A Tester is a generalist. They have a broad knowledge base, different models and different viewpoints. They may be able to perform an alternative singular job competently, but they may never be the virtuoso that others are. They can provide valuable input to those areas where they do have knowledge.
A rose by any other name would smell as sweet
But a Tester by any other name, may smell as sweet, but they wouldn't be a Tester
Testing and Testers shouldn’t be dirty words. Testers need to stand up, be confident and proud of their craft. Please stop using the term QA to represent what Testers do. They do so much more.