Quality Equals Profit – Understanding Quality Helps Us Test

A coworker sent me an email about a conversation he had with one of our executives about risk and how quality played into her decision making:

“She [the executive] was giving me some insight…

As we were discussing the balance of quality policies (as we experienced them in the beta program) and balancing them against expediency she mentioned that quality equals profits. Ultimately this is because quality means a greater degree of predictability, and that greater certainty influences commercial policy to take risk out of competitive pricing, which means more deals won, and also means revenue won’t be eroded by fixing product issues once deployed (and the negative marketing spin they can create).”

How fascinating! This executive thinks quality is about predictability and reducing the risk of selling! I’ve worked at a few large companies where teams of programmers, analysts, testers, support people, professional services and others are brought together from various functional areas for a particular project. I’ve also worked at small startups where I sit next to all my engineers and in each case, regardless of the organization size the testing process mostly works the same way.

As things are scoped (through planning or building), the information that flows out from the project help us testers start to understand the product under test, how much we’ll have to test (scope), what our requirements are (both written and not), who makes up the team, et. al. But it’s been my experience with all these processes going on we end up forgetting or missing the important thing for understanding our project:

Our mission as understood by our stakeholders! For testers this mission will come in the form of an information objective (or multiple objectives). Our information objective is very important because it dictates the problem or problems we are trying to solve for our customers and/or stakeholders (who I’ll refer to now on collectively as stakeholders). To make matters more complex it changes with each project even if we’re working on the same product or with the same team.

To help understand our testing objectives and our overall mission we should be asking what do our customers expect from this project? Just because some written requirement states something is supposed to work one way, does that mean our stakeholders really want it? Would they in fact accept something else that addresses their problem in a slightly different way? Matt Heusser uses the term “desirements” instead of requirements because when you really understand your stakeholders you realize they are willing to make changes if they meet the end goal.

As we begin to understand our testing objectives we then need to understand from those same stakeholders what quality means to them. If you are like me, you’ve probably worked on many teams and/or projects where the assumption was “whatever I deem to be quality is quality”.  For example, in the quote at the beginning it sounds like this executive is interested in quality as it relates to controlling costs and reducing risks (at least the risk of spending more money to fix things later). This could lead to more questions like what information do they need (information objective) that would help them make better decisions about controlling costs and/or spending more money to fix problems later? Is it possible that testing can help uncover this information?

Perhaps by understanding what problems (or types of problems) exist in the system now we can make fixing problems in the future more predictable.

If this was the consensus across our stakeholders and/or if this stakeholder was the stakeholder that mattered this information objective would drive our mission and our test strategy. If this wasn’t the stakeholder who matter but was just one, we’d also want to know what the other stakeholders think was important. What is quality to them? What information do they need from testing?

Quality is subjective and we should expect to get a different answer from each of your stakeholders but that’s ok. Knowing what quality is, what each group of stakeholders expects and to whom certain things are important can lead to a better understanding of the priorities of the test efforts. At the very least it will influence how bugs are fixed.

Influence how bugs are fixed? Yes. Let me give you an example.

Say we have a stakeholder who thinks quality means the branding of the system (logos, trademarks, text with the company name) conforms to the latest design guidelines and we know this because we asked their group what quality meant and what information they needed to see to sign off on the release. If we (the testers) file a bug that says something like “logo isn’t the appropriate size as in design guidelines” its entirely possible a programmer would consider this low priority and skip it. If this stakeholder is important to the project team we can cite who would be affected and the impact of NOT fixing the bug. Again assuming the importance of the stakeholder this might be enough evidence to the programmer to rate this bug a higher priority.

The opposite could also be said. By knowing what our stakeholders expect from the testing mission we can also identify biases certain groups will have.

Going back to the example in the beginning if we know our executive thinks quality is profit and wants testing to provide information to help control costs, we know they may be unlikely to get behind fixes or features that directly benefit another stakeholder if they don’t fall into this category. It doesn’t matter how beneficial to that other stakeholder or group of stakeholders, so we may need to provide additional information in bugs or change requests to address that bias.

It comes down to: The more I know about my stakeholders the greater effect it will have on my mission and my testing objectives and eventually it will make it easier to appeal and influence the person making the decision about whether to fix a bug or implement a change.

Testing is often too large of a task to just randomly go through the testing process without thinking about or trying to understand the underlying mission and objectives of testing, instead it requires sampling. Asking what quality means to your stakeholders is one way to sample. Language influences the way we think about and deal with problems.

It may sound odd, as testers, to equate quality to profits (maybe you think quality is reputation, credibility, no UI bugs, no Easter eggs, etc.) but if we don’t ask these basic questions we may misunderstand our testing mission.

However if we do ask questions like who are the people that matter, what do they think quality is and what do they need to understand from testing, then we end up dealing with the right problems for the right people.

These days I make it a point to understand my stakeholders and talk directly to them, even the obvious ones I might be sitting next to because so much of what I do is effected by the information they give to me. I ask them what quality means and what information is important for them to understand which leads me to develop my information objectives, my mission and eventually my test strategy.

This article was originally published in the December 2013 edition of Testing Circus Magazine. It has been updated and reposted because it highlights an important concept I was grappling with in 2013 which, in 2019 is that customers are the only ones capable of judging and evaluating the quality of our product. Enjoy!