DORA Metrics for QA Teams (2026)

DORA metrics are how engineering leaders talk about delivery performance — but they’re usually framed as a DevOps or platform concern, and QA gets left out of the conversation. That’s a mistake. Testing is one of the strongest levers on the metrics that matter most, and QA teams that can speak in DORA terms make their impact legible to leadership. This guide maps testing to each metric. Where we reference Qualflare, we describe only what it actually does.

The four DORA metrics

DORA metrics, from the DevOps Research and Assessment program, are four measures that split into two pairs answering two different questions. The throughput pair — deployment frequency (how often you ship) and lead time for changes (the time from commit to production) — measures how fast a team moves. The stability pair — change failure rate (the share of deployments that cause a failure) and time to restore service (how fast you recover when one does) — measures how safely it moves. Together, the DORA Four Keys are the standard vocabulary engineering leaders use for whether a team ships both fast and safely, rather than trading one for the other. One note on currency: DORA has since expanded this model — dora.dev now frames five metrics and has renamed “time to restore service” to “failed deployment recovery time.” The classic four keys below still map cleanly onto QA’s work, so this guide keeps the familiar terms throughout.

• Throughput — deployment frequency (how often you ship) and lead time for changes (commit to production).
• Stability — change failure rate (share of deployments that cause a failure) and time to restore service (how fast you recover).

Why QA teams should care

The headline insight: testing’s biggest impact is on the stability metrics, and stability is what keeps throughput honest. Anyone can deploy more often by testing less — until change failure rate spikes and time to restore balloons. Good testing is what lets a team raise throughput without sacrificing stability, and the mechanism isn’t abstract: a mid-sized suite carrying a few hundred flaky tests — roughly what Google’s ~16% flakiness rate implies at scale, walked through in the worked example below — trains engineers to rerun red builds instead of investigating them, which is exactly how real regressions slip through and change failure rate climbs. Fixing that, by quarantining the worst offenders and then root-causing them, moves detection time first, change failure rate within a few sprints, and lead time last, as trust in the suite comes back. None of that requires shipping less; it’s throughput recovered as a side effect of stability work. Framing QA’s work in DORA terms turns “we reduced flaky tests” into “we lowered change failure rate”, which is the language leadership funds.

How testing maps to each metric

Testing moves all four DORA metrics, but not equally, and not by the same mechanism. The clearest link is change failure rate: reliable tests catch regressions before they ship, so the metric most directly measures whether your suite is doing its job. Lead time for changes moves next most directly — fast, trustworthy tests keep the CI feedback loop short, and a short feedback loop is most of what lead time actually measures once code review time is accounted for. Deployment frequency moves more indirectly: it’s confidence from good tests, not testing itself, that lets a team ship smaller changes more often instead of batching risk into infrequent releases. Time to restore service is the least direct of the four, but testing still shortens it — fast detection and a clear failure signal turn diagnosis into minutes instead of hours once something does go wrong in production. The table below summarizes all four side by side:

DORA metric	How QA moves it
Change failure rate	The most direct link — reliable tests catch regressions before they ship
Lead time for changes	Fast, trustworthy tests keep the CI feedback loop short
Deployment frequency	Confidence from good tests lets teams ship smaller changes more often
Time to restore service	Fast detection and clear failure signals shorten diagnosis

The stability metrics QA owns

Change failure rate is the metric testing influences most, and it’s worth being precise about why it’s specifically a QA-owned lever rather than a shared one: deployment tooling, feature flags, and rollout strategy all touch it too, but only the test suite decides whether a regression gets caught before it ships in the first place. Improving coverage of critical paths and — critically — reducing flakiness moves it more than almost anything else, because a suite people trust actually blocks bad deploys instead of being waved through under cover of “probably just flaky.”

Time to restore service is shortened by fast detection and legible failures, and QA’s leverage here is more about signal quality than speed alone. When a test goes red and a failure cluster points straight at the cause instead of a bare stack trace, diagnosis is minutes, not hours — the same mechanism that improves mean time to detection in the worked example below applies just as directly once an incident is already in production, not only pre-merge.

How flaky and slow tests hurt DORA

Flaky and slow tests drag every metric the wrong way. Slow suites lengthen lead time directly — speeding up the CI suite is itself lead-time work. Flaky tests are worse: they delay releases through reruns, and — by training teams to ignore red builds — they raise change failure rate, because the one red build that mattered gets dismissed as “probably flaky.” And flakiness is common enough to matter at scale: Google reported that ~16% of its tests have some level of flakiness, so a team trained to wave through red builds is dismissing a large, noisy population of failures — and change failure rate climbs the moment one of them was real. Reliability work is DORA work — for a concrete model of what that noise actually costs in engineering hours, see the real cost of flaky tests.

What to measure on the QA side

DORA metrics are lagging indicators — they tell you what already happened, weeks after the decisions that caused it. QA should track three leading ones that feed them instead: flake rate, which measures how much the suite can actually be trusted; mean time to detection, which measures how fast tests catch a defect once it’s introduced; and CI feedback-loop time, which measures how fast developers actually get a result back. Improve these and the downstream DORA numbers follow with a lag, not a leap — flake rate drives change failure rate, detection time drives time to restore, and feedback-loop time drives lead time directly. The history needed to measure all three is the same test observability data that powers flaky detection and clustering, so teams that instrument one get the other two largely for free. In a monorepo, aggregating results across packages is what turns per-package noise into the single, trustworthy pass rate needed to track these indicators at all.

• Flake rate — how much the suite can be trusted.
• Mean time to detection — how fast tests catch a defect.
• CI feedback-loop time — how fast developers get a result.

These three are the DORA-specific leading indicators — for the broader QA metrics taxonomy beyond DORA (defect density, escape rate, automation rate, and more), see QA metrics that actually matter.

Start free with Qualflare — connect your pipeline and track the flakiness, detection, and feedback-loop signals that move your DORA metrics.

A worked example: turning flaky tests into a DORA win

The connection between flakiness and DORA metrics is easier to see with numbers attached. What follows is an illustrative walkthrough, not a specific customer’s reported results — built around the flakiness rate already cited above, to make the mechanism concrete rather than abstract.

Starting point. Consider a mid-sized team shipping a web application, running roughly 2,000 CI tests per build, several times a day. Using Google’s reported ~16% flakiness rate as a rough benchmark, a suite that size could plausibly carry somewhere in that neighborhood of tests exhibiting occasional flakiness — call it 250-300 tests that fail intermittently with no code change behind it. The team doesn’t track this explicitly; they just know CI “sometimes needs a rerun.” Two consequences follow from that: engineers default to re-running a red build before investigating it, since so many failures turn out to be noise, and change failure rate sits elevated — not because the code is unusually buggy, but because a meaningful share of the real regressions get waved through alongside the noise, dismissed as “probably another flaky one.”

The intervention. The team adopts a two-step process. First, quarantine — pull the worst, most-frequently-flaking tests out of the required-to-pass gate immediately, so CI stops crying wolf, without silently deleting coverage. Second, they work the quarantine list down over several sprints, applying root-cause analysis to each test instead of just adding a retry. They track flake rate weekly throughout, as a leading indicator, not a one-time cleanup metric.

What moves, and in what order. As the quarantine list shrinks, three things change in sequence, not all at once:

1. Mean time to detection improves first. With fewer flaky tests muddying the signal, a red build is far more likely to mean a real regression, so engineers stop reflexively re-running and start investigating immediately.
2. Change failure rate follows within a few sprints. The team is no longer waving through real failures under cover of flaky noise, so problems get caught and fixed pre-merge instead of surfacing as production incidents.
3. Lead time for changes improves last, and most gradually. A CI feedback loop people trust is one they wait for instead of routing around, and a suite with less contention from reruns is simply faster wall-clock.

The takeaway. None of this required shipping less often or slowing the team down — the throughput metrics (deployment frequency, lead time) improved as a side effect of stability work, which is the pattern DORA’s own research describes: stability and throughput move together, not in tension. The lever the team actually pulled was entirely on the QA side — quarantine, root-cause fixes, and tracking flake rate as a leading indicator — and it showed up as a stability story leadership could see.

Frequently asked questions

What are the four DORA metrics?

Deployment frequency (how often you ship), lead time for changes (commit to production), change failure rate (the share of deployments that cause a failure), and time to restore service (how quickly you recover). The first two measure throughput; the last two measure stability.

How does QA affect DORA metrics?

Most directly through the stability metrics. Reliable tests catch regressions before they ship, lowering change failure rate, and fast, trustworthy tests keep the feedback loop short, which shortens lead time. Flaky and slow tests do the opposite — they delay releases and let real failures hide in the noise.

Which DORA metric does testing influence most?

Change failure rate. It’s the most direct measure of whether your testing catches problems before production. Reducing flakiness and improving coverage of critical paths moves it more than almost anything else QA does.

What should QA teams measure to improve DORA?

Track leading indicators that feed DORA: flake rate (trust in the suite), mean time to detection (how fast tests catch a defect), and CI feedback-loop time (how fast developers get a result). Improving these shows up downstream in change failure rate and lead time.