Last week I enjoyed an interesting exchange on Twitter with (among others) Jean Ann Harrison. We were responding to Ori Bendet’s article for TechBeacon entitled “6 ways QA can work better with developers”. I had some concerns about the points raised in the article and Jean clearly shared one of them; the use of the term ‘QA’.

I oppose the way in which the term ‘QA’ is applied in some quarters and I felt compelled to expand on my concerns in my blog this week….

---

In some organisations there is a misapprehension about the purpose of testing. There is sometimes a belief that through testing we are somehow guaranteeing a level of quality in a product. Testers who call themselves ‘QA Engineers’ (or similar) are reinforcing that misapprehension.

[Note that by ‘QA’ I am referring to ‘Quality Assurance’. I am aware of other roles and terms (this article for example refers to ‘Quality Analyst’ and ‘Quality Ambassador’). I don’t believe these terms are widely used.]

It is worth considering the way in which the words ‘Quality Assurance’ might be interpreted and the accountability which may be invited by referring to your role in this way.

Let us start by breaking the term down into its component parts.

Quality

What is your definition of ‘Quality’? There have been many attempts to define what quality means in the context of software development. If you believe that quality is, for example, an absence of bugs, then I would definitely recommend that you read further on the subject. In particular I recommend that you read what Gerald Weinberg has to say in Chapter 3 of ‘Perfect Software: and other illusions about testing’. If you cannot test everything, then how can you claim to have bug free software?

I haven’t encountered what I would consider a perfect definition of quality, but I have heard and read some very good ones. James Bach wrote an excellent article about quality called ‘The Quality Creation Myth’ which included an explanation of why a product is not simply code, it is “the experience the user receives”. In my opinion, the best definitions of quality consider it through the eyes of the person who will use the product.

By this, I don’t mean that quality is measured through ‘meeting requirements’. This is a mechanism sometimes used in software delivery; a way to apply a quantitative measure to quality. For example, you may hear a claim along the following lines:

‘We have a test for each requirement and each test has passed, therefore we have met requirements and have a quality product.’

I’ve been down the road of attempting to apply quantitative measures to quality and it simply doesn’t work.

What is important here is your definition of quality. If you believe that you play a role in determining the quality of a product then you need to be clear on what you believe quality is.

Assurance

The word ‘Assurance’ can be interpreted in different ways. My preferred dictionary (The Oxford Dictionary) provides the following definitions:

• A positive declaration intended to give confidence
• Certainty about something

On dictionary.com a further definition is:

• A promise or pledge

This is where the danger lies. As I discussed in my article on uncertainty a few weeks back, there is sometimes a desire for certainty in software development. We should be wary of this and cautious in our language. Providing certainty about quality or a promise of quality is not something I would feel comfortable doing.

It doesn’t really matter whether you intend the word ‘assurance’ to mean this. If you say ‘Quality Assurance’, it may be interpreted this way.

So what is ‘Quality Assurance’?

Of course, looking at the two words individually does not tell the whole story. Quality Assurance has a wider meaning defined in the Oxford Dictionary as:

• The maintenanceof a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production.

In software development, Quality Assurance is a nebulous term which covers any activity or decision which influences the quality of a product. There are many such activities and decisions involved in the product’s development.

If you are a tester you are unlikely to perform many of these activities or influence many of these decisions; you are therefore unlikely have a significant impact on the quality of a product. The people most likely to carry out activities which could be classed as Quality Assurance are managers. Michael Bolton explains this in his presentation ‘Who does Quality Assurance?’

---

Quite apart from the risks in using the term, I also object to the manner in which ‘QA’ is applied as:

• a verb – ‘I’m going to QA the website’
• a person – ‘what is the role of a QA these days?’

I am not clear on why some people who are primarily involved in testing are reluctant to call themselves ‘testers’. Perhaps the trend for applying the ‘QA’ term comes from a cultural desire within some organisations to make testers accountable for quality. After all it is then much simpler to blame the tester because ‘they touched it last’.

Whatever the reason, I urge you to stop and think next time you are about to use the term ‘QA’. Be sure that you are using it in a way that you are comfortable with.

---

 

If you are interested in the Twitter conversation which prompted this article, the link is here:

https://twitter.com/richrtesting/status/672583178486349825

Apologies if all of this took you back to 1978 and ‘The Village People’ and you are now quietly singing to yourself “Why say QA?”

What are your thoughts on the term ‘QA’? Do you consider what you do to be Quality Assurance? Let me know in the comments below.