What Is Test Coverage? Why the Percentage Can Lie

Test coverage measures how much of your application your tests actually exercise, usually expressed as a percentage. It is one of the most cited QA metrics — and one of the most misunderstood. Used well, it points you toward untested gaps. Used as a target, it quietly rewards the wrong behavior.

What coverage actually measures

The most common form is code coverage: the share of your code lines (or branches, or functions) that ran while your tests executed. If your tests touched 750 of 1,000 lines, that is 75% coverage. There is also functional or journey coverage — the share of real user journeys your tests verify — which is often far more meaningful for end-to-end testing.

Why the percentage can lie

Here is the catch that trips up many teams: coverage only measures whether code ran, not whether you checked the result. A test can call every function in a file — driving coverage to 100% — while asserting nothing meaningful about what those functions returned. The number looks perfect; the tests prove almost nothing.

This is the same illusion as a suite of hundreds of green tests sitting on top of a broken checkout, which we unpack in why your app breaks when your tests pass. High coverage with weak assertions is false confidence.

The danger of coverage as a goal

The moment a coverage percentage becomes a mandated target, it stops being a useful measurement. Teams start writing shallow tests purely to hit the number — tests that execute code without verifying behavior, inflating the metric while adding maintenance burden and little real protection. This is a textbook case of a metric becoming a target and ceasing to be a good metric.

How to use coverage well

• Treat it as a gap-finder, not a grade. Low coverage in a critical module is a useful red flag worth investigating. A high overall number is not an achievement on its own.
• Prioritize journey coverage for what matters. Full, well-asserted coverage of your make-or-break journeys beats a high line-coverage number padded with trivial tests.
• Pair it with assertion quality. Always ask not just "did this code run?" but "did the test verify the right outcome?"
• Don't chase 100%. The last stretch is often spent testing trivial code at the expense of more valuable work. Many teams treat 70–80% as a healthy guideline, with the real focus on critical paths.

Coverage and reliability

Coverage and reliability are related: padding coverage with shallow or brittle tests tends to add flakiness and maintenance cost without adding real signal. A smaller suite of meaningful, stable tests is worth more than a large one inflated to hit a number.

What to measure instead

The most honest coverage question is not "what percentage of our code ran?" but "are our critical user journeys genuinely verified?" Mapping those journeys deliberately — covered in mapping critical user journeys — gives you a coverage model tied to business value rather than a vanity metric.

The takeaway

Test coverage is a useful flashlight for finding untested areas, but a terrible scoreboard. Chase verified journeys and strong assertions, not a percentage. QA Guardian focuses coverage where it counts — your critical flows, asserted and reliable — so your number reflects real protection. Book a demo to see your journeys mapped to meaningful coverage.