Tracking Coverage During a Sprint

Best for: QA Engineers, QA Managers

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.