01Code coverage
What percentage of code lines/branches are exercised by tests. Reported by test runners (Jest, JaCoCo, etc.). High code coverage is necessary for catching regressions but not sufficient — you can hit 100% and still miss behavioural bugs.
02Requirement coverage
What percentage of stated requirements have at least one test case verifying them. A test management tool tracks this — for each requirement, are there test cases linked, and did they pass.
03Risk coverage
The most useful but least automatable. For the failure modes that would hurt the most (data loss, security, billing errors), are there tests, and have they recently passed? This is what release sign-off should actually evaluate.
04Practical advice
- Use code coverage to find untested code paths, not as a target.
- Use requirement coverage to make sure features have at least one test.
- Use risk coverage as the heuristic for "are we ready to ship?"
05Related
06Frequently asked questions
Is 100% test coverage a good goal?
Almost never, in any of its meanings. 100% code coverage often means you're testing trivial getters; 100% requirement coverage usually misses what the requirements didn't spell out.
What coverage metric matters most?
Risk coverage. Are the high-impact, high-likelihood failure modes tested? That's the only number that actually predicts release confidence.