Coverage Analysis
Coverage Analysis is a unified quality dashboard in SeaLights that gives your entire team a single, shared view of test 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
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 refreshed 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.
For a full reference of every feature and configuration option, see the Creating & Editing a View and Reading & Using a View pages.
Last updated
Was this helpful?