Challenged by Michael Bolton, Brian Marick wrote a blog entry about a famous quotation from Jerry Weinberg:

Quality is value to some person.

Marick called his entry “Quality is value to some person” restated. In his entry he describes quality without even using the name quality.

After having read Marick’s piece, the only thing I see is that this whole discussion is pointless. How does the discussion about what quality is lead to better software? How does the discussion lead to better testing? How does it lead to better management of the projects around us?

There is one precise point underlying the discussion, that Jerry also mentions in his Quality Software Management series, and that – to me – Brian seems also to agree to. Quality means different things to different persons, and that means that quality as a term is ambiguous.

It didn’t take me four years of working as a tester to realize this. Recalling the past few years, whenever I was asked what the quality of the software is, I was puzzled about what to answer. Maybe “42” is the right answer there. And of course, every problem in the software is a quality problem. For infinite times I ran into troubles, because the quality I thought was relevant did not match the quality for the next person to complain.

That said, since quality may mean different things, we have to find out what quality to care about. But how do we do this? The first person to approach with this question is the stakeholder, the one who asked us to do quality related work for him. He may say something like “Quality to me means that the customer will be happy with the software.” or “Quality to me means that I can get money with the product for the next decade.” Helping ourselves understand what quality we ultimately should care about is part of what Cem Kaner calls finding out the mission of our testing. For this we need to work closely together with our stakeholders and try to find out what our mission for the current project or task at hand is, and how we can help assist in quality related aspects of the software.

Such a mission may be to test the product for risky bugs. Another mission may be to evaluate a product, and help to decide whether we may ship it. This may mean that we evaluate a tool for future use. Just like a dressmaker works together with you to get the dress you would like to wear, we need to work together with our stakeholders to help us understand how we can add value to the product in our unique manner.

That’s what a professional tester does. And it’s still a thing I’m working on to excel at.