How to Sell QA to Higher-Ups

Full Circle

We’ve come full circle (maybe once again?) with Quality Assurance being looked at as a cost center rather than a cost saver.

As much as I talk about automation, I’m still a tester at heart. The art and skill of taking software, and coming up with creative ways to find defects, is crucial for any company to be successful.

It can be difficult to convince the higher-ups of the need for QA. I mean, we know it, because we eat, sleep and breathe the stuff.

But to someone on the outside looking in, it can appear like a money hole, especially if you’re regularly shipping good product.

One thing I’ve found is that higher-ups love numbers and metrics. So today, I’d like to share some insights on how to use that to your advantage, so that you have the knowledge needed to convince people of the need for good QA.

The Tangibles

The best way to argue for QA is to start putting dollar values on bugs. This value should represent the financial impact of the company if that bug reached production.

Some bugs (like cosmetic errors) won’t be worth as much. Some bugs (such as security holes) will be worth possibly billions of dollars.

Some bugs (such as not billing $10 per customer) will be worth more, the more people are exposed to it.

Some bugs will be worth a lot if a bunch of people (or whole departments) have to stop what they’re doing to resolve an issue.

Some bugs will be worth a lot if it’s due to some kind of non-compliance issue.

But every bug will result in one or more people being diverted from other revenue-generating work, to fix this bug.

A combination of these and similar variables will give you a dollar value for the bug.

And then compare that number to how much is being spent yearly on the QA team.

You might have noticed that I didn’t include the cost of QA finding the bug, and the cost of developers fixing the bug. Even if we said: 1 QA finds 1 bug, and 1 dev takes 1 day to fix it, that’s tiny compared to how much it costs to fix a bug that makes it to production.


The Intangibles

The tangibles above probably got you some big numbers already. But let’s talk about a different thing now: the intangibles. These are going to be based on things like company perception, both internal and external.

How much will it cost in bad publicity if a bug makes it to production?

How much does it cost in talent attraction? Are people going to want to come work for you if it looks like you don’t have it together?

How much does it cost in talent retention? Are people leaving because constantly reacting to problems caused by defects is creating a lot of stress?

How much does it cost in data loss or hacking? Are hackers selling sensitive information to the highest bidder and causing your company to look untrustworthy?

Are people overworking and getting sick more often and not able to come in?

Are you having to hire more customer service reps to handle the flood of disgruntled customers?

It can be difficult to calculate the dollar value of these intangibles. But if you can, then compare that number to how much is being spent on the QA team.

Side Effects

If you’re a tester reading this, you may be seeing that finding the bugs that impact the customers the most, will result in the highest savings. A side effect of this article might be that you adjust your strategy for testing.

(And right now, security is the biggest thing that causes problems in software. It’s rare to hear about defects that make the news, that don’t have to do with security.)

Here are some tips on testing for high-value bugs. What parts of the system…

  • …are involved the most with generating revenue?
  • …are used by the most users?
  • …have a higher history of bugs?
  • …have a high degree of complexity?



If this seems like a huge unsolvable problem, just take courage in the fact that being successful requires great software as the cornerstone of your company. If you have that, everything else will fall into place. Great QA is the key to having that.



5 thoughts on “How to Sell QA to Higher-Ups

  1. It’s a question of “talking in the language of management”, which most often is money. You need to talk about “hard” dollar vs. “soft” dollar impacts. Hard dollar impacts are revenue related; new sales and renewals, cost to fix the defect (in-cycle before release and full cycle again after release). You have to look at each phase and determine when the defect was found and when it was fixed. The longer the time in-between the more costly. You need to convince them that testing early and often is more cost effective, meaning lower cost overall. They need to be shown that it is both a short-term and long-term view regarding testing. The Soft dollar impacts are reputation and revenue related, and can have significant impact to the hard dollar ones. Users are fickle, they don’t like buggy software and will quickly switch to a competitor. They also talk, and word of mouth can be a killer to a product. Increased support calls add to the hard dollar impacts, and pissed off customers can lead to a lot of talk that will ruin a product and companies reputation. These all lead to loss of revenue. Show your management this type of information and they will wake up, and if not it may be time to leave. Finally, you also need to “Sell” testing to other groups as well in order to get them to help. Talk in their languages as well and how testing (or lack of) impacts them too. Remember the ABC of selling, Always Be Closing.


  2. A friend sold software quality like this: after each upgrade of a website, there were typically 150-300 error reports. This team had no written requirements, formal tests–anything. So the proposal: let’s try writing requirements, then verifying that we at least tests to cover all requirements before next release. If it improves the process, we keep doing it. If not, we drop it.” The leaders bought it. So, next release they followed the plan. The result: 3 reported errors. Management didn’t believe the difference was due to the change in process, until the second release produced the same outcome. They became believers.


  3. I’m in the process of building out a QA team for custom professional services projects. QA here is done on the R&D level, but there has been limited time spent testing custom modules that come out of the services team. Quality has been enough of an issue that my boss convinced his boss they needed a QA team in services.

    I was hired in January.

    It’s like pulling teeth trying to get the PMs to add enough QA time to these projects to cover the amount of time we need to test. Their MO is customers do’t want to pay for it. I have been suggesting they bake my estimates into development time.

    Anyway… Right now I’m working on some metrics that show bugs reported in the last non-QA’d releases versus the current releases that are being QA’d. I’m hoping that this shows the value of the team as we move forward building the process.


    1. Welp: if they don’t want to pay to have it done right, they should be prepared to pay to have it done over 😉

      The metrics approach is definitely the right idea. Presenting what you know in a way that everyone can understand will give you the leverage you need, to get the resources you’re looking for.

      Best of luck in assembling your team!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s