QA Metrics and Reporting: How to Calculate Each Metric and Report It
A formula for every common QA metric, the test data behind it, and a reporting rhythm that gives each audience the numbers it needs.
For QA leads and engineers who report testing progress, and anyone building a quality dashboard from test run data.
What Are QA Metrics?
QA metrics are numbers calculated from test execution, defect and planning data that show how much has been tested, how well it passed, and where risk is concentrated. QA reporting puts the right metrics in front of each audience on a regular rhythm, so decisions rest on the same facts.
Every metric in this guide comes with its formula and the data that feeds it in Evaficy Smart Test, so you can calculate it the same way every time.
The Data Behind Every Metric
Six sources supply everything the formulas below need:
| Source | What it records | Where you find it |
|---|---|---|
| Run summary | Per run: total cases, passed, failed, blocked, skipped, not run, and the pass rate | Runs list and run header |
| Run report | Per case: status, executed by and at, actual result, defect description and severity, block and skip reasons | Export CSV or PDF from a run |
| Defects | Status, severity, priority and linked scenario for every defect | Defects page, Standalone Defects and From Test Runs tabs, with filters |
| Test Plan | Scenarios in scope for a release and the share with a completed run | Test Plans |
| Risk Insights | Per scenario: a risk score, fail rate and trend from completed runs | Risk Insights panel on the Dashboard, from 5 completed runs |
| Time tracking | Hours by category, optionally linked to a scenario, run or defect | Time Tracking page, My time and Team tabs |
Test runs, their reports, Test Plans and Risk Insights are part of the Enterprise plan. Defects and time tracking are available on every plan.
Execution Metrics and Their Formulas
These come from the run summary and the run report. Calculate them per completed run, then line the runs up to see the trend:
| Metric | Formula | How to read it |
|---|---|---|
| Pass rate | passed ÷ total cases × 100 | The run summary counts every case, including those not run yet, so the figure grows during execution. Compare completed runs. |
| Execution progress | (total − not run − in progress) ÷ total × 100 | How far a run has got. The run header shows it as "executed / total". |
| Pass rate of executed cases | passed ÷ (passed + failed + blocked + skipped) × 100 | A mid-run quality signal, calculated from the run report. |
| Blocked ratio | blocked ÷ total cases × 100 | The Block Reason column shows what to unblock first. |
| Failure concentration | a scenario's failed cases ÷ all failed cases in the period × 100 | Shows where failures cluster across runs. |
| Fix verification rate | passed ÷ total cases in a Re-run Failed run × 100 | A re-run contains only the cases that failed, so this measures how many fixes held. |
Re-run Failed creates a new run named "Re-run: <original name>" containing only the cases that failed, which makes the fix verification rate a one-line calculation. For how each case status is set during execution, see the Test Run Execution guide.
Defect Metrics and Their Formulas
Defects logged during a run appear in that run's report and on the Defects page under From Test Runs; defects logged on their own appear under Standalone Defects. Both tabs filter by project, status, severity and priority.
| Metric | Formula | How to read it |
|---|---|---|
| Defects found per run | run report rows with a defect description | Count per run and compare across builds. |
| Open defects by severity | defects with status Open or In progress, grouped by severity | Filter the Defects page by status and severity. |
| Defect density per scenario | defects linked to a scenario ÷ test cases in that scenario | Highlights the areas that generate the most defects per case. |
| Time to fix | date resolved − date reported | Record the date a defect moves to Resolved in your report sheet; the defect keeps its current status. |
Severity and priority answer different questions, and good reports show both. The Defect Reporting guide explains how to set them.
Planning, Risk and Effort Metrics
These three answer the release-level questions: is everything in scope tested, where is the risk, and what does testing cost in time?
| Metric | Formula | How to read it |
|---|---|---|
| Test Plan coverage | scenarios with at least one completed run ÷ scenarios in the plan × 100 | Any completed run of a scenario counts, so check build versions for a release-specific figure. |
| Risk score | fail rate × 80, plus 20 if worsening or minus 10 if improving, capped at 0 to 100 | Fail rate is failed ÷ total cases across a scenario's completed runs. |
| Time per executed case | hours logged against a run ÷ executed cases | Uses time entries linked to the run. |
Risk Insights calculates the risk score for you once a project has 5 completed runs. A scenario's trend compares the average pass rate of its last 3 runs with its earlier runs: more than 10 points higher reads as improving, more than 10 points lower as worsening. See Test Plan Management for how plans group scenarios for a release.
A Reporting Rhythm That Works
Report at three levels, each built from the one below:
After every run
Share the run report PDF with the people who requested the run. It carries the case results, defects and environment, so it stands on its own.
Every week
Export each completed run as CSV into one sheet and add a row per run: pass rate, blocked ratio, defects found and open defects by severity. Four columns, one glance, a clear trend.
Every release
Lead with the decision, then Test Plan coverage, the highest risk scores from Risk Insights, open critical and high defects, and the fix verification rate of the last re-run.
One Dashboard, Three Audiences
The same sheet serves everyone; each audience reads a different slice of it:
The QA team
Tech Leads and developers
Product Owners and release owners
For reports that go to clients, see Building QA Reports Clients Actually Care About.
Common Questions
Which QA metrics should a team start with?
Start with three: pass rate per completed run, open defects by severity, and Test Plan coverage for the current release. Add failure concentration and blocked ratio once you have a few runs of history.
Why does the pass rate rise while a run is in progress?
The run summary divides passed cases by all cases in the run, including those not run yet. Each case that passes adds to the figure, so the final pass rate is the one to compare across runs.
How many runs do I need before trends mean something?
Three to five completed runs of the same scenario give a useful first trend. Risk Insights starts scoring once a project has 5 completed runs, and calculates a scenario's trend once it has 4 or more completed runs.
Can I measure how long defects take to fix?
Yes, with one extra step: note the date each defect moves to Resolved in your report sheet. Evaficy Smart Test keeps each defect's current status, so the dates you record give you the time to fix.
Where do I decide which metrics are worth tracking?
This guide shows how to calculate and report each metric. For which metrics signal real quality and which are vanity numbers, see the Test Coverage guide.
Key Takeaways
- Calculate every metric from a fixed formula and a named data source, so the numbers stay comparable.
- Pass rate counts all cases in a run, so compare completed runs rather than runs in progress.
- The fix verification rate comes straight from a Re-run Failed run.
- Test Plan coverage and Risk Insights answer the release-level questions.
- Report after every run, every week, and every release, each level built from the one below.
- One sheet serves the QA team, Tech Leads and Product Owners; each reads its own slice.
Turn every test run into numbers you can report
Create your free account to run scenarios, log defects in context, and export the results your metrics are built from.
Create your free account