Testing Fundamentals — Why We Test

This post is part of the ISTQB Foundation Level series — a structured guide designed to help you understand software testing concepts as defined by the ISTQB syllabus, whether you’re preparing for the CTFL exam or simply building a solid QA foundation.

Why Bother Testing?

On July 23, 1999, NASA’s Mars Climate Orbiter disintegrated in the Martian atmosphere. The cause? One engineering team was using metric units (newton-seconds) and another was using imperial units (pound-force seconds). A unit mismatch — a defect that could have been caught — cost $327.6 million and set back Mars exploration by years.

In 1985–1987, the Therac-25 radiation therapy machine delivered lethal overdoses to at least six patients. The software had race conditions that, under specific timing conditions, bypassed safety interlocks. The developers assumed if there was no hardware interlock, the software would behave correctly. It didn’t.

In 2012, Knight Capital Group lost $440 million in 45 minutes due to a software deployment that activated a dormant trading algorithm. The company ceased to exist as an independent firm.

These are not obscure historical footnotes. They are illustrations of what happens when software is not adequately tested. And the pattern is consistent: the cost of a defect grows exponentially the later it is found.

Phase defect found	Relative cost to fix
Requirements	1×
Design	5×
Coding	10×
Testing	20×
Production	100×+

Testing is how we find defects before they reach production. But that framing — “find bugs” — is only part of the story.

Goals of Testing (ISTQB 1.1)

The ISTQB Foundation Level syllabus defines testing with a richer set of goals than just defect hunting. Understanding all of them changes how you think about what you’re doing when you test.

1. Find defects

The most obvious goal. Testing creates conditions under which defects manifest as visible failures. Without testing, defects stay hidden until a user encounters them — usually at the worst possible moment.

2. Gain confidence in the quality level

Sometimes you test not because you expect to find bugs, but because you need to demonstrate that the system works correctly. Regression suites, smoke tests, and acceptance test passes are all about building and communicating confidence.

3. Provide information for decision-making

Stakeholders need to decide: do we release? Do we delay? Do we accept these known defects as low-risk? Testing provides the data they need — defect counts, test coverage, risk areas still untested. Testing is an information-generating activity.

4. Prevent defects

This surprises many newcomers. How does testing prevent defects? By involving testers early — in requirements reviews, design discussions, story refinement. When a tester asks “what happens if the user enters an empty string here?” during requirements, that’s defect prevention. The defect never gets coded.

5. Verify compliance with requirements

Did we build what was specified? Formal verification testing checks that the software meets contractual, regulatory, or standards-based requirements. This is especially critical in regulated industries (medical, aviation, finance).

6. Validate that the system meets user needs

Verification asks “did we build it right?” — validation asks “did we build the right thing?” A system can pass all its specified tests and still fail users. Usability testing, exploratory testing, and beta programs all contribute to validation.

:::tip[ISTQB Exam Tip] The ISTQB distinguishes between verification (“does the software conform to specifications?”) and validation (“does the software meet user needs and expectations?”). Both are goals of testing, but they answer different questions. :::

Testing vs. Debugging (ISTQB 1.1.2)

One of the most important distinctions the ISTQB makes — and one that causes real friction in teams — is the difference between testing and debugging.

Testing is the activity of executing the software and observing whether it behaves as expected. When the behavior diverges from expectations, testing has found a failure. Testing can be performed by anyone: testers, developers, business analysts, end users.

Debugging is the activity of finding the cause of a failure, fixing it, and confirming the fix. It requires deep knowledge of the code. Debugging is almost always done by developers.

The chain looks like this:

Failure observed → Defect located (debugging) → Fix applied → Confirmation test run

Testing can trigger this chain, but testing is not the same as debugging. A tester who reports “clicking Submit causes a 500 error” has done their job. Finding why the server throws a 500 is the developer’s job.

This distinction matters for team dynamics. Testers who feel responsible for finding the root cause of every bug will burn out and overstep. Developers who resent bug reports because “that’s not a bug” need to understand that a failure is a failure regardless of cause.

:::note[ISTQB Exam Tip] The ISTQB syllabus is explicit: dynamic testing (executing the software) can reveal failures, but only debugging finds and fixes the defect that caused the failure. Confirmation testing after a fix is a testing activity, not debugging. :::

The 7 Principles of Testing (ISTQB 1.3)

These principles underpin everything else in the ISTQB syllabus. They’re not abstract philosophy — each one has direct implications for how you plan and execute tests.

1. Testing Shows the Presence of Defects, Not Their Absence

No matter how thorough your test suite, a passing test run does not prove the software is defect-free. It proves the software passed those specific tests. There may be defects your tests don’t cover, edge cases you haven’t considered, or environment-specific bugs that never appear in your test environment.

This principle should breed healthy skepticism. A green build is good news, not a guarantee.

2. Exhaustive Testing Is Impossible

Consider a simple login form with two fields. The number of possible input combinations — including special characters, Unicode, very long strings, empty inputs, SQL injection payloads — is effectively infinite. For a real application, the state space is incomprehensibly large.

You cannot test everything. Testing is always a process of selection: choosing which inputs, scenarios, and conditions are worth testing given your time and risk constraints. Risk-based testing and equivalence partitioning exist precisely because of this principle.

:::tip[ISTQB Exam Tip] When asked about exhaustive testing, the ISTQB answer is: it’s impossible except in trivial cases. The response to this impossibility is risk-based testing — prioritising tests by the likelihood and impact of failure. :::

3. Early Testing Saves Time and Money

Refer back to the cost table at the start of this post. A defect found in requirements costs a fraction of what it costs to find in production. Testers involved early — reviewing requirements, participating in design discussions, writing acceptance criteria alongside developers — prevent defects from ever being written into code.

This is the intellectual foundation of the shift-left movement in modern software development.

4. Defects Cluster

In most software systems, a small number of modules or features contain the majority of defects. This is sometimes called the Pareto Principle applied to testing: roughly 80% of defects come from 20% of the code.

The practical implication: if you find a bug, look for more bugs in the same area. Where there’s one defect, complexity, unclear requirements, or difficult code often means there are others nearby.

5. Beware of the Pesticide Paradox

If you run the same tests over and over, eventually those tests will stop finding new defects. Why? Because any defects those tests could expose have already been found and fixed. The remaining defects are ones your test suite doesn’t exercise.

Like pesticides that lose effectiveness over time as pests develop resistance, test suites that never change lose their defect-finding power. The response: regularly review and update tests, add new test cases, and supplement scripted testing with exploratory testing.

6. Testing Is Context Dependent

How you test a medical device firmware is not how you test a mobile game. The testing approach for a safety-critical embedded system — formal methods, traceability matrices, regulatory documentation — would be absurdly over-engineered for a two-week sprint feature. The testing approach for a social media app — rapid exploratory testing, A/B testing, user feedback loops — would be dangerously inadequate for medical software.

Good testers understand their context and adapt their approach accordingly. There is no universally correct testing strategy.

7. Absence-of-Errors Fallacy

A system can pass every single test and still be a failure. If the tests are testing the wrong things — if the requirements were wrong, if the system solves the wrong problem — no amount of test passing will save it.

This is why validation (testing against user needs) matters as much as verification (testing against specifications). The worst outcome in software is a system that is thoroughly verified to be doing the wrong thing correctly.

:::note[ISTQB Exam Tip] All 7 principles are examinable. The ones most frequently tested: principle 1 (testing shows presence not absence), principle 2 (exhaustive testing is impossible), and principle 7 (absence-of-errors fallacy). Know both the name and the implication of each. :::

Connecting the Principles to Daily Work

These principles aren’t exam memorisation fodder — they’re operational guidelines.

When your manager asks “are we done testing?”, principle 1 reminds you that you can’t say “yes, it’s defect-free.” You can say “we’ve tested these scenarios to this level of coverage and found X defects, Y of which are open.”

When you’re told to test everything before the release, principle 2 is your evidence that this isn’t possible, and risk-based prioritisation is the responsible alternative.

When the team resists involving QA in requirements, principle 3 gives you the business case: defects found early cost less to fix.

When you’re wondering what to test next, principle 4 (defect clustering) suggests starting in areas that have already shown problems.

When your regression suite never finds anything, principle 5 says it’s time to review and extend it.

When someone asks you to apply a testing strategy from a different domain, principle 6 reminds you to think about context.

When a feature passes all tests but users hate it, principle 7 explains why.

Conclusion

Testing is not a phase you do at the end before you ship. It’s a discipline that informs how software is built from the first conversation about requirements to the last monitoring alert in production.

The ISTQB Foundation Level provides a rigorous, shared vocabulary for this discipline — one that is recognised in 130+ countries and used by organisations that take software quality seriously. Understanding why we test, not just how, is what separates professionals from technicians.

In the next post in this series, we’ll look at the psychology of testing — the mindset, cognitive biases, and communication challenges that make testing as much a human problem as a technical one.