ISTQB-FL | 1.3 Seven Testing Principles

Core idea

A short tutorial on the seven fundamental testing principles from ISTQB Foundation Level. Each principle is explained with practical examples (including exam-style questions) and recommendations for applying them in real projects.

The video/tutorial is intended to help testers preparing for ISTQB FL and practitioners apply these principles on projects.

The seven testing principles

1. Testing shows the presence of defects

   • Tests can reveal defects but cannot prove the absence of all defects. Finding many defects doesn’t guarantee there are no more.

2. Exhaustive testing is impossible

   • You cannot test every input or combination (for example, all PIN combinations). Testing must be selective and based on risk and priorities.

3. Early testing

   • Start testing as early as possible (requirements and documentation stages) to find defects sooner and reduce cost/impact.

4. Defect clustering (Pareto effect)

   • A small portion of modules often contain most defects (approximately 80/20). Identify and focus effort on those modules.

5. Pesticide paradox

   • Repeating the same tests will eventually stop finding new defects. To avoid this, review and refresh test cases, design new tests, and target unexplored areas.

6. Context-driven testing

   • The testing approach depends on domain and context (e.g., medical systems vs. e-commerce). Scope, depth, techniques, and timelines should adapt to risk and impact.

7. Absence-of-errors fallacy

   • A product can be defect-free yet still not meet user needs (wrong requirements or misunderstanding). Passing tests doesn’t ensure business fit or user satisfaction.

Practical guidance and exam tips

• Use risk-based prioritization: test the most critical or risky areas first.
• Regularly review and update test cases to overcome the pesticide paradox.
• In projects with complex code, concentrate testing on defect-prone modules (defect clustering).
• When communicating metrics (e.g., “95% of defects found”), explain the limits of testing to management:
  • You can’t guarantee 100% coverage.
  • Use the impossibility of exhaustive testing, defect clustering, and pesticide paradox to justify residual risk.
• Start testing early in the lifecycle to reduce defect cost and improve quality.
• Distinguish between “no technical defects found” and “requirements met”; validate requirements and user expectations.

Examples covered

• PIN/password combinations as an impractical exhaustive-testing example.
• Pareto (80/20) example showing a small code portion causing most issues.
• An exam-style scenario where the test team found 95% of defects and how to explain remaining risk to non-test managers.
• A scenario about complex code illustrating how defect clustering guides focused testing.

Format and source

• Format: Tutorial-style explanation with practical examples and exam-relevant questions.
• Intended audience: Testers preparing for ISTQB FL and practitioners applying principles in projects.
• Main speaker/source: An unnamed course instructor presenting ISTQB Foundation Level material (instructional ISTQB-FL tutorial).