Test Coverage
Test coverage measures how much of an application has actually been exercised by tests — as a percentage of code lines, branches, requirements, or user flows, depending on what's being measured. High coverage reduces the odds of untested code shipping with a hidden defect, but it's a proxy for risk reduction, not a guarantee of quality on its own.
There are several different things people mean by "coverage," and mixing them up causes confusion: code coverage measures which lines or branches of source code were executed during tests; requirements coverage measures which documented requirements have at least one test case; functional coverage measures which user-facing features or flows have been tested.
The trap with coverage numbers is treating them as a quality target instead of a risk signal. A test suite can hit 90% code coverage while asserting almost nothing meaningful — every line executed, but no assertions checking the output was correct — because coverage measures what ran, not what was verified. It's most useful as one input among several, alongside defect trends and manual risk assessment, not as the single metric a team optimizes for.
