QA Metrics That Actually Matter: Defect Escape Rate, MTTD, and More

Defect escape rate tells you what percentage of bugs reached users instead of being caught in QA, making it the closest single number to "how well is QA working." Test coverage percentage tells you which lines of code were executed by tests, which is easy to inflate to 95% by writing assertions that never actually verify anything. This article covers five metrics worth tracking, how to calculate each one, and three popular metrics that look useful but mislead.

Metrics that matter

Defect escape rate

What it is: The percentage of bugs found by customers (in production) versus found during QA. Formula: Bugs found in production / Total bugs found × 100 Why it matters: This is the most direct measure of QA effectiveness. If you're finding 90% of bugs before release, your defect escape rate is 10%. If customers are finding half the bugs, something is wrong with your coverage. Target: Varies by product risk. Payment systems should aim for <2%. Internal tools can tolerate higher rates. Anti-pattern: A team with zero production bugs isn't necessarily doing great QA — they might be shipping very slowly, or the product is used so rarely that bugs go unreported.

Defect density

What it is: Bugs per unit of code or feature. Formula: Bugs found / Lines of code (or story points, or features) for a release Why it matters: Tracks where bugs concentrate. A module with 10x the defect density of the rest of the codebase needs attention — more test coverage, code review, or a refactor. Use it to: Identify high-risk areas to prioritize in regression. Justify investment in test coverage for specific modules.

Test pass rate over time

What it is: Percentage of tests passing in CI over time, tracked per run. Why it matters: A gradually declining pass rate is an early warning. Either the product is accumulating regressions, or the test suite is accumulating flakiness. Both need attention. Warning sign: A pass rate that's stable at 85% means 15% of tests are always failing — which means the team has normalized failure. The suite has stopped being a reliable signal.

Mean time to detect (MTTD)

What it is: Average time between when a bug is introduced and when it's detected. Why it matters: If bugs take 2 weeks to detect, they're usually found after the fix author has moved on, context is lost, and the fix is more expensive. Short MTTD means fast feedback loops. How to reduce it: Shift left — unit tests run in seconds, integration tests in minutes, E2E in CI on every PR. The earlier in the pipeline bugs are caught, the lower the MTTD.

Test execution time trend

What it is: How long your test suite takes to run, tracked over time. Why it matters: A suite that takes 45 minutes to run doesn't get run on every commit. Developers start skipping it. The feedback loop breaks. Healthy trend: Execution time should grow slowly relative to feature count. If adding 10 features doubles your suite time, your test architecture has a parallelization problem.

Metrics that look useful but aren't

Test coverage percentage

Coverage is the most tracked and least useful QA metric. A 95% line coverage number tells you which lines were executed by tests — it says nothing about whether those lines were verified correctly.

Teams game it constantly: write tests that execute code without asserting anything meaningful, and coverage goes up while actual quality goes nowhere. Use coverage as a floor ("we won't merge code below 80% coverage") not as a quality signal.

Number of test cases

"We have 10,000 test cases" is meaningless without knowing how many are automated, how many actually run, and how many are maintained. A test suite with 500 well-maintained, fast, reliable tests is more valuable than 10,000 stale manual test cases nobody runs.

Bug count closed per sprint

Closing bugs isn't the goal — preventing them is. A team closing 50 bugs a sprint might be in a terrible position (bugs are escaping fast enough to generate constant work) or a fine position (working through old technical debt). The number alone tells you nothing.

QA metrics that help with stakeholder communication

When non-technical stakeholders ask about QA, they usually want to understand risk, not methodology. Frame metrics accordingly:

Risk-oriented framing:

"We have 3 high-severity open bugs against the payment flow. We recommend delaying the mobile release until 2 are resolved."
"Defect escape rate increased from 8% to 14% this quarter — we're finding more bugs after release. The root cause is reduced regression coverage on the API layer."

Progress-oriented framing:

"E2E test suite went from 22 minutes to 9 minutes after parallelization. CI feedback on PRs is now under 10 minutes."
"Flaky test rate dropped from 15% to 3% this quarter after isolation fixes."

These are conversations, not dashboards. The metrics are in service of decisions — staffing, release timing, technical investment — not in service of themselves.

How to start tracking

You don't need a specialized QA metrics tool to start. A spreadsheet with four columns works:

|---|---|---|---|

| 2026-W20 | 18 | 3 | 34 min |

| 2026-W21 | 22 | 1 | 34 min |

| 2026-W22 | 15 | 5 | 37 min |

Trends are more actionable than single data points. After four weeks, you'll see whether production escapes are trending up or down, and whether your suite is getting slower.