> 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/coverage-and-quality-insights/coverage-analysis.md). # Coverage Analysis

Coverage Analysis is a unified quality dashboard in SeaLights that gives your entire team a single, shared view of code coverage across your application. Modern applications span many services and test stages, and getting a clear answer to "are we covered?" has traditionally meant either deep infrastructure knowledge or significant manual effort stitching reports together. Coverage Analysis removes that friction. It lets you: * **Aggregate coverage across services** without needing to know every branch and lab configuration by heart. * **Surface failing tests alongside coverage** so quality risks are visible in context, not in a separate report. * **Share a consistent view** so everyone (QA Engineers, QA Managers, Release Managers) is looking at the same data, always up to date. *** ### Who It's For

Role	Primary Value
QA Engineer	Drill into uncovered methods, identify gaps by test stage, trace issues to specific contributors and code files
QA Manager	Monitor coverage trends across the team, track sprint and release progress, catch quality risks before they become blockers
Release Manager	Confirm release readiness with a single consolidated view of coverage and failing tests across all services and test stages

*** ### Key Concepts **Views** A view is a saved configuration that defines what data Coverage Analysis shows. Each view has a name, a set of metrics, a date range, a code scope, and a selection of test stages. Views are shared across your team and stay up to date automatically. **Metrics** Three metrics can be included in any view: * **Overall Coverage:** what percentage of all methods in scope were executed by tests during the selected period. * **Change Coverage:** what percentage of *modified* methods were tested. This is the right metric when you want to know whether the code you changed was covered, not just the codebase as a whole. * **Failed Tests:** how many unique tests are currently failing. Always shown in context alongside coverage data. **Code Scope** Defines which services and branches are included in the view. You can scope by Lab (the environment where tests run), which automatically pulls in the associated services, no need to manually list every app and branch. **Date Range** Controls the time window for coverage data. Ranges can be rolling (e.g., always "last 7 days"), open-ended from a start date (useful for an in-progress sprint), or fixed (useful for reviewing a completed release). *** ### How It Fits Into Your Workflow Coverage Analysis is a cross-cutting, team-level view. Use it: * **During a sprint** to track whether new and modified code is being tested as development progresses. * **Before a release** to confirm coverage across all services and test stages in scope. * **After a deployment** to review what was covered during the release window. * **On an ongoing basis** as a shared quality dashboard that your team checks regularly. Views are automatically updated so they always reflect the latest data. The "Data as of" timestamp in the header tells you exactly when the view was last updated. *** ### Ready to Get Started? If you're new to Coverage Analysis, the best next step depends on what you're trying to accomplish. The **Coverage Analysis Playbooks** offer step-by-step guidance for the most common team scenarios, from sprint tracking and release readiness to ongoing quality monitoring, each with recommended configurations and success metrics to help you measure progress over time.

	Cover image
Playbook 1: Tracking Coverage During a Sprint	/files/bif5CAcljDiH374XfUkQ	https://docs.sealights.io/knowledgebase/guides/quality-improvement/coverage-analysis-playbooks/tracking-coverage-during-a-sprint
Playbook 2: Confirming Release Readiness	/files/eFak515Dgmvzr3u2ZLE8	https://docs.sealights.io/knowledgebase/guides/quality-improvement/coverage-analysis-playbooks/confirming-release-readiness
Playbook 3: Monitoring Ongoing Quality as a Team Dashboard	/files/hJwHxvTX8ERZ1EFNU9oQ	https://docs.sealights.io/knowledgebase/guides/quality-improvement/coverage-analysis-playbooks/monitoring-ongoing-quality-as-a-team-dashboard

For a full reference of every feature and configuration option, see the [Creating & Editing a View](/knowledgebase/coverage-and-quality-insights/coverage-analysis/creating-and-editing-a-view.md) and [Reading & Using a View](/knowledgebase/coverage-and-quality-insights/coverage-analysis/reading-and-using-a-view.md) pages. --- # 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/coverage-and-quality-insights/coverage-analysis.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.