What does Quality mean for you?

“Quality is our number 1 priority “

“I want a perfect Quality”

“Quality is non-negotiable”

All right, I got it, we will do our best to deliver on your expectation, boss…

But what is expected precisely? Not sure this is very clear actually…

What does Quality mean?

Let’s look at a formal definition of Quality:

“a high level of value or excellence”.

OK, now, what does high level mean? And what about excellence?

You got it, Quality is far from being a very factual thing. It represents a concept, a vision, but can hardly be given a unique, precise definition.

In the software industry, Quality will be associated to defects, or anomalies. And you would usually define defect severities and priorities in order to classify them and decide which ones are acceptable or not.

Obviously this will be different according to the context, taking into account security, amount of money engaged, or reputation impact.

Nobody is expecting a bug to be unfixed in an aircraft navigation system, although you will have experienced tons of defects with your favorite social networking tool (at least I have!)…

All of this means that prior to defining any vision or priority about Quality, you have to properly define what Quality means for you.

And then, once you have delivered your product, you will need to be able to cross check if the expected Quality was there when you thought it was.

The most important view of Quality for a software product is the perceived Quality, that I would also call the experienced Quality. What is really important is what your customers, the people who need the product, will consider being the Quality of the product.

There could be thousands of issues existing in your product. If the users do not experience those in real usage conditions, they will be totally acceptable.

For instance, if clicking 10 times on the same button within a second makes your invoicing product crash, this will never be experienced, hence you shouldn’t care.

And this should be your only focus. The defect that is solely experienced by the CEO of the company but could not be by a paying customer doesn’t actually need to be fixed.

Unfortunately, it is often times just after you have made a decision according to the Quality you thought you had achieved, that you will be able to realize if this view was right or wrong. Avoiding such situation will be the purpose of Beta phases, user acceptance, or user workshops.

The role of a QA team is to ensure the view they give is as close as possible to the perceived Quality, and to continuously work on limiting the gap between the Quality they measure and the Quality that is experienced.

A good QA team will not have found millions of issues, it will not have missed customer reported ones…

This is what Quality means for me…