Quality is a journey - but do you know your destination?

After any decent exposure to software testing, Jerry Weinberg’s definition of quality tends to gain traction and respect. That is  “Quality is value to some person”.  You like it because of its subjectivity. You may also hate it because of its subjectivity.

Remember that bug report you raised only to discover that others had a different view point? Forget about having a fixed mindset to quality. What was ‘quality’ yesterday is no longer ‘quality today’. Quality morphs and moulds itself to the context it's living in. In reality, we never will achieve quality. Quality is too fast for us and horribly intangible to be able to emphatically state “we have quality”. But we can go on a journey to improved quality, and we can monitor how we are progressing.

A common question I get asked is “how do we know we have quality?”.  Metrics are something that many reach for to understand this answer. It’s understandable go to, but metrics don’t always tell the whole story. Using metrics is like looking through binoculars, it’s only part of the picture. You need a combination of metrics, stories and context and a time machine to get the full picture. (I’m guessing that you need a time machine, I haven’t tested that). Metrics can give you some indication of where you are at, but it doesn’t always tell you if you are going in the right direction.

I like to frame the quality story in terms of business outcomes. Business outcomes are goals that your business wants to achieve. For example, it could be the ability to respond rapidly to market demand, it could be reduced cost or maybe its increased sales. I use these business outcomes to help me focus my work . What small step can I take next, that will help my get closer to the desired business outcome? Like a compass it helps direct me on where to go next.  This compass becomes especially useful with increased uncertainty. When companies grow and expand, when products are experimental, uncertainty thrives and out comes my handy compass.

Here’s a team based roadmap on moving towards the quality you want:

So step 1: work out your companies business outcomes. Ask people what they are being measured on, or what their teams are being measured on.

Step 2: Think about (in terms of your context) what might threaten those outcomes. For testers, it could be that your test environments prevent you from testing early in the development lifecycle. Or perhaps there’s waste in your automation in testing. Let’s call these opportunities for improvement.

Step 3: Get buy-in. In my experience, you get buy-in by doing things people are interested in. And, it’s likely the more senior the person, the more emphasis you want to place on that interest. Buy-in is important. It gives you legitimacy. You get buy in by linking the business outcome the the opportunities you have in mind.

Step 4: Start working on reducing those threats, one small step at a time. It’s not going to happen immediately, so prepare people to think long term. Also, think about how you might do small experiments that people are keen to know answers on. Analyse and refactor.  The goal is not to achieve the objective but to demonstrate how you are moving to the objective.

Step 5: Don’t forget those business outcomes, they are your destination, not the experiments themselves. Speak in terms of those outcomes. Do it repeatedly. Preferably by visualising progress.

Step 6: Be pleasant, have fun and treat others with respect.

[This post has been written iteratively and has some minor changes made to it since the initial release ]