What is Seven Principles of Testing?

The seven principles are: (1) Testing shows the presence of defects, not their absence, finding bugs proves they exist, but no amount of passing tests proves there are none. (2) Exhaustive testing is impossible, you cannot test every input and path, so you prioritize with risk and techniques. (3) Early testing saves time and money, defects are cheaper to fix the earlier they are found (shift left). (4) Defects cluster together, a small number of modules usually contain most defects (the Pareto principle in testing). (5) Beware the pesticide paradox, repeating the same tests stops finding new bugs, so revise them. (6) Testing is context dependent, you test a safety-critical system differently from a marketing site. (7) Absence-of-errors is a fallacy, software that is bug-free but does not meet user needs is still a failure.

Together these principles shape a mature testing mindset: test early, prioritize by risk, focus where defects cluster, keep tests evolving, and measure success by whether the product meets real needs, not just by passing tests. They are the conceptual backbone behind practices like risk-based testing, shift-left, and exploratory testing.

Worked through one at a time, each principle carries a direct operational consequence. 1. Testing shows the presence of defects, not their absence: never report "the software works," report what was tested, what was found, and what risk remains. 2. Exhaustive testing is impossible: even a small form has more input combinations than you could ever run, so use risk-based prioritization plus techniques like equivalence partitioning and boundary value analysis to let a few tests stand for the many. 3. Early testing saves time and money: review requirements and designs before code exists, because a defect caught in a requirements workshop costs minutes while the same defect in production costs incidents and trust. 4. Defects cluster together: mine your defect history for hot modules and weight regression coverage toward them instead of spreading effort evenly.

5. Beware the pesticide paradox: a regression suite that never changes stops finding new bugs, so retire stale cases, add tests for new risk areas, and mix in exploratory sessions to keep the "pesticide" effective. 6. Testing is context dependent: a payment service, a game, and an internal admin tool justify different rigor and evidence, so defend your strategy in terms of the product's risk profile rather than a universal checklist. 7. Absence-of-errors is a fallacy: a release with zero open defects still fails if it is slow, unusable, or solves the wrong problem, which is why exit criteria should include user-facing quality signals, not just bug counts.

In interviews, the principles work best as justification, not recitation. Asked how you would test a feature with limited time, cite principles 2 and 4 to explain risk-based selection focused on historically defect-dense areas. Asked why a bug escaped despite passing tests, cite principles 1 and 5: passing tests never proved absence, and the suite may have gone stale. Asked to define quality, use principle 7 to move the answer from defect counts to fitness for purpose. Naming the principle and immediately grounding it in a decision you made is what separates an ISTQB-memorized answer from an experienced one.