QA Metrics Explained: What to Track and What to Ignore

A QA metric is a number that describes either the software or the process that built it. That split does more work than any single formula. Product metrics read the code, the bug tracker, and the test suite. Process metrics read the deploy log and the incident log. A dashboard that mixes the two without saying which is which produces meetings instead of decisions.

Here are the QA metrics worth the tracking cost, the formula behind each, what a good number looks like, and the four ways a metrics program quietly starts to lie.

The two families

Product metrics answer one question: how good is the thing we built? Defect density, escape rate, and test coverage live here. They change when the code changes.

Process metrics answer a different one: how well does the system that builds it run? Change failure rate and time to restore service live here. They change when the pipeline, the review culture, or the release cadence changes.

Mixing them is what makes most QA dashboards useless. A rising defect count and a rising deploy count are not the same problem, and they do not have the same fix.

Which QA metrics are worth tracking

Eight metrics cover almost every real question a QA team gets asked. Everything else is a variation.

The last two come from DORA, whose four key metrics are deployment frequency (“how often an organization successfully releases to production”), lead time for changes (“the amount of time it takes a commit to get into production”), change failure rate (“the percentage of deployments causing a failure in production”), and time to restore service (“how long it takes an organization to recover from a failure in production”). DORA added a fifth metric, reliability, in 2021.

Defect detection percentage is the ISTQB term for the stage-by-stage view of escapes. It asks what share of the defects that a test level could have found it actually found.

A worked release scorecard

Numbers make the point faster than definitions. Take one release of a billing service.

• 18,000 lines of code, 24 confirmed defects, 6 of them reported by customers
• 2,400 automated tests, 38 of which fail intermittently on unchanged code
• 40 deploys, 6 of which needed a rollback or a hotfix

That produces:

Defect density   = 24 / 18 KLOC = 1.33 per KLOC
Escape rate      = 6 / 24       = 25%
Flaky rate       = 38 / 2400    = 1.6%
Change failure   = 6 / 40       = 15%

Read alone, a density of 1.33 says “this component needs attention.” Read next to the escape rate, it says something sharper. A quarter of the known defects reached users. Testing is not finding what it should, so the true density is higher than 1.33. The measured number is a floor.

Now add branch coverage of 61% and the picture closes. Low coverage, high escape rate, moderate density: the team is not looking hard enough, and the density number understates the problem. Try the numbers from your own release in the free Defect Density Calculator and the Test Coverage Calculator.

Three metrics disagreeing is the useful state. One metric alone can always be explained away.

What counts as a good number

For most QA metrics, no credible universal band exists. Defect counts depend on what your tracker calls a defect. Coverage depends on which flavor you measure. Both depend on how hard anyone was looking.

The two metrics on this site with published reference points have them for narrow reasons. Defect density has industry figures from decades of published studies, and they still only apply within a comparable measurement convention. Test coverage has Google’s public tiers, which are explicitly tiers rather than a target.

Even the most-cited benchmark set in the industry keeps moving. DORA’s performance clusters started as Elite, High, Medium, and Low. The 2022 report cut them to three by dropping Elite. The 2025 report, renamed State of AI-assisted Software Development, replaced the ladder with seven team profiles drawn from a survey of nearly 5,000 technology professionals.

That is not a criticism of DORA. It is the strongest available argument against copying a band out of any report. Benchmarks describe the population that was surveyed. Yours is a different population.

Compare a component against its own history. That comparison shares a defect definition, a tracker, and a counting rule on both sides, which is what makes the two numbers mean the same thing.

What DORA found about AI-assisted work

The 2024 DORA report, published on 22 October 2024, found that as AI adoption increased, delivery throughput fell an estimated 1.5% and delivery stability fell an estimated 7.2%. The 2025 report, published on 23 September 2025, found the throughput relationship had turned positive while stability stayed negative. In that survey, 90% of respondents reported using AI at work, and about 30% reported little or no trust in the code it generates.

For a QA team, the practical effect lands on the denominators. More code per week and more tests per week, with the same review capacity, moves defect density and coverage without anything about quality changing. Testing in the Age of AI covers why review effort, not authorship volume, is the thing worth counting now.

Where QA metrics mislead

A metric attached to a person stops measuring the software. This is Goodhart’s law in its most common QA form. Bugs filed per tester rewards filing trivial bugs. Defect density used to score a team rewards logging fewer defects. Both changes are invisible in the number, which keeps looking healthy while the data underneath rots.

Aggregates hide the distribution. A platform at 78% coverage might have every service at 78%. It might also have thirty services at 95% and the payment service at 20%. The aggregate cannot tell you, and the aggregate is what gets on the slide. Always break a quality metric down by component before acting on it.

Output counts are not quality. Test cases written, tests automated, and bugs closed measure activity. A team can double all three and ship worse software. If a metric would still rise during a week when nothing improved, it is measuring effort.

The denominator moves under you. Generated code, scaffolding, and AI-assisted authorship inflate line counts faster than they inflate the surface where defects live. A density figure that improves in the same release a component grew 40% is measuring the growth. Switch to story points or function points when a real share of your volume is generated.

How to run a metrics program that survives

Pick three metrics, not eight. One product metric, one process metric, one suite-health metric. Defect density, change failure rate, and flaky rate is a defensible starting set for most teams.

Write down the definition of each one, including what counts as a defect and which severities are included. Half of all metric arguments are definition arguments wearing a disguise. A short written rule, agreed once, ends them. The same discipline that makes a bug report useful makes a defect count comparable.

Measure per component and per release. Read the direction before the value. Report the trend to the team and never to a performance review.

A QA metric earns its place when it changes a decision. If nobody can name the decision a number would change, stop collecting it. The tracking cost is real, and an unused metric on a dashboard still costs the meeting time spent explaining it.

References

• Google Cloud Blog. Use Four Keys metrics like change failure rate to measure your DevOps performance
• Google Cloud Blog. Announcing the 2024 DORA report
• Google Cloud Blog. Announcing the 2025 DORA Report
• ISTQB Glossary. Defect Detection Percentage