Series: QA Leadership · Article 1 of 9

You track defects, test coverage, execution results - and you have the feeling that outside your own QA team nobody cares. You're right. And it's not your fault.

For years I’ve watched the same pattern: meticulously prepared dashboards, detailed bug tables - and complete silence from the business side. Sprint review wrapped up with “ok, thanks”, decisions made by gut feel, with no anchor in QA data.

The problem isn’t a lack of data. We have too much data. The problem is that we report activity instead of outcomes. This isn’t a technical problem - it’s a communication problem.

An activity metric tells you how hard you worked. An outcome metric tells you what the result was. The business pays for results - and that is what it wants to hear about.

This article is the first of nine in a series. You’ll learn which metrics to collect, how to interpret them, and - most importantly - how to use them to tell a story that stakeholders understand and can act on.

What the business actually hears

Picture a sprint review. QA presents numbers. Stakeholders nod. The decision is made by feel. Below are exactly the same facts about exactly the same sprint - in two different languages.

BEFORE - Activity
Bugs found47
Tests executed312
Pass rate94%
Coverage82%
Nobody reads it. Gut-feel decision.
AFTER - Outcomes
Defect Detection Ratio94%
Escaped / Release1.2
Issues / Release8 ↓ 40%
Releases this Q10
Confidence Score91%
Story. Decisions. GO.

The left side describes how busy QA is. The right side answers the question the business actually asks: can we release, and how is quality trending? This shift doesn’t require new tools - it requires a new approach to the question you want your data to answer.

What the business really wants - three pillars

Stakeholders ask three questions - and those are the questions your QA metrics should answer. Nothing more, nothing less.

Pillar 1 - Release confidence

One question, one answer: can we ship? A Release Confidence Score aggregates blockers, regression results and critical paths into a single indicator. One number - one decision in the steering committee.

Sprint 12
62%
Hold
Sprint 13
78%
Conditional
Sprint 14
94%
GO

Pillar 2 - Cost of defects

One escaped bug isn’t “+1 to the counter”. It’s a concrete number of hours and currency. Once you start converting it - you have a financial argument that every CFO and every Engineering Manager understands.

DevOps
4.5h
hotfix + rollback
Developer
2h
analysis + fix
PM
1h
coordination
SLA breach
+penalty
customer trust
Total
8h+
per 1 defect

A single sprint is nothing. Four quarters are a story - and direct evidence that investment in QA pays off. The escaped defect rate trend is one of the strongest arguments in a conversation with the board because it talks about return on investment.

Escaped Defect Rate - yearly trend
Percentage of defects discovered after deployment to production
↓ 66% YoY
Escaped Defect Rate (%)

Five metrics that together tell a story

Each of the metrics below answers one specific business question. Combined, they form a narrative stakeholders understand and can act on. Individually they inform - together they tell a story.

# Metric What question does it answer?
01
Defect Detection Ratio
DDR = pre-release bugs ÷ (pre + post)
How many defects do we catch before they hit production?
02
Escaped Bugs & Problems
Code, infra, configuration, integrations, regressions post-deploy
What slips into production and in what form?
03
Issues per Release
All problems found in a single release
How mature is the code that reaches testing?
04
Escaped Bugs per Release
Escaped per specific release - not the overall rate
Which releases were risky and why?
05
Number of Releases
Context metric - normalises everything above
Are we comparing apples to apples?
DDR vs Escaped Bugs - quarterly trend
A classic healthy QA trend: DDR rises, escaped falls - at the same time
Q1 - Q4 2025
DDR (%) Escaped Bugs (count)
Issues per Release - code maturity
A drop from 24 to 8 is a 66% improvement. Not just QA - the whole delivery process is maturing.
v2.1 → v2.5
Issues found in a release

Three releases in a row below 10 issues is the moment when you can tell the Engineering Manager: “look what we did together over the last six months.” That’s the conversation data enables - and the one you simply can’t have without data.

Mapping model

QA → Business KPIs

Every QA metric has its counterpart in business language. The QA Lead's job is to build that bridge - and to anchor each number in the question a stakeholder asks in the steering committee.

Confidence Score
Release Predictability
Can we release safely?
DDR + Escaped Rate
Cost of Poor Quality
How much do bugs cost us?
Issues/Release + Releases
Delivery Sustainability
Are we accelerating safely?
Escaped/Release trend
Risk per Deployment
Which release was risky?

Three reporting anti-patterns

Even good data can be presented badly. Here are the mistakes that most often destroy QA credibility in the eyes of the business - and which you only need to be aware of to avoid.

01
Too many metrics
A dashboard with 20 charts is overwhelming. When everything is important - nothing is. Start with 3 metrics, add gradually.
02
No context
Just "82%" with no trend and no goal says nothing. Always: number + direction + target. Trend says where you're coming from, target - where you're heading.
03
Technical jargon
Speak the audience's language, not your tool's. No "flaky tests in the CI/CD pipeline" on a slide for the Product Owner. Plain and clear.

What comes next - 9 articles, one topic

Series: QA metrics the business wants to hear
  • 01
    The complete guide you are here
    Diagnosis of the problem, three pillars, five metrics, the QA → KPI mapping model
  • 02
    Formula, interpretation, pitfalls, real-life numerical examples
  • 03
    Why count more than just bugs in the application code
  • 04
    How this metric reshapes the conversation with the Engineering Manager
  • 05
    Pinpointing problems, not just watching trends
  • 06
    Number of Releases - the context metric
    Why 3 bugs with 2 releases is a disaster, and with 15 - a success
  • 07
    Release Confidence Score step by step
    Three calculation models, rollout, concrete examples from practice
  • 08
    Storytelling with metrics - building a narrative
    How to turn a table of numbers into a business argument
  • 09
    3 anti-patterns that destroy QA credibility
    Too many metrics, no context, jargon - and how to avoid each