Confirming Release Readiness
Best for: QA Managers, Release Managers
The Situation
A release is approaching. You need to answer a simple but high-stakes question: are all the services going into this release adequately tested, and are there any failing tests that should block the deployment? Historically, getting this answer has meant chasing down coverage numbers from multiple teams, combining reports manually, and hoping nothing was missed. The risk is that gaps only surface after the release, when the cost of fixing them is highest.
How Coverage Analysis Helps
Coverage Analysis gives you one view that consolidates the answer across every service and test stage in your release scope. You define the release window as a fixed date range, select all the relevant test stages, and the view assembles the full picture automatically.
Coverage is shown both in aggregate and broken down by service and by test stage, so you can immediately see whether a specific app or a specific stage is the source of a gap, rather than seeing a combined number that masks the detail.
Failing tests are surfaced right alongside coverage data, so the two signals you need for a release decision, "was it tested?" and "are the tests passing?", are visible in the same view. After the release, that same fixed-date view becomes a permanent record of what coverage looked like at the time of the decision.
Recommended View Configuration
Date Range
Fixed [release start → release end]
Code Scope
All services in the release (via Lab or Saved Scope)
Test Stages
All stages in the release validation pipeline
Metrics
Overall Coverage + Change Coverage + Failed Tests
Code Changes Baseline
Previous release date or branch cut date
Review the App tab to identify any service with coverage below your release threshold. Review the Test Stage tab to confirm all required stages ran and have acceptable coverage. Check the Failed Tests count — any non-zero count warrants investigation before sign-off.
Share the view with your team or export it as a PDF for inclusion in your release documentation.
Success Metrics to Watch
Overall Coverage % at Release
The most direct readiness indicator. Most teams set a minimum threshold that must be met before a release is approved to proceed.
Common industry thresholds: 70–80% overall coverage for production releases is a widely used baseline. High-criticality systems (financial, medical, infrastructure) often require 85–90%+.
What to track over time: Compare this number release-over-release. A stable or improving trend indicates the team is sustaining quality as the codebase grows. A declining trend across releases is an early warning that test investment isn't keeping pace with development velocity.
Change Coverage % for This Release
Specific to the code that changed in this release cycle. A release with high overall coverage but low change coverage is shipping code that wasn't adequately tested in this cycle, which is where release-specific risk lives.
Target: 75%+ change coverage for the release window is a strong signal that new and modified code was tested before shipping.
Failed Test Count at Release
The ideal number at release sign-off is zero, or a documented, understood set of known failures that have been explicitly accepted. Any unexpected failures should be investigated, not ignored.
Track trend: Is the number of failing tests at release increasing or decreasing over time? A downward trend indicates improving test health. A flat or growing count may indicate test debt accumulating faster than it's being addressed.
Time to Release Confidence
How long does it take from "release candidate declared" to "confident to ship"? Teams using Coverage Analysis for release readiness typically reduce this time because the consolidated view eliminates the manual effort of assembling coverage data from multiple sources.
Post-Release Defect Rate
The ultimate lagging indicator. Over time, track whether releases with higher change coverage at the time of shipping correlate with fewer post-release defects. This is the clearest evidence of the business value of investing in test coverage.
Last updated
Was this helpful?