The 7 principles of testing
The seven classic principles of software testing in plain English, each with a one-line example, so you understand the rules of the game before you start playing.
Every craft has a handful of truths that experienced people just know, often learned the hard way. Software testing has seven of them. They're sometimes called the seven principles of testing, and they show up in courses, certifications, and interviews everywhere. Learn them now and a lot of confusing situations later will suddenly make sense.
Don't worry about memorising them word for word. Understand the idea behind each one, and you'll be able to explain it in your own voice, which is far more impressive than reciting a list.
The seven principles at a glance
| # | Principle | What it really means | One-line example |
|---|---|---|---|
| 1 | Testing shows the presence of defects, not their absence | Finding bugs proves bugs exist. Finding none doesn't prove there are none. | You tested the login and found nothing, but the signup page may still be broken. |
| 2 | Exhaustive testing is impossible | You can never try every possible input and path, so you must choose wisely. | A single text box accepts infinite strings; you can't type them all, so you pick smart cases. |
| 3 | Early testing saves time and money | Catch defects as early as possible, because they get costlier the longer they live. | Spotting a vague requirement on day one beats finding it as a live crash on day ninety. |
| 4 | Defects cluster together | A small number of areas usually hold most of the bugs (the 80/20, or Pareto, pattern). | If one screen has thrown five bugs already, look there before the quiet, stable screens. |
| 5 | Beware the pesticide paradox | Run the same tests forever and they stop finding new bugs. Refresh them. | Just like pests grow immune to one spray, your old tests stop catching fresh problems. |
| 6 | Testing is context dependent | How you test depends on what you're testing. There's no one-size-fits-all. | A banking app is tested far more strictly than a hobby blog's comment box. |
| 7 | Absence of errors is a fallacy | A bug-free product that nobody wants is still a failure. "Correct" isn't "useful". | Flawless software that solves the wrong problem helps no one. |
A closer look at the trickier ones
A few of these trip people up, so let's slow down on them.
The pesticide paradox (principle 5)
Imagine spraying the same bug-killer on a field season after season. The pests that survive breed, and eventually the spray does nothing. Tests work the same way. The first time you run a set of tests, they catch real bugs. Run that exact same set forever and, once those bugs are fixed, the tests just keep passing and stop finding anything new. The fix is to keep evolving your tests: add new cases, vary your data, and explore corners you haven't touched.
Defects cluster (principle 4)
Bugs aren't sprinkled evenly across an app. They pile up in the hard, messy, frequently-changed parts. This is the famous 80/20 rule (the Pareto principle): a small slice of the software tends to produce most of the defects. The practical lesson is wonderful: when you find one bug in an area, slow down and dig there, because friends of that bug are usually nearby.
The absence-of-errors fallacy (principle 7)
This one feels almost philosophical, but it's deeply practical. You could test a product until it has zero bugs and still have failed completely, if the product solves the wrong problem or is impossible to use. Quality isn't only "does it work?" It's also "is this the right thing, built well enough that people actually want it?" A perfect calculator that opens upside down is still a bad calculator.
Testing is not about proving software is perfect (you can't) or trying everything (you can't). It's about spending your limited time where it does the most good, then staying honest about what your results do and don't prove.
Interview tip: if you're asked for the principles and blank on the list, explain principle 1 and principle 2 well. "Testing can show bugs exist but never prove there are none, and since you can't test everything, smart test design is the whole skill." That answer shows you actually understand the craft.
- Testing can show defects are present, but it can never prove they're all gone.
- You can't test everything, so choosing the right tests is the real skill.
- Test early (cheaper), look where bugs cluster (80/20), and refresh your tests so they don't go stale (the pesticide paradox).
- How you test depends on context, and a bug-free product that solves the wrong problem still fails.