How We Got a Client to 95% Release Coverage

A SaaS client came to us already running manual QA on every release. The problem was not that nothing got tested, it was that nobody could say what percentage of the product actually had coverage, and the untested share was exactly where nearly every production incident kept originating.

What does it actually take to reach 95% release coverage?

Reaching 95% release coverage takes a real coverage map before anything else, a documented picture of every critical path and whether a test actually exists for it, not a guess. Without that map, a team adds tests to whatever feels most urgent that week and never closes the gaps actually causing incidents.

Where the coverage gap was actually hiding

The team's instinct was to test new features thoroughly, which felt like good practice and looked fine in every sprint retro. The blind spot was everything already shipped and considered done. Production incidents kept originating in code nobody had looked at in months, not in the features getting the most current attention, since working and recently tested had quietly become the same assumption.

What changed, in order

• A full coverage audit mapping every critical path against existing test cases, so the team could see the real percentage for the first time instead of estimating it
• Coverage gaps prioritized by risk and production incident history, not by which feature was newest or most requested
• Test cases written for the highest-risk gaps first, closing the areas actually causing incidents
• Automated regression layered onto the newly mapped stable paths, so coverage did not quietly erode as the product kept changing
• Coverage tracked and reported every release, so the number stayed real instead of becoming a one-time snapshot

The result

Coverage climbed from an unmeasured guess to 95% within two quarters, tracked release over release instead of assumed once and forgotten. Production incidents originating from previously untested areas of the product dropped sharply within the same window, since those were precisely the paths the coverage map had surfaced as gaps.

What 95% coverage does not mean

A coverage percentage only means as much as the tests behind it. A suite that checks that a page loads without checking that the data on it is correct will report high coverage and still let real defects through. The number mattered less to this engagement than the map behind it, since the map is what made 95% an honest figure instead of a vanity metric.

This is the same pattern we track across embedded engagements broadly, coverage that climbs toward the 95% mark once a team can actually see its own gaps, not because more tests get written for their own sake, but because the team finally knows which ones are worth writing.