> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/guides/quality-improvement/coverage-analysis-playbooks/confirming-release-readiness.md). # Confirming Release Readiness {% hint style="success" %} **Best for:** QA Managers, Release Managers {% endhint %} ### 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
SettingValue
Date RangeFixed [release start → release end]
Code ScopeAll services in the release (via Lab or Saved Scope)
Test StagesAll stages in the release validation pipeline
MetricsOverall Coverage + Change Coverage + Failed Tests
Code Changes BaselinePrevious 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.sealights.io/knowledgebase/guides/quality-improvement/coverage-analysis-playbooks/confirming-release-readiness.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.