Skip to content

The real cost of escaped defects and how to measure QA ROI

Every bug your users find costs more than one your testers find. Here is a practical model for pricing escaped defects and proving QA ROI with your own data.

Three professionals reviewing printed charts in a meeting
Photo: Vitaly Gariev on Unsplash

Every bug your users find costs more than one your testers find, yet most teams cannot say how much more. Escaped defects show up as support tickets, refunds, hotfixes and quiet churn, scattered across budgets nobody adds up. This guide gives you a practical model for pricing escaped defects with your own data, the metrics to track, and a way to show QA ROI that finance will accept.

Key takeaways

  • Escaped defects carry five cost buckets: engineering rework, support, lost revenue, release disruption and trust damage.
  • Track defect escape rate and defect containment per release and per severity, not as one blended number.
  • Price escaped defects with your own data: hourly rates, ticket costs, conversion and order values.
  • QA ROI equals avoided escape cost minus testing cost, divided by testing cost.
  • Feed every escaped defect back into your test suite and device matrix, so the same class of bug never escapes twice.

What escaped defects are and why they cost more

An escaped defect is any bug that reaches production and is discovered by users, support agents or monitoring rather than by your testing. It is the clearest signal of what your QA process missed. However, its cost is rarely tracked in one place.

Escaped defects cost more for structural reasons, not mysterious ones. First, the developer who wrote the code has moved on, so they need time to reload context. Second, a production fix needs a full release: build, review, store submission and rollout. Third, real users were harmed in the meantime, so you pay in support time, refunds and trust. As a result, the same one-line fix can cost a few minutes before merge and several days after launch.

Mobile apps make this worse. Store review adds delay, and users do not all update quickly. Therefore, a bug in a mobile release can live on devices for weeks after you ship the fix.

Man looking puzzled at his smartphone
Man looking puzzled at his smartphone. Photo: sayan Nath on Unsplash

The five cost buckets of escaped defects

To price escaped defects, break the cost into buckets you can measure. Each bucket maps to data you probably already have.

  1. Engineering rework. Hours to reproduce, diagnose, fix, review, test and release the patch. Include the context switch away from planned work.
  2. Support load. Tickets, chats and calls caused by the bug, multiplied by your average cost per contact.
  3. Lost revenue. Abandoned checkouts, failed renewals, refunds and chargebacks during the bug’s lifetime.
  4. Release disruption. Delayed features, emergency release coordination, and store review time for hotfixes.
  5. Trust damage. Rating drops, negative reviews, churned accounts and, in regulated sectors, compliance exposure.

The first four are measurable with internal data. The fifth is harder. However, you can approximate it with churn or rating changes in the weeks after a major incident. In addition, be conservative: a model finance believes is worth more than a dramatic one they dismiss.

How to calculate the cost of escaped defects: a worked example

Here is an illustrative example for a mid-sized ecommerce app. The numbers are made up for the example, so replace them with your own. Suppose a bug causes Google Pay to fail silently for users on Android 13 devices with a specific bank app, and it stays live for four days.

Cost bucket How to estimate Illustrative value
Engineering rework 3 engineers x 10 hours x loaded hourly rate 30 engineering hours
Support load 420 tickets x average cost per contact 420 contacts
Lost revenue Affected sessions x conversion rate x average order value About 1,100 lost orders
Release disruption Planned sprint work delayed by hotfix 2 days of a squad’s roadmap
Trust damage Rating change, reviews mentioning payment failure Rating dip for two weeks

Convert each row into currency using your own rates and order values. Then add them up. For most teams, lost revenue dominates for checkout bugs, while engineering and support dominate for bugs in account or settings flows.

Now compare. If a real-device test pass on Android payments would have caught this bug before release, the avoided cost is the full total. That single comparison often justifies a quarter of testing on its own.

Metrics for tracking escaped defects over time

One expensive incident gets attention. A trend changes budgets. Therefore, track a small set of metrics every release.

Defect escape rate

Divide production-found defects by total defects found for the release, before and after launch. For example, if testing found 45 bugs and users found 5, your escape rate is 5 out of 50, or 10%. Track it by severity, because 5 minor escaped defects and 5 critical ones are very different releases.

Defect containment by stage

Record where each bug was caught: code review, automation, manual or crowd testing, beta or production. As a result, you see which stage is pulling its weight and which is leaking.

Time to detect and time to fix

Measure hours from release to first report, and from report to fix in users’ hands. Long detection times often mean weak monitoring or a user segment you do not test, such as a market or device tier.

Production stability signals

Crash-free sessions, ANR rates and app store ratings are lagging indicators of escaped defects. Google’s Android vitals documentation explains how crash and ANR rates affect visibility on Google Play, which turns stability into a growth issue too.

Building a QA ROI model leadership will trust

QA ROI uses the same logic as any investment. You compare what testing costs with what it saves. The formula is simple:

QA ROI = (avoided cost of escaped defects – cost of testing) / cost of testing

The hard part is “avoided cost,” because those bugs never happened. Here is a defensible way to estimate it:

  1. List the bugs testing caught for a quarter, with severity and affected flow.
  2. Assign each a cost-if-escaped using your five buckets and your own rates. Use historical incidents of similar severity as anchors.
  3. Apply a probability discount. Not every caught bug would have hit every user. For example, weight a crash on one rare device lower than a checkout failure on a common one.
  4. Sum the avoided cost and compare it with the full cost of testing, including internal time to manage it.
  5. Report a range, not a point. Show conservative and expected cases, so the model stays credible.

In addition, show the trend. If critical escaped defects dropped from six per quarter to one after you added real-device and payment coverage, that story is more persuasive than any formula.

How to reduce escaped defects in practice

Measurement is only useful if it changes your process. Every escaped defect should trigger a short, blameless review with three questions: why did it escape, which test or environment would have caught it, and what will you add?

Most escaped defects cluster into a few patterns:

  • Environment gaps: the bug only appears on a device, OS version, carrier or locale you never tested. Fix it by widening your device matrix with real-usage data.
  • Real-world payments: sandbox success hides failures on live rails such as UPI, Pix, iDEAL or Apple Pay. Fix it with real-rail testing in target markets.
  • Untested journeys: each screen works, but a sequence such as “edit cart after applying a coupon” breaks. Fix it with exploratory charters.
  • Regression blind spots: an old feature breaks because nobody re-tested it. Fix it by adding the case to your suite. Our regression testing strategy guide explains how to rank them.
  • Noisy reporting: the bug was reported but buried among duplicates. Fix it with a triage gate that reproduces and deduplicates.

TestGate targets these gaps directly. Vetted testers cover real devices, carriers and payment rails in 120+ countries, and every report is reproduced and deduplicated before it reaches Jira, Linear or Azure DevOps. You can explore localization and payments testing or exploratory testing to close the most common escape paths.

Common mistakes when measuring QA ROI

A QA ROI model is only as strong as its weakest assumption. Finance teams spot inflated numbers quickly, and one bad assumption can discredit the whole report. Avoid these traps.

  • Counting bugs, not impact. Fifty cosmetic bugs are worth less than one broken checkout. Weight every bug by severity and affected flow before you add anything up.
  • Assuming every caught bug would hit every user. A crash on a rare tablet model affects a small slice of your base. Therefore, scale the avoided cost by the share of users on that device, OS or market.
  • Ignoring internal cost. Testing is never free, even when a partner runs it. Include the hours your team spends writing scope, reviewing reports and retesting fixes.
  • Measuring once. A single quarter can be noisy because one big launch skews everything. Instead, report rolling four-quarter trends.
  • Leaving out speed. Faster feedback has value too. For example, if triaged results arrive in two days instead of a week, your release train moves faster and features earn revenue sooner.

In addition, agree on the model with finance before you present results. When they help pick the inputs, such as the loaded hourly rate or the average order value, they are far more likely to trust the output. As a result, the conversation shifts from “is this number real?” to “where should we invest next?”

Finally, keep a simple log of every major incident with its estimated cost. Over a year, that log becomes your most convincing evidence, because it is built entirely from your own history.

Reporting escaped defects to leadership

Executives do not need bug lists. They need a one-page view that connects quality to business outcomes. A quarterly quality report should include:

  • Escaped defects by severity, with the trend over four quarters.
  • The top three escaped defects, each with estimated cost and the fix to the process.
  • Defect containment by stage, showing where testing investment pays off.
  • QA ROI as a conservative and expected range.
  • One clear ask, such as adding a market to the test matrix before a launch.

Keep the tone factual. Consequently, quality becomes a business conversation about risk and return, rather than a debate about headcount.

Frequently asked questions

What are escaped defects?

Escaped defects are bugs that reach production and are found by users, support or monitoring instead of by your testing process. They are the most direct measure of what your QA missed.

How do I calculate defect escape rate?

Divide the number of defects found in production by the total defects found for that release, both before and after launch, then multiply by 100. Track it per release and per severity so one minor bug does not hide a critical trend.

How do I measure QA ROI?

Estimate the cost of the defects your testing caught as if they had escaped, subtract the cost of the testing itself, and divide by the testing cost. Use your own support, engineering and revenue data rather than generic industry multipliers.

What is a good defect escape rate?

There is no universal target, because it depends on product risk and release cadence. Focus on the trend for critical and major escaped defects, and aim for zero critical escapes on revenue and trust flows.

Cut escaped defects with TestGate

Close the device, network and payment gaps that let bugs reach your users, with triaged results in days: talk to us.

#defect escape rate #escaped defects #qa roi #qa strategy #quality metrics

Ship your next release with proof from the field.

Vetted testers on real devices, carriers and payment rails in 120+ countries. Every bug triaged before it reaches you.

Book a live demo