Summary of "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

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.
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.
Early testing
- Start testing as early as possible (requirements and documentation stages) to find defects sooner and reduce cost/impact.
Defect clustering (Pareto effect)
- A small portion of modules often contain most defects (approximately 80/20). Identify and focus effort on those modules.
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.
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.
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).