Selling Quality

After giving a talk about testing to developers, someone in the audience asked: how do you sell testing and quality to the business? How do you get them to realise those are important?

Those questions stopped me right in my tracks.

In a sense, you never have to sell the concept of quality to anyone. I can’t think of anyone who would say ‘no’ if you ask them if they care about quality. And in a way, software development is a test: software is merely a vessel to validate whether a business concept will be of value to the customers. What I’m describing here is not new at all; it’s the lean startup cycle, basically.

So, what is the problem, then? I have identified a couple of options of where things might go astray when it comes to selling testing and quality:

• the ownership of the business goal is no longer clear. The organisation is so big that for some middle manager, the goal is no longer clear and they just wants to micro-manage the developers working for them; “Get this done asap”, and quality and testing are not important. They don’t see the need. Testing and (technical) quality only endanger their KPI’s.
• shallow understanding of the term “quality”. What I think is “quality” will probably differ from your perception, but if we never talk about that and agree on a baseline, then what?
• some companies don’t measure what the users actually do with the application so how can they make a quality experience for their users? Guessing?
• some managers fully go with their own assumptions and they think testing of assumptions isn’t needed (dictator-style leadership), just “test that the written requirements work” and nothing more.
• testing is a phase, instead of an activity that’s a normal part of the development cycle, and there might be little communication between developers and testers (let alone shared ownership).
• some people think testing is (or should be) done by 1 person, instead of being an integrated part of everybody’s role (everybody is a tester)
• all testing can be automated, so the project relies on boolean outcomes. That testing is an umbrella term that can do more than just validate specific scenarios is not known.
• ….. etc ….[insert your horror story here].

Whatever may be the case in a given context, usually the discussion is not about quality or testing, but rather about symptoms and problems that are being identified. Testing is expensive and it’s hard to pinpoint what “Return On Investment” it brings (*barf*), to speak in management-terms. In a way, I’m never surprised that companies would like to cut back on it. Testing cannot find every piece of information you want it to find, but it is an easy blame-target when things go wrong.

So, no, you don’t want to sell testing to your business. You want to sell the generic benefits of identifying the most important problems and finding ways of solving them before your users do. Testing is one of the myriad ways you have to validate if you are on the right track of solving problems. Measuring is another one.

The ‘selling quality’ thing is harder because “quality” is not definable. You know when it isn’t there, but what makes quality happen is neigh impossible to describe. The more you try to define and describe it, the further you get removed from the essence (as the author of Zen and the Art of Motorcycle Maintenance has tried).

Don’t despair though, because there are other options. What you can do is frame a discussion around quality aspects. You avoid talking directly about the abstract term “quality”. Instead, you take the mission and goals of your company (or team) and map quality aspects onto them so you can center discussions about quality around it. For example, when you are making a web application the usability aspect is often very important. Cool, you can have a discussion about how you want to make sure that the usability is going to be of good quality for your users and how you are going to test for that.

Talking about abstract concepts like testing and quality is nice for awhile, but if you want to go to a more practical domain you have to cut it down into smaller pieces. Make it relatable for other people. Give examples, explain what you mean. It usually helps to get other people on board!

Good luck in selling quality and testing to your business, it’s okay to start small.