False Positive vs False Negative (Testing)

Borrowed from statistics and medicine, these terms map directly onto test results.

False positive — the test fails, but the software is fine. Usually caused by a flaky test, a brittle selector, or an assertion that's stricter than it needs to be. The cost is wasted investigation time and, eventually, people ignoring failures.

False negative — the test passes, but the software is actually broken. Usually caused by a weak assertion (checking that something ran, not that it produced the right result), an over-mocked dependency that hides the real bug, or coverage that simply doesn't reach the broken code. The cost is a bug reaching production despite "all tests passing."

Which is worse

False negatives are more dangerous because they create false confidence — the team believes it's covered when it isn't. False positives are more corrosive over time because they train people to distrust and ignore the suite, which eventually produces more false negatives too (nobody's looking closely at failures anymore).

In practice

Reduce false positives by fixing the root causes of flakiness — see why E2E tests get flaky. Reduce false negatives by asserting the actual outcome, not just that a step completed, and by not over-mocking — see mock vs stub vs fake. Autonomous testing reduces false positives structurally, since there's no brittle script to misfire, but a plain-English check is still only as strong as the outcome you tell it to verify.