Pesticide paradox
The pesticide paradox is the software testing principle that running the same tests repeatedly stops them finding new defects. Boris Beizer's image is the pest and the pesticide: bugs survive a suite that never changes, because the defects it can catch get fixed and the subtler ones it cannot catch are left untouched.
The longer version
A test finds only the faults its inputs and checks can reach. Once those are fixed, the suite passes, and re-running it can only confirm they stay fixed. Every defect that sits outside what the tests exercise remains, and the green result reads as quality when it describes the suite's own reach. The paradox is the gap between a suite that keeps passing and a product that is still being broken by users in places no test ever visited.
It is a different problem from a flaky test, which fails at random and is a reliability fault in the test. It is different too from a regression suite doing its job: a suite that keeps passing because nothing broke is working as intended, and the paradox concerns what that suite never looked at. Regression suites are exactly where it bites, since they are run unchanged for years by design. Exploratory testing is the usual counter, because a person following a hunch goes where the scripts do not.
The signs are a long run of green builds alongside rising defect reports from customers, defects found in code the suite covers on paper, and a suite whose growth is all additions and no revisions. Coverage numbers hide it, because a line can execute during a test without any assertion that would notice it behaving wrongly.
The remedy is deliberate change. Teams review the suite each release, add tests for every escaped defect, vary data and inputs, rotate who writes and runs the tests, and schedule exploratory sessions in areas the scripts treat lightly. Test case prioritization helps at the margin by running the likeliest failures first, but it reorders the same tests, so it does not cure a suite that has stopped looking in the right places.
Common questions
What does the pesticide paradox mean in software testing?
Running the same set of tests again and again stops finding new defects, because the faults those tests can reach have already been fixed. Defects outside their reach remain. The suite keeps passing while the product still has bugs, so the tests have to be reviewed and varied to keep finding them.
Where does the pesticide paradox come from?
Boris Beizer coined it in Software Testing Techniques (1990), observing that every method used to prevent or find bugs leaves a residue of subtler bugs against which that method is ineffectual; the pest and pesticide image is his. The ISTQB Foundation syllabus (2018) lists it as a testing principle, worded as repeated tests eventually no longer finding any new defects. Version 4.0 (2023) renamed that principle "Tests wear out".
How do you avoid the pesticide paradox?
Review and revise the test set on a schedule, add a test for each defect that escaped, vary the data and the paths, let different people write and run tests, and run exploratory sessions in areas the scripts barely touch. The aim is for the suite to change as the product and its failures change.
Does the pesticide paradox mean regression tests are useless?
A regression suite is meant to repeat, and repeating confirms that earlier fixes still hold, which is its purpose. The paradox applies to treating a passing regression run as proof the product is sound. It needs fresh tests beside it, including exploratory ones, to look where it does not.
How can you tell a test suite has stopped finding bugs?
Builds stay green while customers report new defects, escaped defects cluster in areas the suite supposedly covers, and the suite grows only by additions. High code coverage does not rule it out, since executing a line proves nothing about whether any assertion would catch it misbehaving.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.