Disclaimer: This article is not an official ISTQB® document. It is prepared for knowledge-sharing and learning purposes only, based on the publicly available ISTQB® Foundation Level syllabus. For official and authoritative information, please refer to the ISTQB® website.

Worded simply, the ISTQB outlines seven guiding principles that every tester should know. These are not rigid rules, but trusted anchors for thoughtful, risk-based testing.

1. Testing shows the presence of defects, not their absence

You can prove that defects exist — but never that they don’t. No matter how many tests pass, undiscovered bugs can still hide. Testing reduces risk, but it doesn’t prove perfection.

You run 500 regression tests after a new release, and all pass. A week later, a user reports a critical bug in an edge case that wasn’t part of your test set. This doesn’t mean testing failed — it means the test suite didn’t cover that scenario yet.

2. Exhaustive testing is impossible

Testing every possible input, path, and precondition is unrealistic except for the simplest systems. Instead, use risk assessment and test design techniques to focus effort where it matters most.

A login form accepts usernames up to 20 characters. Technically, there are millions of possible input combinations — but instead of testing all, you apply equivalence partitioning to test representative inputs: valid, boundary length, empty, and invalid formats.

3. Early testing saves time and money

The earlier a defect is found, the cheaper it is to fix. Testing activities — both static (like reviews) and dynamic — should start as early as possible in the development lifecycle.

During a design review for a payment gateway, a tester notices that the flow doesn’t account for expired credit cards. Fixing it at design time takes 10 minutes — if it were found after release, it could cost thousands in failed transactions and hotfix deployment.

4. Defects cluster together

A small number of modules often contain most of the defects. Recognizing where defect clusters are likely (or have been observed before) helps you focus your testing effectively.

In a large banking application, 70% of reported bugs come from the transaction reconciliation module. Testers focus extra effort here in future cycles, because history shows it’s more prone to defects.

5. Beware the pesticide paradox

If you run the same tests repeatedly, they’ll eventually stop finding new bugs — just as pests grow resistant to the same pesticide. You need to regularly review and refresh your test cases.

You’ve been using the same set of smoke tests for months. They keep passing, but you notice fewer new bugs being found. After adding fresh test cases covering new workflows and edge cases, you uncover several high-priority defects.

6. Testing is context-dependent

Testing isn’t one-size-fits-all. The approach, techniques, and level of rigor depend on the system under test — whether it’s safety-critical software or a casual mobile game.

Testing a hospital patient monitoring system demands rigorous safety testing, failover checks, and compliance validation — while testing a casual mobile game focuses more on user experience, speed, and fun factor.

7. Absence-of-errors is a fallacy

Even a bug-free system can fail if it doesn’t meet user needs or expectations. Quality is not just about eliminating defects — it’s about delivering value.

A bug-free fitness app still gets poor reviews because it’s confusing to navigate and doesn’t track workouts in a way users expect. It “works” technically, but fails to deliver value.

Why these principles matter today
These ideas aren’t just exam topics — they’re timeless patterns of critical thinking for testers. They help shift focus from simply “finding bugs” to delivering reliable, valuable software. Even with AI and automation reshaping testing, these principles remain the foundation of good practice.