The Seven Testing Principles
Seven statements, agreed on by the testing community over decades, that describe what testing can (and cannot) achieve. They come up constantly in the CTFL exam - and in real testing work.
~7 min read
The seven principles, explained
Testing shows the presence of defects, not their absence
Testing can confirm that defects exist by revealing failures, but it can never prove that a system is completely defect-free - it can only show that no defects were found by the tests that were run. Passing every test reduces the probability of undiscovered defects, but it is not proof of correctness.
A login form passes all 20 of your test cases. That tells you those 20 scenarios work - it says nothing about the 21st scenario nobody thought to test (e.g. pasting a password with a trailing space).
Exhaustive testing is impossible
Testing every possible combination of inputs, preconditions, and paths through a system is infeasible for anything beyond trivial software. Instead of trying to test everything, testers use risk analysis and test techniques to decide what to test and how much testing is enough.
A form with 5 independent fields, each accepting 100 possible values, already has 100^5 (10 billion) input combinations - clearly nobody is testing all of them before every release.
Early testing saves time and money
Defects are cheaper to fix the earlier they are found. A requirements defect caught in a review costs far less to correct than the same defect discovered after the system has been built, tested, and released - by then it may have caused design and code to be built on a flawed foundation. This is why test activities should start as early as possible in the software development lifecycle (SDLC) - a practice known as "shift left".
A misunderstood requirement caught during a requirements review takes an hour to clarify. The same misunderstanding, discovered only after the feature ships to production, can mean re-architecting a module and re-testing everything that depends on it.
Defects cluster together
In most systems, a small number of modules contain most of the defects, or are responsible for most of the operational failures. This is sometimes called the Pareto principle applied to defects (roughly 80% of the problems are found in 20% of the modules). Recognizing where defects cluster helps testers focus their effort where it matters most.
A payments module that was rushed under a tight deadline turns out to account for 60% of all production defects across the whole application - it deserves proportionally more test effort than a rarely-touched settings screen.
Beware of the pesticide paradox
If the same set of tests is repeated over and over without change, it eventually stops finding new defects - just as pests eventually become resistant to the same pesticide. The code paths those tests exercise have already been proven correct; any remaining defects are simply outside what those specific tests can see. To keep finding new defects, test cases need to be regularly reviewed, varied, and extended.
A regression suite that has run unchanged for a year keeps passing, but a real defect slips into production - because the suite only ever tested the same handful of paths, never expanding to cover new edge cases introduced by recent changes.
Testing is context dependent
There is no single "correct" way to test - the right approach depends on the context: the type of system, the level of risk, applicable regulations, and the goals of the stakeholders. Testing a safety-critical medical device demands far more rigor (and different techniques) than testing an internal admin dashboard used by three people.
An e-commerce checkout flow is tested primarily for correctness and usability under real payment loads, while flight-control software for an aircraft is tested exhaustively against formal safety standards - both are "well tested", but the approach and depth differ enormously.
Absence-of-defects is a fallacy
Fixing every defect found during testing does not guarantee a successful system. If the system does not do what users actually need, or does not meet business requirements, it can still fail even with zero known defects. Verifying the system meets requirements (verification) is not the same as confirming it meets the real needs of its users (validation).
A team fixes every bug reported during testing and ships a perfectly stable app - but it automates the wrong workflow entirely, because nobody validated it against what users actually needed. Zero defects, but still the wrong product.
Key points to remember
- Testing can show defects exist; it can never prove a system is defect-free.
- You cannot test everything - use risk to decide what matters most.
- The earlier a defect is found in the SDLC, the cheaper it is to fix (shift left).
- Focus extra testing effort on the modules where defects tend to cluster.
- Repeating identical tests forever eventually stops finding new defects - vary them (pesticide paradox).
- How you test should match the context - there is no one-size-fits-all approach.
- Zero known defects does not mean the system meets real user needs (verification vs. validation).
Terminology
A few terms from this topic worth knowing precisely.
The tendency for an unchanged, repeated test suite to eventually stop finding new defects - just as pests grow resistant to the same pesticide - unless test cases are regularly reviewed and varied.
Checking that a product conforms to its specified requirements - "did we build it right?"
Checking that a product meets the user's actual needs in its real operating environment - "did we build the right thing?"
The underlying flaw or root cause present in a work product, such as a contradiction in a requirement or a bug in code.
Summary
The seven testing principles exist to keep expectations about testing realistic: testing reduces risk and builds confidence, but it can never prove a system is perfect, cover every possible input, or replace understanding what users actually need. Use them as a checklist whenever an exam question - or a real conversation with a manager - claims testing can "guarantee" something absolute.
| Principle | One-line memory hook |
|---|---|
| 1. Presence, not absence | Tests find bugs, never prove "zero bugs" |
| 2. Exhaustive testing impossible | Can't test everything - use risk to choose |
| 3. Early testing saves money | Shift left - catch it before it's built on |
| 4. Defects cluster | 80/20 rule - test the risky modules harder |
| 5. Pesticide paradox | Same tests forever = stop finding bugs - vary them |
| 6. Context dependent | How you test depends on what you're testing |
| 7. Absence-of-defects fallacy | Zero bugs ≠ the right product (verify vs. validate) |
Check your understanding
10 quick questions - click an option to see if you got it right.