ISTQB – Testing Principle 1

Testing Principle 1: Testing Shows the Presence, Not the Absence of Defects

In the next seven blog posts, I’ll explore each of the Testing Principles outlined in the ISTQB Foundation Syllabus. This is one of my favourite chapters because it covers essential aspects of testing that truly reflect what we experience in our daily work.

As testers, we should always keep these principles in mind – though that’s not always easy. It can be challenging, especially when we’re deeply focused, under tight deadlines, or need to persuade other team members about the importance of these principles.

I’m sure many of you already know and apply them in your work. Some of you may have come across them while preparing for the ISTQB Foundation Level Exam, while others might just need a quick refresher.

Let’s list all seven principles before diving into the first one:

1. Testing shows the presence, not the absence, of defects
2. Exhaustive testing is impossible
3. Early testing saves time and money
4. Defects cluster together
5. Tests wear out
6. Testing is context-dependent
7. The absence-of-defects fallacy

(These principles are taken from the ISTQB Foundation Level Syllabus, pages 17–18.)

Principle 1: Testing Shows the Presence, Not the Absence of Defects

“Yay – there are no bugs in the software!”

You might think that this would make the Product Team and Stakeholders very happy. After all, a “bug-free” product sounds like a dream come true. But in reality, if a QA team reports that no bugs were found, it’s actually a reason for concern. Let’s explore why.

No Bugs ≠ Good News

Modern software is inherently complex and constantly evolving, especially in Agile environments. There’s a 99.99% chance that defects exist somewhere. If testing reveals no bugs, it might mean:

• The test coverage wasn’t sufficient to cover all critical areas.
• Exploratory testing sessions were too limited in scope.
• The tester’s experience or domain knowledge was still developing (for example, if a new team member was conducting the tests).
• The testing environment wasn’t properly set up, preventing full and effective testing.

Given these possibilities, stakeholders should feel more confident hearing:

“We found X bugs, all of which have been fixed and retested. We executed X test cases, and all have passed.”

That statement indicates thorough testing and solid quality assurance.

How Testers Can Apply This Principle

When preparing or executing tests, testers must always remember this rule: our goal is to reduce the probability of undiscovered defects.

Reducing that probability involves adopting strong testing practices. Here are a few key ones:

• Prioritisation: Focus first on the system’s most critical parts — new features or historically problematic areas.
• Know the weak spots: Understand which components are prone to failure and pay closer attention to them.
• Peer reviews: A second pair of eyes can offer fresh insights and uncover missed issues.
• Trust your intuition: Never ignore something that feels “off.” It’s better to clarify with the Product Team and log a minor ticket than to overlook an issue that might cause major trouble later. Early in my career, I ignored a few of these small suspicions — and they always resurfaced at the worst time. Since then, I’ve learned to trust my tester’s intuition (I’ll write a separate post about this soon!).
• Recognise limitations: The entire team must understand testing constraints. For example, we can test on all major browsers but not every single browser or configuration combination.
• Adapting to change: In Agile environments, codebases evolve constantly. Even with regression testing, it’s rarely possible to retest the entire product after every change.

In Summary

The principle “Testing shows the presence of defects, not their absence” reminds us that testing is a continuous process focused on discovering and resolving defects — but it can never guarantee that a system is completely error-free.

It reinforces the importance of ongoing improvement in testing practices and encourages QA teams to approach testing with a realistic understanding of its limitations.

Certified Tester Foundation Level (CTFL) v4.0

If you’d like to learn more about Software Testing Principles and other related topics, and you’re considering enrolling in the Certified Tester Foundation Level (CTFL) v4.0 training, please visit our Courses page to explore the available options. Alternatively visit our Contact page, to see the options how to get in touch.