The 7 testing principles
Codified by the ISTQB, these seven principles hold for any language, framework or methodology. Treat them as constraints: a test strategy that ignores one of them will fail in a predictable way.
1Testing shows the presence of defects, not their absence
Testing lowers the probability that defects remain. A green suite proves the tested paths work under the tested conditions. It never proves the software is correct.
Example. “42 checks passed, covering checkout and three payment errors. Refunds were not tested.”
2Exhaustive testing is impossible
Inputs, states, orderings and environments multiply. A form with five fields of ten values each has 100,000 combinations before you consider timing, browsers or data.
Techniques. Equivalence partitioning, boundary value analysis, pairwise testing and decision tables.
3Early testing saves time and money
A defect caught in a requirement costs a conversation. The same defect caught in production costs a hotfix, a rollback and user trust. Testing activities should start as soon as there is something to review. This is what “shift left” means.
In practice. Testability reviews, acceptance criteria before code, and static analysis plus unit tests on every commit.
4Defects cluster together
A small number of modules usually hold most of the defects, often close to the Pareto split of roughly 80% of defects in 20% of modules.
Where to look. Modules with high complexity, recent churn, unclear ownership or a history of defects.
5Tests wear out
Running the same tests over and over finds fewer new defects each time. They still catch regressions, but they stop discovering anything. Older syllabi call this the pesticide paradox.
Techniques. Property-based testing, exploratory sessions, and mutation testing to find tests that no longer catch anything.
6Testing is context dependent
A medical device, a banking API and a mobile game need different techniques, rigour and coverage. There is no single correct test strategy.
Inputs to the strategy. Risk, regulation, users and release cadence.
7Absence-of-errors fallacy
Software that passes every test can still fail if it solves the wrong problem or is hard to use. Verification asks whether you built it right. Validation asks whether you built the right thing.
Techniques. Stakeholder acceptance testing, usability checks, beta feedback and product analytics.