Guide To The Top 20 QA Metrics That Matter

Software teams are releasing faster while managing growing testing demands. According to the 2026 Sembi Software Quality Pulse Report, 43% of teams release new code weekly or more frequently, while 61% report moderate to dramatic increases in QA demand due to AI-generated code.

QA metrics help teams understand whether their testing keeps pace with that change. The right measurements can reveal coverage gaps, slow defect resolution, unstable tests, execution bottlenecks, and areas of elevated release risk.

However, no single metric can determine whether a QA team or product is performing well. Test counts, pass rates, and defect totals only become useful when they are interpreted alongside product risk, change scope, test type, and trends over time.

This guide covers 20 QA metrics that can help teams evaluate testing progress, quality outcomes, efficiency, and release readiness.

The takeaway in 30 seconds

• Select metrics based on the question your team needs to answer, such as whether a release is ready or where testing is becoming less reliable.
• QA metrics should support decisions, not simply produce larger dashboards.
• Use a mix of outcome, coverage, execution, reliability, cost, and flow metrics.
• Raw counts need context. Finding 20 defects may be good or bad depending on their severity, the scope tested, and when they were discovered.
• Trends across comparable releases are generally more useful than isolated measurements.
• Avoid using one metric, such as test count or defects found, as an individual productivity score.

Raw counts vs. calculated QA metrics

The original distinction between “quantitative” and “qualitative” metrics is misleading because counts, percentages, rates, ratios, costs, and averages are all quantitative measurements.

A more useful distinction is between raw counts and calculated metrics.

Raw counts provide the underlying data. Calculated metrics make that data easier to compare across releases, teams, or time periods. Qualitative evidence adds the context needed to interpret both.

For example, the number of escaped defects is useful, but severity, customer impact, affected functionality, and release size determine what that number means. A team should therefore combine metrics rather than treating any single measurement as a complete assessment of quality.

Top 20 Essential QA Metrics

1. Escaped defects

An escaped defect is a defect discovered after the testing stage that was expected to catch it. Production escapes are especially important because they can affect customers, generate support work, and require emergency remediation.

Track escaped defects by severity and customer impact rather than relying only on the total. One critical production defect may represent more risk than several minor visual issues.

Teams can monitor the raw number of escaped defects or calculate a production escape rate:

Production escape rate = Production defects ÷ (Pre-release defects + Production defects) × 100

Define which releases, defect types, and time periods are included before comparing results. A release with more functionality or users may naturally produce more reported defects than a smaller release.

Review each significant escape to determine:

• Which test level should have detected it
• Whether the affected requirement or risk had adequate coverage
• Why the existing tests did not expose it
• What test, process, or monitoring change could prevent a similar escape

The goal is not to claim that every release will be defect-free. It is to reduce the frequency and impact of defects that reach customers. For additional guidance, see how to improve bug reporting.

2. Test coverage

Test coverage measures how much of a defined set of coverage items has been exercised by testing. The coverage items might be requirements, risks, user journeys, platforms, configurations, or code structures.

“Test coverage” should therefore always identify what is being covered.

Common coverage measurements include:

• Requirements coverage: The percentage of in-scope requirements exercised by completed tests
• Risk coverage: The percentage of identified product risks addressed by completed tests
• Platform coverage: The percentage of supported browsers, devices, or operating systems tested
• Code coverage: The percentage of specified code structures, such as statements or branches, exercised by automated tests

For requirements coverage, use:

Requirements coverage = Requirements exercised by completed tests ÷ Total in-scope requirements × 100

A requirement with a test case linked to it is not necessarily tested. Teams should distinguish between requirements that have tests designed and requirements whose tests have actually been executed.

Coverage also does not prove that the tests are effective. A suite can report high coverage while missing important edge cases, weak assertions, or critical user workflows. Combine coverage with defect outcomes, test reliability, and risk analysis. See how to improve automation test coverage for more guidance.

3. Defects per requirement

Defects per requirement helps teams identify requirements or functional areas associated with unusually high numbers of confirmed defects.

An average can be calculated as:

Defects per requirement = Confirmed defects linked to tested requirements ÷ Total requirements tested

Teams can also group defects by individual requirement to identify potential hotspots. If one requirement produces substantially more defects than comparable requirements, investigate whether it is:

• Ambiguous or incomplete
• More complex than originally estimated
• Frequently changing
• Poorly understood by the implementation team
• Missing important acceptance criteria or test scenarios

Avoid assuming that a requirement with more defects is automatically lower quality. Larger or higher-risk requirements may receive more testing and therefore produce more findings. Compare requirements of similar size and complexity, and account for defect severity and test depth.

This metric is most useful for prioritizing additional review and testing—not evaluating individual developers or testers.

4. Test effort

Test effort measures the time and resources required to plan, design, maintain, execute, and review testing.

Instead of treating the number of tests created or executed as a productivity score, track effort by activity:

• Test planning and risk analysis
• Manual test design
• Automation development
• Test data and environment preparation
• Test execution
• Failure investigation and defect triage
• Test maintenance

To compare actual effort with the plan, use:

Test effort variance = (Actual test effort − Planned test effort) ÷ Planned test effort × 100

A positive result means testing required more effort than planned, while a negative result means it required less.

Review the reason for the difference. Higher effort may reflect unexpected product complexity, unstable environments, changing requirements, or extensive failure investigation. Lower effort may indicate increased efficiency, but it can also signal reduced scope or incomplete testing.

Use test-effort trends to improve planning and identify recurring sources of unplanned work. Avoid comparing teams based solely on tests completed per hour because test complexity varies considerably.

5. Test reliability

Test reliability measures whether a test produces a consistent and accurate result under equivalent conditions.

A reliable test:

• Passes when the expected behavior works
• Fails when the expected behavior does not work
• Produces repeatable results when relevant inputs remain unchanged
• Provides enough diagnostic information to investigate a failure

Useful indicators include:

Flaky-test rate = Tests with inconsistent outcomes ÷ Tests evaluated for flakiness × 100

False-failure rate = Failures caused by test or environment issues ÷ Total test failures × 100

Track the first failure as well as the final retry result. If a test fails initially and passes on rerun, reporting only the pass can make the suite appear more reliable than it is.

When reliability declines, investigate timing assumptions, shared state, unstable dependencies, test data, environment differences, and parallel execution. See the guide to identifying and fixing flaky tests for a detailed troubleshooting process.

6. Time to test

Time to test measures how long testing activities take. Because test creation, execution, and failure analysis are different types of work, track them separately.

Useful measurements include:

• Test design time: Time spent creating and reviewing test cases
• Automation development time: Time spent building and maintaining automated tests
• Execution time: Time required to complete a test run
• Time to feedback: Time between a code change or pipeline trigger and an actionable test result
• Failure-analysis time: Time required to determine whether a failure represents a product defect, test defect, or environment problem

An average can be calculated as:

Average test execution time = Total execution time ÷ Tests executed

However, averages can hide unusually slow tests. For large automated suites, median duration and 90th- or 95th-percentile duration can provide a clearer picture.

Compare equivalent test types rather than combining manual and automated execution into one number. Automated tests may execute faster, while exploratory and usability tests require human judgment and should not be evaluated by the same benchmark.

Reducing testing time is valuable only when coverage, reliability, and defect detection remain acceptable.

7. Test cost

Test cost is the total amount spent planning, preparing, executing, maintaining, and reporting on testing.

Depending on the organization, it may include:

• Tester and developer labor
• Test management and automation software
• CI infrastructure and cloud usage
• Test environments, devices, and data
• External testing services
• Training and onboarding
• Automated test maintenance
• Failure investigation and defect verification

Track both the planned testing budget and the actual cost:

Test budget variance = (Actual test cost − Planned test cost) ÷ Planned test cost × 100

A positive result means testing exceeded its planned budget. A negative result means it cost less than planned.

Cost can also be allocated by release, requirement, test type, or product area. These comparisons are most useful when the work is similar. Testing a high-risk payment workflow will naturally cost more than testing a small visual change.

Use test cost alongside escaped defects, coverage, and cycle time. A lower cost is not an improvement if it results from reducing important testing.

8. Cost per defect fix

Cost per defect fix estimates the average resources required to investigate, correct, verify, and deploy resolved defects.

A basic formula is:

Cost per defect fix = Total defect-remediation cost ÷ Number of defects resolved

The remediation cost may include:

• Reproduction and root-cause analysis
• Development time
• Code review
• Regression testing
• Environment and infrastructure usage
• Deployment or hotfix work
• Customer support and incident-response time

Segment the results by defect severity and discovery stage. A minor defect found during development should not be averaged with a critical production incident because the work and business impact differ significantly.

This metric is most valuable as a trend. If the cost of resolving similar defects increases over time, investigate whether the causes include system complexity, weak diagnostics, slow environments, or inadequate regression coverage.

9. Cost of insufficient testing

The cost of insufficient testing estimates the losses associated with defects that testing did not detect or that the team knowingly accepted before release.

Potential costs include:

• Production incident investigation and remediation
• Emergency releases and rollback work
• Downtime or interrupted transactions
• Customer support volume
• Refunds, service credits, or lost revenue
• Regulatory or contractual penalties
• Customer churn and reputational damage

A simple incident-level estimate is:

Estimated failure cost = Remediation + Incident response + Support + Downtime + Direct business losses

This is an estimate, not a precise calculation. Customer trust, lost opportunities, and reputational damage can be difficult to quantify. Testing also cannot prevent every production failure, so avoid attributing the entire cost of an incident to the QA team.

Use this metric to compare the cost of prevention and earlier detection with the cost of failures—not to suggest that more testing is always the answer.

10. Test execution status

Test execution status shows the current results of the tests included in a run, plan, sprint, or release.

Common statuses include:

• Passed
• Failed
• Blocked
• In progress
• Not run
• Retest
• Skipped

Report both counts and percentages, and define which statuses your organization considers complete.

For example:

Test completion rate = Tests with completed results ÷ Total tests planned × 100

Test pass rate = Passed tests ÷ Tests completed × 100

The denominator matters. Calculating pass rate against all planned tests produces a different result from calculating it against completed tests.

Execution status should not be treated as a standalone measure of release quality. A high pass rate may coexist with untested critical requirements, weak coverage, or unresolved high-severity defects. Blocked and not-run tests can also represent release risk even though they have not failed.

Use a trend chart or status breakdown to show whether testing is progressing as planned and where work is stalled.

11. Defects per software change

Defects per software change measures how many confirmed defects are associated with a release, feature, pull request, or other defined change.

A basic formula is:

Defects per change = Confirmed defects linked to changes ÷ Changes tested

This metric can help identify changes that introduce disproportionate risk. For example, repeated defects in changes affecting the same component may indicate architectural complexity, unclear requirements, or insufficient regression coverage.

Avoid distributing defects evenly across changes. If a release contains five changes and produces 25 defects, that does not mean each change introduced five defects. Link each defect to the change that caused it whenever possible.

Change size also matters. Compare similar changes or normalize the results using factors such as story points, lines changed, or affected components. Review defect severity alongside the total because one critical regression may matter more than several minor issues.

12. Defect distribution over time

Defect distribution shows where defects occur and how that distribution changes throughout a test cycle or across releases.

Teams can group defects by:

• Severity or priority
• Product component
• Root cause
• Platform, browser, or device
• Test type
• Discovery stage
• Release or sprint
• Opened and resolved date

Tracking the distribution over time can reveal patterns that a total defect count would hide. For example, the overall number of defects might decline while critical defects in a payment workflow increase.

Use consistent categories across reporting periods. If severity definitions or component labels change, document the change so teams do not mistake a reporting difference for a quality trend.

Defect distribution should guide investigation and prioritization. It should not be used to compare individual testers based on how many defects they report.

13. Defects opened vs. defects closed

This metric compares the number of confirmed defects opened with the number closed during the same reporting period.

Two useful calculations are:

Net defect backlog change = Defects opened − Defects closed

Closure-to-discovery ratio = Defects closed ÷ Defects opened × 100

If more defects are opened than closed, the backlog grows. If more are closed than opened, it shrinks.

Interpret this metric alongside severity and release stage. A shrinking backlog is not necessarily positive if critical defects remain unresolved or defects are being closed without adequate verification. A growing backlog may be expected during an intensive testing phase when defect discovery accelerates.

A trend chart showing opened, closed, and remaining defects can help teams understand whether remediation is keeping pace with discovery.

14. Defect resolution rate

Defect resolution rate measures the percentage of confirmed defects from a defined group that have been resolved.

Defect resolution rate = Resolved defects ÷ Total confirmed defects in the group × 100

The group might include defects associated with a release, sprint, component, or reporting period. Use a consistent cohort so defects opened in one period are not incorrectly compared with unrelated defects closed in another.

Segment the result by severity. A high overall resolution rate can be misleading if the remaining defects include critical or release-blocking issues.

This metric reflects the combined work of development, QA, product, and other teams involved in triage and remediation. It should not be treated solely as a measure of QA performance.

15. Defect age

Defect age measures how long a defect has remained open.

Open defect age = Current date − Defect creation date

For defects that have already been closed, measure resolution time instead:

Defect resolution time = Resolution date − Defect creation date

Report median age and age ranges rather than relying only on an average. A few very old defects can distort the average and hide the condition of the rest of the backlog.

A useful breakdown might include:

• Less than 7 days
• 7–30 days
• 31–90 days
• More than 90 days

Review defect age by severity, priority, and product area. An old low-priority visual issue may be acceptable, while an unresolved high-severity defect can represent significant release risk.

Decreasing defect age may indicate faster triage and remediation, but it should be evaluated alongside reopen rates, verification quality, and the severity of the defects being resolved.

16. Test case effectiveness

Test case effectiveness evaluates whether test cases expose meaningful defects and provide useful evidence about product behavior.

One narrow indicator is the defect-revealing test rate:

Defect-revealing test rate = Test cases that exposed at least one confirmed defect ÷ Test cases executed × 100

Count each test case once, even if it uncovers multiple defects. Otherwise, the result could exceed 100%.

Do not interpret a higher rate as automatically better. Stable regression tests provide value even when they pass, and an unusually high defect-revealing rate may indicate an unstable build rather than strong test design.

Evaluate test cases using additional signals such as:

• Coverage of important requirements and risks
• Severity of the defects detected
• Duplicate or obsolete test cases
• False failures and flaky results
• Production defects the suite failed to detect
• Clarity, repeatability, and maintainability

Use these signals to improve the test suite rather than score individual testers.

17. Defect leakage

Defect leakage occurs when a defect is not detected at the testing stage expected to catch it and is discovered at a later stage.

For example, a defect that should have been found during system testing but is first identified during UAT represents leakage from system testing. A production escape is therefore one type of defect leakage, but leakage can occur between any two test levels.

A common formula is:

Defect leakage rate = Defects found after the target test stage ÷ (Defects found during the target stage + Defects found afterward) × 100

Include only defects the target stage was reasonably expected to detect. A security issue discovered in penetration testing should not automatically count as leakage from a functional testing stage.

For each leaked defect, review:

• The test stage that should have caught it
• Whether the relevant risk or requirement had coverage
• Whether the test existed but failed to expose the defect
• Whether environment or data differences affected detection
• What additional test or process change is needed

Segment leakage by severity and affected component so critical gaps are not hidden inside an overall percentage.

18. Test case productivity

Test case productivity measures the amount of test-design or maintenance work completed within a defined amount of effort.

For planning purposes, teams may calculate:

Test design throughput = Approved test cases created ÷ Test-design hours

The same approach can be used for test updates or automation work, provided each category is measured separately.

This metric requires caution because test cases vary substantially in complexity. A short validation test and a detailed end-to-end workflow should not be treated as equivalent units of work.

Use test case productivity to:

• Improve capacity estimates
• Understand the effect of changing requirements
• Identify unusually time-consuming product areas
• Compare similar work performed under similar conditions

Do not use it to rank individual testers or encourage higher test counts. That can lead to duplicated, shallow, or unnecessarily fragmented test cases.

19. Test completion rate

Test completion rate measures how much of the planned testing scope has reached a completed result.

Test completion rate = Completed tests ÷ Total tests planned × 100

Define which results count as complete. Passed and failed tests usually qualify because they produced a result. Blocked, skipped, or partially executed tests may need to remain incomplete depending on the team’s workflow.

This metric differs from test execution status:

• Test execution status shows the current distribution of passed, failed, blocked, and untested cases.
• Test completion rate shows overall progress against the planned scope.

Track completion over time rather than only at the end of the cycle. A test completion burn-up chart can reveal whether execution is progressing quickly enough to meet the release deadline.

A high completion rate does not prove release readiness. Review unresolved failures, blocked critical tests, coverage gaps, and accepted risks before making a release decision.

20. Test review efficiency

Test review efficiency evaluates how quickly and consistently test cases are reviewed before use.

The original formula is more accurately described as a review completion rate:

Test review completion rate = Test cases reviewed ÷ Test cases submitted for review × 100

Teams can also measure review cycle time:

Test review cycle time = Review completion date − Review submission date

Useful supporting indicators include:

• Percentage of test cases approved on the first review
• Percentage returned for substantial revision
• Median time waiting for review
• Number of test cases used before review
• Common reasons for rejection or rework

A faster review process is not necessarily more effective. Reviews should confirm that test cases have clear preconditions, useful steps, expected results, appropriate coverage, and no unnecessary duplication.

Use this metric to identify review bottlenecks and improve test quality—not to reward reviewers for approving cases as quickly as possible.

Put these QA metrics to work with TestRail

TestRail helps teams centralize the test cases, execution results, requirements, and defects used to calculate many of the metrics in this guide.

Teams can use TestRail to:

• Monitor passed, failed, blocked, and untested cases across test runs and plans
• Track testing progress by milestone, project, configuration, or assignee
• Link test cases to requirements and identify coverage gaps
• Connect failed tests with defects from integrated issue trackers
• Compare results across test runs and configurations
• Review test case activity and maintenance
• Import automated test results through the TestRail API or CLI
• Generate project-level reports and, on Enterprise plans, cross-project reports

TestRail does not calculate every metric in this guide automatically. Cost, production incidents, customer impact, and engineering-remediation data may come from financial systems, observability platforms, support tools, or issue trackers. Teams can combine that information with TestRail results through exports, APIs, or reporting tools.

The goal is to maintain a consistent source of test information that helps QA leaders explain coverage, execution progress, defect risk, and release readiness.

Start a free 30-day TestRail trial to evaluate its reporting and traceability capabilities with your own testing workflow.

Frequently asked questions about QA metrics

What are QA metrics?

QA metrics are measurements used to evaluate testing progress, product quality, process efficiency, and release risk. Examples include requirements coverage, escaped defects, test completion rate, defect age, and flaky-test rate.

A useful QA metric should answer a specific question or support a decision. Collecting a number without understanding how it will be used usually creates reporting work without improving quality.

Which QA metrics are most important?

The most useful metrics depend on the product, release, and risks involved. Most teams benefit from tracking a balanced group that includes:

• Escaped defects by severity
• Coverage of critical requirements and risks
• Test execution and completion status
• Flaky-test rate
• Open defects by age and severity
• Defect resolution trends
• Time to actionable test feedback

Avoid selecting metrics only because they are easy to collect. Start with the decisions stakeholders need to make and identify the measurements that provide relevant evidence.

How many QA metrics should a team track?

A team does not need to track all 20 metrics continuously. A smaller set of actionable measurements is usually more useful than a large dashboard that no one reviews.

Start with approximately five to eight metrics tied to current quality goals. Add or remove metrics as the product, release process, and risks change.

How often should QA metrics be reviewed?

Operational metrics such as execution status, blocked tests, and critical defects may need daily review during active testing. Release-level metrics can be reviewed at milestones or release-readiness meetings. Longer-term trends such as escaped defects, defect age, and test reliability may be reviewed monthly or quarterly.

The reporting schedule should match how quickly the team can act on the information.

What makes a good QA metric?

A good QA metric is:

• Connected to a clear quality objective
• Defined consistently
• Based on reliable data
• Easy for stakeholders to interpret
• Reviewed with relevant context
• Capable of prompting a decision or action

It should also be difficult to manipulate. Metrics based only on test or defect counts can encourage teams to increase volume without improving coverage or quality.

What tool creates a QA report?

Test management platforms such as TestRail create reports from test cases, test runs, results, requirements references, and linked defects. CI/CD platforms, issue trackers, observability tools, and business-intelligence systems may provide additional data.

The right reporting setup depends on the metrics being measured. TestRail can report on testing activity and traceability, while costs, production incidents, and customer impact may need to be sourced from other systems.

Does TestRail support test reporting and traceability?

Yes. TestRail includes reports for test cases, test results, defects, references, milestones, plans, and runs. Teams can link test cases to requirements or other references and connect test results with defects.

Cross-project reports are available with TestRail Enterprise and require the appropriate permissions.

How does TestRail help teams track test coverage?

Teams can link test cases to requirements using TestRail’s References field. Coverage reports can then show which references have associated test cases and compare results for tests connected to those references.

This measures requirements traceability and execution coverage. It should not be confused with code coverage, which is typically collected by development or automation tools.

Does TestRail calculate every QA metric automatically?

No. TestRail directly stores and reports data related to test cases, execution, results, references, defects, milestones, and assignments. Metrics involving labor cost, downtime, customer support, production incidents, or revenue require data from other systems.

Teams can use TestRail’s API and exports to combine test data with other sources when they need broader quality reporting.

Is TestRail free?

TestRail is a paid test management platform with cloud and self-hosted options. A free 30-day trial is available, and current plan details are listed on the TestRail pricing page.