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 its living in.

Of course, this makes quality very hard to pin down and digest. 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 but it doesn’t always tell the whole story. It’s like looking through binoculars, it’s only part of the picture. I find it’s a combination of metrics, stories and context and that x-factor that we haven’t realised provides a better view.

At a practical level, I like to frame the quality story in terms of business outcomes. In my simple language, 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 can’t stress how important to work this stuff out, both the explicit and the unspoken.

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. (Hint — build a relationship with a person first before you get onto this topic….).

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.

Anne-Marie Charrett

Written by

Software Testing Coach & Trainer