> 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/coverage-analysis-faq.md).

# Coverage Analysis FAQ

### Access & Permissions

<details>

<summary><strong>Who can create and manage views?</strong> </summary>

Users with Admin or DevOps roles can create, edit, and delete views. All other users can access, filter, and export any view that has been created for them, no special permissions needed to use a view.

</details>

<details>

<summary><strong>Can I see coverage data for all apps in a view, regardless of my permissions?</strong> </summary>

No. Coverage Analysis respects your existing app-level permissions. If a view includes apps you're not authorized to see, those apps are excluded from the data and metrics displayed to you. A banner at the top of the view will notify you that some data has been restricted. The metrics you see accurately reflect only the apps you have access to.

</details>

<details>

<summary><strong>Can I edit or delete a view someone else created?</strong> </summary>

Users with DevOps role can edit and delete any view. Other users can only edit and delete views they created themselves.

</details>

***

### Metrics

<details>

<summary><strong>What is the difference between Overall Coverage and Change Coverage?</strong> </summary>

Overall Coverage tells you what percentage of all methods in your scope were executed by tests during the selected period - it's a broad picture of your codebase's test health. Change Coverage narrows this to only the methods that were modified during the selected window. It answers a more targeted question: "Did we test the code we actually changed?".\
These two metrics serve different purposes.

</details>

<details>

<summary><strong>Why would I use Change Coverage instead of Overall Coverage?</strong> </summary>

High overall coverage does not guarantee that recently modified code was tested. A codebase can have 80% overall coverage while new and changed features have little to no coverage, because the existing tests cover stable, unchanged code. Change Coverage surfaces this distinction, making it the right metric for sprint-level quality validation and change risk assessment.

</details>

<details>

<summary><strong>Can I include both Overall Coverage and Change Coverage in the same view?</strong> </summary>

Yes. When both are selected during view creation, the view shows them as switchable tabs. You can compare both perspectives without needing separate views.

</details>

<details>

<summary><strong>What does the Failed Tests count represent?</strong> </summary>

Failed Tests shows the number of *unique* tests that are currently failing (or their last run) within your scope and date range, not the total number of test executions that failed. A test that fails repeatedly in multiple runs is counted once. This gives you a clearer sense of how many distinct issues exist, rather than how many times they occurred.

</details>

<details>

<summary><strong>Why does my overall coverage look lower than expected when Test Optimization is active?</strong> </summary>

Test Optimization intentionally runs only a subset of tests per cycle to save time and resources. Because not every test runs in every cycle, not every method gets executed in every reporting period, which can result in a lower overall coverage number. This is expected behavior, not a gap in your test suite. An indicator appears next to any test stage where Test Optimization was active, with a tooltip explaining the impact.

</details>

***

### Scope & Configuration

<details>

<summary><strong>What is the easiest way to define my application scope?</strong> </summary>

The simplest approach is to select a Lab. Since labs are deployed with the services your team works on, selecting the relevant lab automatically includes all associated services, without needing to manually list every app, branch, or configuration. If you need more precise control, you can define a custom scope using App, Branch, Lab, or Code Label filters and save it for reuse.

</details>

<details>

<summary><strong>Can I reuse the same code scope across multiple views?</strong> </summary>

Yes. You can create a Saved Scope and apply it to as many views as you like. This is useful for teams or product areas that have a consistent scope definition they want to use across sprint, release, and monitoring views.

</details>

<details>

<summary><strong>Can I delete a saved code scope?</strong> </summary>

Only if it isn't linked to any active views. A saved scope used by one or more views is protected from deletion. To delete it, you first need to remove or reconfigure the views that reference it. Deletion is done from the Coverage Dashboard.

</details>

<details>

<summary><strong>What is the difference between the date range modes (Last, Since, Fixed)?</strong></summary>

* **Last** is a rolling window - "Last 7 days" always means the 7 days ending right now, updating automatically as time passes. Best for ongoing monitoring.
* **Since** grows forward from a fixed start date to the present - useful for tracking an in-progress sprint or release from its kickoff until now.
* **Fixed** is a locked period with a defined start and end - useful for reviewing a completed sprint, pre-defining a release window or a planned testing period before it concludes.

</details>

<details>

<summary><strong>Can the change baseline for Change Coverage be different from the date range?</strong> </summary>

Yes. When Change Coverage is enabled, you can set the change baseline independently - either tied to the start of the date range, or set to a specific reference date such as a previous release or sprint start. This lets you, for example, measure test results over the past two weeks while measuring changes relative to the last release date.

</details>

***

### Views & Data

<details>

<summary><strong>Are views shared with my whole team?</strong> </summary>

Yes. Views are shared across all users in your organization. Anyone can open any view from the view selector. Filters applied within a view are personal, each user's filter state is saved independently and doesn't affect what others see.

</details>

<details>

<summary><strong>Can two views have the same name?</strong> </summary>

Yes. There is no uniqueness requirement on view names, so teams can use naming conventions that work for them (e.g., "Sprint 44 – Payments Team" alongside "Sprint 44 – Auth Team").

</details>

<details>

<summary><strong>How current is the data in a view?</strong> </summary>

Views refresh automatically every 15 minutes, as long as the view has been accessed in the past month. The **"Data as of"** timestamp in the view header shows when the last successful refresh occurred.

</details>

<details>

<summary><strong>What happens if I leave the page while a view is being generated?</strong> </summary>

Generation continues in the background. You can navigate freely within SeaLights while the view processes. When it's ready, it will be available in the view selector. If you return to Coverage Analysis before it finishes, the view is shown with a "Generating" status so you know it's still in progress.

</details>

<details>

<summary><strong>What if a view fails to generate?</strong> </summary>

An error message will appear in the main area with an option to regenerate. Clicking it retries the generation using the same configuration, no need to reconfigure the view from scratch.

</details>

***

### Exports

<details>

<summary><strong>What does the CSV export include?</strong> </summary>

A full method-level table with: App, File Path, File Name, Method name, Line Number, and a column per test stage showing whether each method was covered. If Change Coverage is included in the view, additional columns show whether each method was changed and who the contributors are.

</details>

<details>

<summary><strong>What does the PDF export include?</strong> </summary>

A formatted report organized as: Summary metrics → Change Coverage breakdowns (by test stage and by app) → Overall Coverage breakdowns (by test stage and by app) → Failed Tests list. Both export formats reflect any filters you've applied in the left-side panel.

</details>

<details>

<summary><strong>Who can export a view?</strong> </summary>

Any user with access to Coverage Analysis can export any view, regardless of whether they created it.

</details>


---

# 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/coverage-analysis-faq.md?ask=<question>&goal=<endgoal>
```

`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.