Practical QA guide · 10 min
The Seven Testing Principles Explained
Learn the seven foundational testing principles with practical examples and understand how they change everyday QA decisions.
Written and reviewed by ShiftQA Labs QA Education Team · Updated September 2, 2026
Browse Lessons modules
Principles one through three: evidence, selection, and timing
Testing shows the presence of defects, not their complete absence. A passed suite means the observed behavior met expectations under tested conditions. Exhaustive testing is impossible for non-trivial products, so teams use risk and techniques to select useful conditions.
Early testing reduces rework. Reviewing an ambiguous acceptance criterion before development is usually cheaper than discovering several conflicting implementations near release.
Principles four and five: concentration and renewal
Defects often cluster in a small number of components or workflows. Historical failures, complexity, change frequency, and integration density can help direct more coverage toward those areas without ignoring the rest of the system.
The pesticide paradox warns that repeatedly running the same cases eventually finds fewer new problems. Stable regression tests remain useful, but teams must review data, assumptions, routes, and techniques as the product changes.
Principles six and seven: context and customer value
Testing is context dependent. A medical device, marketing site, banking API, and mobile game do not need identical techniques, depth, evidence, or independence. The approach must match the product, risk, users, constraints, and decision.
The absence-of-errors fallacy means technically correct software can still fail when it solves the wrong problem or is unusable. Quality includes suitability for real user and business needs, not merely a low defect count.
Worked example
Applying all seven principles to product search
A retailer changes its search ranking before a major campaign.
- 1Do not claim defect-free search because sampled queries pass.
- 2Select equivalence classes, boundaries, high-value queries, empty results, and failure conditions instead of every possible query.
- 3Review ranking rules and analytics expectations before implementation finishes.
- 4Increase depth around the ranking service and catalogue feed where failures historically cluster.
- 5Add new exploratory queries and data shapes instead of relying only on last release’s regression set.
- 6Include functional, usability, performance, accessibility, and search-business context.
- 7Confirm that technically accurate results still help shoppers find the intended products.
Frequently asked questions
Questions testers ask
Which principle says complete testing is impossible?
Exhaustive testing is impossible. Teams therefore select coverage using risk, techniques, priorities, and constraints.
Does defect clustering mean we test only risky modules?
No. It supports concentrating additional effort where defects are more likely or impactful, while maintaining proportionate coverage elsewhere.
Is the pesticide paradox a reason to delete regression tests?
No. Keep valuable regression checks, but review and supplement them so the suite continues to reflect current risks and can find new classes of failure.
