> 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/reading-and-using-a-view.md).
# Reading & Using a View
This guide explains how to navigate, interpret, and act on the data in a Coverage Analysis view, once a view has been created and is ready to use.
***
### Opening a View
Open **Coverage Analysis** from the main navigation. Use the view selector at the top of the page to switch between any views that have been created for your organization. The **"Data as of"** timestamp, that appears on the same line as the view selector, shows when the currently displayed view was last calculated.
***
### Understanding the View Header
The header displays a summary of the view's configuration at a glance: the active Date Range, Code Scope, and Test Scope. When multiple values are selected for a field, the first is shown with a "+N" indicator, hover over it to see the full list. For rolling date ranges (e.g., "Last 7 days"), hovering also shows the actual calculated dates that the range currently covers.
***
### Reading the Metric Cards
**Coverage metric card** Displays the aggregated coverage percentage for the current scope and any active filters, visualized as a percentage bar alongside the count of tested methods, total methods, and uncovered methods.
If both Overall Coverage and Change Coverage were included in the view, they appear as switchable tabs. Click between them to compare both perspectives.
**Failed Tests metric card** *(shown when included in the view)* Shows the total count of unique failing tests and the percentage of failing tests relative to all unique tests run within the scope. A failing test that runs multiple times is counted once and only if failed in its last run - this reflects how many distinct test failures exist, not how many times they occurred.
***
### Analyzing by Test Stage
Click the **Test Stages tab** in the main content area to see a breakdown of coverage per test stage.
Each row shows the test stage name, its coverage percentage, uncovered method count, and failing test count. Stages are sorted by highest coverage by default. Re-sort by lowest coverage to surface the stages with the most gaps and prioritize where to investigate.
**Test Optimization indicator** If Test Optimization was active for a stage during the selected period, an indicator appears on that row, when looking on Overall Coverage view. A tooltip explains that Test Optimization intentionally runs a subset of tests per cycle, which can result in lower-than-expected coverage numbers, this reflects the optimization strategy, not a gap in your test suite.
**Drilling into a test stage** Click any test stage to open a detail panel on the right with two tabs:
* **Coverage tab**: a method-level breakdown of coverage for that stage, grouped by application. Toggle to show only uncovered methods to focus on gaps. Each method row shows its line number and a direct link to the source file in your SCM (GitHub, GitLab, Bitbucket, etc.), so you can navigate straight to the code. The Contributors shows who last modified each method, useful for knowing who to follow up with about a coverage gap. Export the full list as CSV using the download option.
* **Failed Tests tab**: the list of unique tests that are currently failing for this stage, within your current scope and date range.
***
### Analyzing by Application
Click the **Apps tab** in the main content area to see a breakdown of coverage per application.
Each row shows the application name, its aggregate coverage percentage, total method count, and uncovered method count. Sort by lowest coverage to identify which services are most at risk.
**Drilling into an application** Click any app to open a detail panel showing a column per test stage plus an aggregated "All Test Stages" column. This cross-stage view makes it easy to see whether an app has low coverage uniformly or only in specific stages, a much more actionable picture than the aggregate number alone.
Method-level data within the app detail includes SCM links and contributor information, consistent with the test stage detail view. Export the full method table as CSV using the download option.
***
### Filtering Within a View
The filter panel on the left side of the view lets you narrow the view's data by Lab or by Test Stage, without changing the view's underlying configuration. Filters are personal: your filter state is saved and persists across sessions, and it doesn't affect what other users see.
Use filters when you want to focus on a specific subset of the view's data. For example, isolating a particular lab or removing test stages that aren't relevant to your current focus.
{% hint style="info" %}
Lab appears as a filter option only when Code Scope is using the by Lab approach.
{% endhint %}
***
### Exporting a View
Both export formats respect any filters you've applied in the left-side panel.
**CSV export** A full method-level export including: App, File Path, File Name, Method name, Line Number, and a column per test stage showing coverage status for each method. When Change Coverage is included in the view, additional columns show a "Changed" indicator and a Contributors column.
Use CSV exports for deeper analysis, sharing specific gap data with engineers, or feeding coverage data into external reporting or dashboards.
**PDF export** A formatted report of the complete view, structured as: Summary metrics → Change Coverage by test stage and by app (if included) → Overall Coverage by test stage and by app → Failed Tests list.
Use PDF exports for stakeholder updates, sprint review documentation, release sign-off records, or recurring status reports.
***
### Data Freshness
Coverage Analysis views are recalculated automatically every 15 minutes, as long as the view has been accessed within the last 30 days. The **"Data as of"** timestamp in the view header tells you exactly when the last successful update occurred, so you always know how current the data is.
Views that haven't been opened in over a month resume update the next time they are opened.
***
### Tips for Getting the Most from a View
**Use the filter panel to focus, not to reconfigure.** Filters are great for temporarily narrowing a shared view to your team's specific labs or stages. If you regularly need a permanently different scope, consider creating a dedicated view instead.
**Sort by lowest coverage first.** Whether you're in the Test Stage tab or the App tab, sorting ascending immediately surfaces your highest-risk areas without having to scan the whole list.
**Use SCM links to act on gaps immediately.** The direct links from uncovered methods to source files remove the friction of tracking down where a gap actually is. Combined with the contributor column, you have everything you need to follow up in one place.
**Export before a release, keep it on file.** A PDF export of a fixed-date release view is a lightweight, shareable record of what coverage looked like at the time of the release decision. It takes one click and can be valuable for retrospectives and compliance purposes.
**Check the "Data as of" timestamp before sharing numbers.** If you're presenting coverage data in a meeting or report, confirm the timestamp is recent. If the view hasn't refreshed recently, open it and give it a moment to update before exporting.
---
# 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/reading-and-using-a-view.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.