Software Testing Metrics and Reporting

Testing metrics are measurable values that tell the team how testing is progressing, how much of the software has been tested, and how healthy the overall quality is. Good metrics drive better decisions. Poor metrics create a false sense of security.

Why Metrics Matter

  Without metrics:
  "Testing is going well, I think we're almost done."

  With metrics:
  "We have executed 420 of 500 test cases (84%).
   35 bugs found. 28 closed. 7 open (2 critical).
   Defect density: 4.2 bugs per module.
   At the current rate, we finish in 3 days."

  Metrics replace guesses with facts.

Core Testing Metrics

Test Case Execution Rate

The percentage of planned test cases that have been executed so far.

  Formula: (Executed Test Cases / Total Test Cases) × 100

  Example: 420 / 500 × 100 = 84%

Test Pass Rate

The percentage of executed test cases that passed.

  Formula: (Passed Test Cases / Executed Test Cases) × 100

  Example: 385 passed / 420 executed × 100 = 91.7%

  A low pass rate signals quality problems.
  A suspiciously high pass rate may signal weak test cases.

Defect Density

The number of bugs found per module or per 1,000 lines of code. Identifies which modules carry the most risk.

  Formula: Defects Found / Size of Module (lines of code or feature count)

  Module A: 5 bugs / 500 lines = 0.01 bugs per line
  Module B: 40 bugs / 500 lines = 0.08 bugs per line ← High risk

Defect Removal Efficiency (DRE)

The percentage of all bugs that the testing team found before the product reached real users. A higher DRE means fewer bugs reached production.

  Formula: (Bugs found before release / Total bugs including post-release) × 100

  Pre-release bugs found:  85
  Post-release bugs found: 15
  Total bugs:              100

  DRE = 85 / 100 × 100 = 85%

  Industry target: 85–95% DRE

Defect Leakage

The number or percentage of bugs that escaped testing and were found by users in production. Lower is better.

  Formula: (Bugs found in production / Total bugs) × 100

  15 bugs in production / 100 total bugs × 100 = 15% leakage

Mean Time to Detect (MTTD)

The average time between a bug being introduced into the code and the testing team finding it. Shorter MTTD means bugs are caught faster.

Mean Time to Resolve (MTTR)

The average time from bug report to bug fix and closure. Longer MTTR suggests bottlenecks in the fix-verify cycle.

Test Coverage

The percentage of requirements, code paths, or features covered by at least one test case.

  Requirement Coverage: 48 of 60 requirements have test cases → 80%
  Code Coverage:        75% of code lines run during testing

Bug Trends: Reading the Burn-Down

  Week 1:  Bugs Found: 45  |  Bugs Closed: 20  |  Open: 25
  Week 2:  Bugs Found: 30  |  Bugs Closed: 35  |  Open: 20
  Week 3:  Bugs Found: 12  |  Bugs Closed: 25  |  Open: 7
  Week 4:  Bugs Found: 3   |  Bugs Closed: 9   |  Open: 1

  ↓ Healthy trend: new bugs declining, closure rate high.
  The product is becoming more stable over time.

A healthy project shows decreasing bug discovery over time and a rising closure count. A project where new bugs are discovered faster than they are fixed signals quality problems that need urgent attention.

The Test Summary Report

At the end of a testing cycle or sprint, the team produces a test summary report. This document gives stakeholders a clear picture of what was tested, what was found, and whether the product is ready for release.

  TEST SUMMARY REPORT — Structure
  ──────────────────────────────────────────────────────────
  1. Project / Release Information
  2. Testing Scope (what was in scope and out of scope)
  3. Test Execution Summary
     - Total test cases: 500
     - Executed: 500 (100%)
     - Passed: 472 (94.4%)
     - Failed: 18 (3.6%)
     - Blocked: 10 (2%)
  4. Defect Summary
     - Total bugs found: 35
     - Critical: 0   High: 2   Medium: 9   Low: 24
     - Open: 11   Closed: 24
  5. Test Coverage
  6. Risks and Open Issues
  7. Recommendation: Go / No-Go for release
  8. Sign-off

Metrics That Mislead

Some metrics look good on paper but hide real problems. Watch out for:

100% test case execution with 0 bugs: May indicate test cases are too weak to find real bugs — not that the software is perfect.
High pass rate with many blocked tests: Blocked tests are not passing — they are skipped due to environment or dependency issues.
Lines of code covered: Code coverage measures what ran, not what was actually verified. A test that runs code without checking the result achieves coverage without testing anything.

Reporting to Stakeholders

Different stakeholders need different levels of detail from testing reports.

  AUDIENCE              WHAT THEY NEED
  ────────              ──────────────
  Development Team      Detailed bug reports, test case results,
                        reproduction steps

  Project Manager       Bug trends, execution progress,
                        risk summary, Go/No-Go recommendation

  Business Stakeholders High-level quality status, feature readiness,
                        key open risks in plain language

  C-Level / Executive   One-page dashboard: quality score,
                        release risk, key decisions needed

Tailor your reports to the audience. A developer needs detailed technical context. A business executive needs a clear, jargon-free summary of readiness and risk.

Previous lessons

Back to courses