Test coverage percentages hide a risk that has nothing to do with how many tests exist.

TL;DR

• A test suite can report high coverage and still carry serious risk if only one person actually understands why the tests are structured the way they are.
• Coverage percentage measures whether code executed during a test run. It says nothing about whether the knowledge to maintain, extend, or trust that suite is spread across more than one person.
• When that person leaves, goes on leave, or moves to another team, the suite doesn’t get worse immediately. It gets worse the first time someone else has to change it.
• This is a bus-factor problem, not a test-quality problem, and it hides behind a coverage number that looks fine right up until it doesn’t.
• The fix isn’t documentation for its own sake. It’s making the suite’s logic legible enough that a second person can safely modify it without the original author in the room.
• Teams that treat test-suite knowledge as a single-person asset are one departure away from a suite nobody can safely touch.

A test suite reports 87% coverage. Leadership is satisfied. Then the one engineer who built most of it takes two weeks of leave, and a routine feature change needs a test updated. Nobody else on the team is confident touching it: the test uses a custom helper function only that engineer fully understands, structured around assumptions nobody else wrote down. The team ships the feature with the test left broken, planning to fix it “when she’s back.” Coverage stays at 87% on paper. In practice, it just started lying.

This is not a story about that engineer doing bad work. The suite she built may be well-designed. The story is about what “coverage” doesn’t measure: whether more than one person can maintain what the number represents.

Coverage percentage measures the wrong thing

Test coverage is calculated by asking whether a line, branch, or function executed during a test run. It’s a mechanical measurement, and it’s useful for what it measures. It says nothing about whether the tests are understandable to anyone besides the person who wrote them, whether the reasoning behind a specific test case is documented anywhere, or whether a second engineer could modify that test safely without breaking its intent.

A suite at 90% coverage maintained by one person who understands every test is, on paper, indistinguishable from a suite at 90% coverage that person built using patterns nobody else follows, naming conventions nobody else was consulted on, and edge-case logic that exists only in their head. The coverage tool can’t tell these two suites apart. The risk profile is completely different.

The gap shows up at the worst possible moment

Single-person dependency doesn’t cause problems while that person is present and available. It causes problems specifically when they’re not, and it’s rarely a planned absence that reveals it first. A support ticket comes in on a day the suite’s primary maintainer is out. A hotfix needs a test updated under time pressure. A reorg moves that engineer to a different team with no handoff built into the transition.

In each case, whoever is left has to open a test suite they didn’t build, decide whether it’s safe to change, and usually can’t answer that question with confidence. The two common responses are both costly: skip the test change and ship anyway, which quietly degrades the coverage number’s honesty, or spend hours reverse-engineering the original author’s logic under time pressure, which is exactly the kind of slow, expensive work automated testing was supposed to prevent.

Neither response shows up in a coverage report. Both are the actual cost of the single-person dependency, and both are invisible until the specific moment that forces them into view.

Why this gets worse as suites grow

The risk compounds with scale, not because more tests are inherently riskier, but because a growing suite maintained by a shrinking circle of people who truly understand it means an increasing share of that suite is effectively opaque to everyone else on the team. A five-person QA team where two people understand 90% of the suite between them isn’t meaningfully safer than a one-person dependency, if those two people tend to be out, busy, or reassigned at the same times.

This is also why the problem is easy to miss during normal operation. Everything works fine as long as the people who understand the suite are present and have bandwidth. The gap is only visible in the specific moments it matters, which means teams often discover it during an incident rather than during a calm planning cycle where fixing it would be cheap.

What actually closes the gap

The fix isn’t a mandate to “write more documentation,” which tends to produce documentation nobody reads and doesn’t survive the next round of test changes. The real fix is making the suite’s logic legible by construction: structuring tests so their intent is visible from the test itself, not from a comment or a separate doc that drifts out of sync, and reviewing test changes with the specific question of whether someone outside the original author’s head could maintain this.

A practical test: pick a test case at random and ask someone who didn’t write it to explain, without asking the author, what it verifies and why. If they can’t, that test represents single-person risk regardless of what the coverage dashboard says. Doing this exercise periodically, across the suite, surfaces exactly where the dependency actually lives, which is usually a smaller, more specific set of tests than “the whole suite,” and therefore a more tractable fix than it first appears.

Coverage percentage will keep measuring what it measures. The question underneath it, whether more than one person actually understands what that percentage represents, needs its own answer, on its own schedule, before the day it gets forced into view.

Sources

• ISTQB (International Software Testing Qualifications Board), material on test coverage metrics and their limitations
• Google Testing Blog, internal engineering writing on test readability and maintainability
• World Quality Report (Capgemini / Sogeti), sections on QA team structure and knowledge concentration risk