The Seven Principles of Testing

Decades of testing experience — the successes, and especially the expensive failures — compress into seven short statements. The industry calls them the seven principles of testing, they come from the ISTQB, the international body whose vocabulary this book follows, and they are the closest thing this field has to laws of physics. They sound almost too simple. Then, sometime in your first year, each one saves you from a real mistake.

A home inspection makes a good companion for this page. An inspector examining a house you're about to buy faces the same physics you do: too much to check, limited time, and a client who wants a guarantee nobody honest can give. Keep the inspector in mind — several principles are theirs too.

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

You met this one in the last topic, and it leads the list for a reason. Finding a bug proves a bug exists. Finding nothing proves only that you found nothing — not that nothing is there. The inspector who finds no leaks doesn't certify the house leak-free; they report that no leaks were found in the places examined. Every honest test report you will ever write carries that same shape.

2. Exhaustive Testing Is Impossible

Checking every possible input, path, and situation cannot be done — not "is hard," cannot. You saw the arithmetic in Topic 1: one small booking form outruns the seconds in your lifetime. So professional testing is never "test everything"; it is always "choose an intelligent sample." How to choose that sample is a craft with named techniques, and it gets the biggest chapter in this book — Chapter 4 exists because of this principle.

3. Early Testing Saves Time and Money

The cost-of-defect curve from Topic 1, now as a principle: the earlier a defect is found, the cheaper it is to fix. That's why testing isn't a phase that starts when the code is finished — it starts when the requirements are being written, by reading them critically before anything is built. The industry's nickname for pushing quality checks toward the beginning is shift-left (picture the project timeline drawn left to right; testing slides left, toward the start). You'll hear the phrase constantly, and now you know it's just Principle 3 wearing a jacket.

4. Defects Cluster Together

Bugs are not spread evenly through a product. They pile up in hotspots — the newest code, the most complicated logic, the module that's been rewritten three times. The inspector knows this too: a house with one damp corner in the basement usually has more problems in the basement, not scattered randomly through the bedrooms. For a tester this is wonderful news, because it means yesterday's bug map predicts where tomorrow's bugs live — and your limited testing time (Principle 2) should follow that map.

5. The Pesticide Paradox

Run the same tests over and over, and they stop finding new bugs — just as a pesticide used season after season stops killing insects, because the survivors are precisely the ones it doesn't affect. The bugs your existing tests could catch are already caught; what remains is, by definition, whatever those tests miss. The cure is to keep refreshing your tests: new angles, new data, new questions. Repeating old checks still has a job — making sure fixed things stay fixed — but discovering new problems demands new tests.

6. Testing Is Context-Dependent

A banking app, a mobile game, and the software in a heart monitor should not be tested the same way, to the same depth, with the same paranoia. What's "enough testing" for a free game would be negligence for a payment system. There is no universal checklist — the right testing always depends on what the product is, who uses it, and what a failure would cost. This is why this book keeps asking "what would hurt most?" instead of handing you one fixed recipe.

7. The Absence-of-Errors Fallacy

The strangest principle, and the one teams forget in the final week before a launch: a product with zero known bugs can still fail completely. If the software solves the wrong problem, or confuses everyone who tries it, its bug-free-ness doesn't matter — the inspector's structurally perfect house is still a terrible buy if it's in the wrong city for the family buying it. Quality means fit for purpose, not just free of defects. Testing that only hunts bugs, and never asks "is this actually what users need?", is aiming at the smaller target.

The Principles at Work: Petra's Question

Your first week at Fernway, Petra — the product manager — asks the question every tester eventually gets: "Can you guarantee this release has no bugs?" Now you have the professional answer. No — testing shows the presence of defects, not their absence (Principle 1), and checking everything is impossible even in theory (Principle 2). But here is what you can promise: focused, technique-driven testing of the riskiest flows first — payments, bookings, the places where failure costs real money — with an honest report of what was covered and what wasn't. Petra doesn't get her guarantee. She gets something better: a picture she can actually rely on. That trade — false certainty exchanged for honest clarity — is the profession in one sentence.