> 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/tracking-coverage-during-a-sprint.md).
# Tracking Coverage During a Sprint
{% hint style="success" %}
**Best for:** QA Engineers, QA Managers
{% endhint %}
### The Situation
Your team is mid-sprint. Development is active, new code is going in daily, and you want to know whether tests are keeping pace, without waiting until the end of the sprint to find out there are gaps. The risk of discovering coverage holes at sprint close is that there's no time left to address them before the work moves to the next stage.
***
### How Coverage Analysis Helps
Rather than checking each service individually or waiting for a manual report, you create a single Coverage Analysis view scoped to the current sprint. The view updates automatically as tests run, so the coverage you see always reflects the current state of the sprint.
The most useful metric here is **Change Coverage.** It focuses specifically on the methods modified during the sprint, not the entire codebase. This is a much more actionable question than aggregate coverage: "Did we test the code we're actually changing in this sprint?"
If a particular test stage is falling behind, it surfaces immediately in the test stage list. Clicking into it shows you the exact uncovered methods, which apps they belong to, and who last modified each one; giving you the information you need to have a targeted conversation with the right developer.
***
### Recommended View Configuration
Setting
Value
Metrics
Overall Coverage + Failed Tests (optional)
Date Range
Since [sprint start date]
Code Scope
Lab(s) for this sprint's environment
Test Stages
All (or sprint-relevant stages)
Code Changes Baseline
Since date range start date
Once the view loads, use the **Test Stage tab** to see which stages have the lowest change coverage, and drill into any stage to see the specific uncovered methods and their owners.
***
### Success Metrics to Watch
#### **Change Coverage % & How to Read it in Context**
Change Coverage is your primary indicator, but how you interpret it depends heavily on where you are in the sprint and how your team works.
For *modified existing functionality*, automated regression tests typically run close to the change, so Change Coverage for those methods tends to be high from early in the sprint. For *new functionality*, tests often come after the code, sometimes by design. This means Change Coverage can legitimately dip mid-sprint as new code is pushed ahead of its tests, then recover as testing catches up. A mid-sprint dip is not automatically a warning sign, it may simply reflect that development is running ahead of testing, which is normal for many teams.
The curve you should expect also depends on your team's way of working:
* Teams that write tests alongside code will see a relatively stable, gradually improving trend throughout the sprint.
* Teams with a more sequential dev-then-test workflow will see more pronounced dips early and recoveries later.
* Teams with strong existing automation will start with a higher baseline for changed existing code, and gaps will mostly appear around genuinely new functionality.
What matters more than any single data point is the picture at sprint close, and the trend across sprints over time.
#### **Target at Sprint Close**
80% change coverage is a widely used benchmark, and teams with mature test cultures often reach 85%+. Some teams set a lower minimum threshold as a definition-of-done gate while they're building up their testing practice, but the goal should be to trend toward 80% and above over time.
#### **Uncovered Method Count (Changed Methods)**
Track the raw count of uncovered changed methods as the sprint progresses. Expect this number to rise as new code is pushed and fall as tests are written and run. By sprint close, a shrinking or low count is a good signal. A count that remains high at the end of the sprint, not mid-sprint, is the pattern worth investigating.
#### **Failed Test Count** (Optional)
Failing tests that persist across multiple days are a signal of either broken functionality or flaky tests. Both undermine the reliability of your coverage data, a method "covered" by a consistently failing test is not reliably tested.
#### **Coverage by Test Stage**
If one stage (e.g., unit tests) carries nearly all the change coverage while integration or E2E stages contribute very little, that's a structural pattern worth tracking over time, even if the aggregate number looks acceptable. New functionality in particular often needs validation at multiple levels of the testing pyramid.
#### **Improvement Across Sprints**
Compare Change Coverage at sprint close, across the same team and scope, sprint over sprint. A stable or gradually improving trend indicates healthy testing habits. A declining end-of-sprint number across multiple sprints is a stronger signal of concern than any mid-sprint dip.
---
# 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/tracking-coverage-during-a-sprint.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.