Coverage gap review

How it works

Code coverage says which lines ran, not which behaviours or risks were checked. The model reads the test suite — test names, assertions, and the test plan if there is one — alongside the requirements and the risk list, and maps one to the other: which requirements have tests that actually assert on them, and which risks are only touched incidentally. Reading assertions rather than test names matters, since a test called "validates discount" may assert only that the page loaded. The result is a short list of gaps with the reasoning behind each, ready for a decision about which to fill.

When to use it

Before a release, as a check on whether testing matched the risk; when inheriting a test suite; after a large change, to see whether tests kept up; and when a production defect raises the question of what else the suite isn't checking.

Limitations

The mapping depends on the model understanding both the tests and the requirements, and either can be misread; a gap it reports may be covered by a test it didn't connect, and a test it counts as coverage may not check what matters. Manual and exploratory testing usually leaves no artefact the model can read, so gaps it reports may already have been explored. Large suites don't fit in context and get sampled.

Before you reach for it

Tag each test with the requirement or risk it checks when it’s written, so the map is kept up to date rather than reconstructed later.

What you still own

Verifying each reported gap, and deciding which gaps to close and which to accept.

Cite this