Arjun Nair
Two hours in a sprint can vanish when someone says, "I only need to update the tests." Fast-moving engineering teams know this pattern. Keeping a suite aligned with the product takes more time as the product changes, while the suite's protective value does not keep pace. Most teams never account for that cost deliberately.
We began tracking this with teams in our early-access program. The pattern was consistent: teams estimated that test maintenance took 15 to 25 percent of each engineer's sprint time. The result surprised them. They knew tests required time, but not how much.
What counts as test upkeep
The lost hours are seldom obvious. Planned suite updates appear in retrospectives and sprint reviews. More often, maintenance drains time through smaller channels.
A UI refactor requires selector changes. A third-party component changes its output and breaks a passing test. A performance improvement makes an end-to-end test flaky by shortening the delay it expects. A new API field breaks a test tied to the old response shape. These feel less like maintenance than interruptions.
Interruptions compound. An engineer pauses feature work to fix a CI failure, changes the selector, runs the suite locally, pushes the fix, and then tries to recover their place. That context switch costs at least 20 minutes, often more. Multiply that by the number of interruptions in a two-week sprint.
Why maintenance worsens
A new suite built against a stable product has little upkeep overhead. That cost increases as product velocity rises.
More daily deploys create more chances for tests to drift from the product. More features expand what the suite must cover. More engineers make parallel changes more likely, so a UI update can break a test written by someone who did not know it existed.
Eventually, maintenance exceeds what the team can absorb. The usual response is to mark tests skipped or pending, planning to return later. That rarely happens. The skipped total grows, and CI becomes faster because fewer tests run. It feels positive until a real regression reaches production.
The hidden accounting gap
Teams budget for test writing within feature work. A feature takes four days: two for implementation, one for tests, and one for review and CI fixes. Maintenance appears in none of those estimates. It gets absorbed by feature time, making features seem slower and hiding the suite's actual cost.
This is not a team failing. It is an accounting gap in the system. When a cost stays hidden, teams naturally cut what looks expensive. They write fewer tests, skip coverage for some feature types, and begin treating the suite as aspirational instead of authoritative.
The alternative is to expose the cost. Some teams add a specific "test tax" estimate: with each PR, the author predicts how many existing tests will require updates. That figure enters sprint planning and raises a useful question: if a change breaks eight existing tests, is the feature scoped properly?
Where upkeep costs most
Tests do not all cost the same to maintain. End-to-end tests using the rendered UI cost the most because they depend on selector stability, timing, network behavior, and the rendering pipeline. A change in any of these areas puts the test at risk.
Unit tests for pure functions need almost no upkeep. The function signature defines the contract. When that contract changes, the test breaks, as it should. Maintenance effort rises with the number of outside dependencies.
Most teams do not design suites around upkeep cost. They write the test that feels natural for the feature at hand. Over time, high-maintenance tests accumulate because those tests often feel most like real testing.
What automation changes
We added repair to TestSprighte before test generation because upkeep, not initial test writing, is the bottleneck.
When a React refactor shifts a selector, an autonomous agent can spot the change, find the replacement in the DOM, and update the assertion without human help. The test continues to pass, the engineer avoids the interruption, and the suite stays current without using sprint capacity.
Manual test maintenance is not an engineering failure. Treating it as an invisible background cost is a planning failure. Teams can expose and manage the cost, or let it build quietly until the suite is too expensive to maintain and is abandoned. Both choices have a price. One simply remains hidden until the consequences arrive.