Software Testing Metrics: What is, Types & Example

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Software Testing Metrics are quantitative measures of the progress, quality, and productivity of a testing process. This guide covers the three metric types, the base and calculated distinction, the metrics lifecycle, and a formula glossary you can apply directly.

  • 📐 Core Purpose: Metrics turn opinions about test quality into numbers that support a decision.
  • 🧱 Three Types: Process metrics improve the lifecycle, product metrics measure software quality, and project metrics measure team efficiency.
  • 🔢 Base vs Calculated: Base metrics are raw counts gathered by the analyst; calculated metrics are the percentages derived from them.
  • 🔄 Four Lifecycle Stages: Analysis, communication, evaluation, and reporting, each with its own defined steps.
  • 🧮 Worked Formula: Percentage executed equals test cases executed divided by test cases written, multiplied by 100.
  • ⚠️ Selection Rule: Define the audience and the goal before choosing a metric, otherwise you collect data nobody acts on.
Read More

Software Testing Metrics

What are Software Testing Metrics?

Software Testing Metrics are the quantitative measures used to estimate the progress, quality, productivity and health of the software testing process. The goal of software testing metrics is to improve the efficiency and effectiveness in the software testing process and to help make better decisions for further testing process by providing reliable data about the testing process.

A metric expresses, in quantitative terms, the degree to which a system, a component, or a process possesses a given attribute. A simple analogy is a car’s actual weekly fuel consumption compared with the figure the manufacturer quotes.

Testing Metrics in Software Testing

Software testing metrics – Improves the efficiency and effectiveness of a software testing process.

Software testing metrics or software test measurement is the quantitative indication of extent, capacity, dimension, amount or size of some attribute of a process or product.

Example for software test measurement: Total number of defects

Why are Test Metrics Important?

“We cannot improve what we cannot measure.” Test metrics exist to make the testing process measurable.

  • Decide what the next phase of activities should be
  • Provide evidence for a claim or a prediction about quality
  • Identify which kind of improvement is required
  • Justify a change of process or of technology

Read more about its Importance of Test Metrics

Types of Test Metrics

Types of Test Metrics

  • Process Metrics: It can be used to improve the process efficiency of the SDLC (Software Development Life Cycle)
  • Product Metrics: It deals with the quality of the software product
  • Project Metrics: It can be used to measure the efficiency of a project team or any testing tools being used by the team members

Choosing the right metrics matters more than collecting many of them. Consider the following before settling on a set:

  • Fix the target audience for the metric preparation
  • Define the goal for metrics
  • Introduce all the relevant metrics based on project needs
  • Weigh the cost and benefit of each metric, and the project lifecycle phase in which it delivers the most value

Manual Test Metrics

In Software Engineering, Manual test metrics are classified into two classes

  • Base Metrics
  • Calculated Metrics

Manual Test Metrics

Base metrics is the raw data collected by Test Analyst during the test case development and execution (# of test cases executed, # of test cases). While calculated metrics are derived from the data collected in base metrics. Calculated metrics is usually followed by the test manager for test reporting purpose (% Complete, % Test Coverage).

Depending on the project or business model, the metrics that matter most are usually:

  • Test case execution productivity metrics
  • Test case preparation productivity metrics
  • Defect metrics
  • Defects by priority
  • Defects by severity
  • Defect slippage ratio

RELATED ARTICLES

Manual vs Automation Test Metrics

The metrics described above assume a manually executed suite. An automated suite is measured differently, because execution effort is no longer the constraint.

Criteria Manual Testing Metrics Automation Testing Metrics
Primary focus Effort and execution progress Coverage, stability, and run time
Typical measure Test cases executed per day Automation coverage percentage
Quality signal Defects found per test hour Flaky test rate, the share of unstable tests
Cost measure Tester hours Script maintenance hours per release
Speed measure Cycle duration in days Suite execution time in minutes 
Automation Coverage = (Test cases automated / Total test cases) x 100

Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100

Flaky test rate deserves particular attention. Once it passes roughly 5 percent, teams begin ignoring red builds, and at that point the suite stops providing information regardless of how high its coverage is.

Test Metrics Life Cycle in Software Engineering

Test Metrics Life Cycle in Software Engineering

Different stages of Metrics life cycle Steps during each stage
Analysis
  1. Identification of the Metrics
  2. Define the identified QA Metrics
Communicate
  1. Explain the need for metric to stakeholder and testing team
  2. Explain to the testing team which data points must be captured to calculate the metric
Evaluation
  1. Capture and verify the data
  2. Calculating the metrics value using the data captured
Report
  1. Develop the report with an effective conclusion
  2. Distribute the report to the stakeholder and respective representative
  3. Take feedback from stakeholder

How to Calculate a Test Metric

Sr# Steps to test metrics Example
1 Identify the key software testing processes to be measured Testing progress tracking process
2 In this Step, the tester uses the data as a baseline to define the metrics The number of test cases planned to be executed per day
3 Determination of the information to be followed, a frequency of tracking and the person responsible The actual test execution per day will be captured by the test manager at the end of the day
4 Effective calculation, management, and interpretation of the defined metrics The actual test cases executed per day
5 Identify the areas of improvement depending on the interpretation of defined metrics If test case execution falls below the agreed goal, investigate the cause and propose corrective measures

Example of a Test Metric Calculation

Take the percentage of test cases executed as a worked example. To express execution status as a percentage, use the formula:

Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100

If 250 test cases were written and 175 have been executed, the result is (175 / 250) x 100 = 70 percent.

The same pattern applies to every other execution parameter: test cases not executed, passed, failed, and blocked. Each is simply a different numerator over the same denominator.

Most Important Test Metrics to Track

The glossary at the end of this tutorial lists every formula in common use. In practice, a reporting pack rarely needs more than eight. These are the ones that consistently drive a decision.

Metric What it answers Watch out for
Test case execution percentage How far through the planned run are we? Says nothing about quality, only progress
Defect density Defects per size unit, so which module is weakest? Depends on a consistent size measure
Defect removal efficiency What share of defects did we catch before release? Can only be finalised after production data arrives
Defect leakage How many defects reached the customer? The single most important quality signal
Test coverage How much of the requirement set is exercised? High coverage with weak assertions proves nothing
Defect severity index Are the open defects serious or cosmetic? Counting defects without weighting misleads
Mean time to repair How quickly does the team turn a fix around? Skewed by a few long-running defects
Test execution productivity How many cases does a tester complete per day? Encourages shallow tests if used as a target

Two formulas worth adding to the glossary because they are the ones management asks for:

Defect Removal Efficiency = (Defects found before release / Total defects found) x 100

Defect Leakage = (Defects found in production / Defects found before release) x 100

The measurement trap. Any metric used as a target stops being a good measure. Set a productivity target of 30 test cases per day and testers will write 30 trivial ones. Report metrics as a set, never in isolation, and pair every productivity figure with a quality figure.

Software Testing Metrics Formula Glossary

  • Rework Effort Ratio = (Actual rework efforts spent in that phase/ total actual efforts spent in that phase) X 100
  • Requirement Creep = ( Total number of requirements added/No of initial requirements)X100
  • Schedule Variance = (Actual Date of Delivery – Planned Date of Delivery)
  • Cost of finding a defect in testing = ( Total effort spent on testing/ defects found in testing)
  • Schedule slippage = (Actual end date – Estimated end date) / (Planned End Date – Planned Start Date) X 100
  • Passed Test Cases Percentage = (Number of Passed Tests/Total number of tests executed) X 100
  • Failed Test Cases Percentage = (Number of Failed Tests/Total number of tests executed) X 100
  • Blocked Test Cases Percentage = (Number of Blocked Tests/Total number of tests executed) X 100
  • Fixed Defects Percentage = (Defects Fixed/Defects Reported) X 100
  • Accepted Defects Percentage = (Defects Accepted as Valid by Dev Team /Total Defects Reported) X 100
  • Defects Deferred Percentage = (Defects deferred for future releases /Total Defects Reported) X 100
  • Critical Defects Percentage = (Critical Defects / Total Defects Reported) X 100
  • Average time for a development team to repair defects = (Total time taken for bugfixes/Number of bugs)
  • Number of tests run per time period = Number of tests run/Total time
  • Test design efficiency = Number of tests designed /Total time
  • Test review efficiency = Number of tests reviewed /Total time
  • Bug find rate, or defects per test hour = Total number of defects / Total number of test hours

FAQs

Base metrics are raw counts collected during execution, such as the number of test cases written or run. Calculated metrics are derived from them, usually as percentages, and are what appears in management reports.

Between five and eight for regular reporting. Beyond that, effort goes into collection rather than action. Every metric on the report should be tied to a decision somebody actually makes.

Because behaviour adapts to the measure. A target of test cases executed per day produces shallow test cases. Always pair a productivity metric with a quality metric such as defect leakage.

AI-based tools generate coverage and risk scores automatically, and predict which modules are most defect-prone from historical data. This shifts reporting from counting past activity towards forecasting where defects will appear.

Yes. AI assistants can compute metrics from raw test data, spot trends across releases, and draft the narrative for a report. Verify every figure against the source data before circulating it.

Summarize this post with: