The 7 principles of software testing, explained with examples

Over 18 parts we have covered a lot of the how of testing. This part steps back to the why: seven principles that experienced testers have learned the hard way, and that explain almost every practice in this series.

They come from the ISTQB Certified Tester Foundation Level syllabus, the most widely used testing certification, and they're a favourite interview topic. More importantly, they change how you test.

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

Testing can show that bugs are there. It can never prove that there are none.

If 500 tests pass, you know the software works in those 500 situations. You don't know about the 501st. Every passing test reduces the risk of an unknown bug, but never removes it.

Example: the discount-code tests all pass. A week after release, a customer finds that applying a code, changing the delivery address and going back to the cart doubles the discount. No test tried that exact sequence.

What it means for you: never promise "bug-free". Report what was tested, what wasn't, and the risk that remains, as in a good test summary report.

2. Exhaustive testing is impossible

Testing every possible input and combination is impossible, except in trivially small cases.

A search box that accepts 10 characters of letters and digits has 36¹⁰ possible inputs: over 3.6 quadrillion. At a thousand tests per second, trying them all would take more than 100,000 years. And that's one field.

Example: the food app has thousands of restaurants, many browsers and phones, two languages, dozens of payment options and endless orders of steps. Testing every combination isn't hard; it's impossible.

What it means for you: choose tests wisely, using risk and test design techniques like equivalence partitioning, boundary values and pairwise testing. Good choices find most bugs with a small fraction of the tests.

3. Early testing saves time and money

The earlier a defect is found, the cheaper it is to fix.

A mistake caught while reading the requirements is a five-minute conversation. The same mistake found by customers in production means support tickets, an urgent fix, a new release, and lost trust.

Example: while reviewing the requirement "codes give 10% off", a tester asks, "before or after the delivery fee?" Nobody had decided. Settling it then costs nothing; finding it after release means refunds.

What it means for you: test from day one. Review requirements, write test cases before the code, and run tests on every change. This is the "shift left" idea from Part 1, and the reason the STLC runs alongside development.

4. Defects cluster together

A small number of areas usually contain most of the defects. This is often linked to the 80/20 (Pareto) rule, though the exact split varies.

Bugs cluster where code is complex, changes often, was written in a hurry, or connects to outside systems.

What it means for you: use your bug history. Where bugs were found before, more are likely hiding. Test those areas more deeply, and ask why they're fragile: often the real fix is simpler code or better tests, not just one more bug report.

5. Tests wear out (the pesticide paradox)

If you run the same tests over and over, they eventually stop finding new bugs.

The older name, the pesticide paradox, compares this to insects becoming resistant to a pesticide used again and again. Once the bugs your tests can find are fixed, the same tests just keep passing, while new bugs appear in places they don't look.

Example: the checkout regression suite has passed every night for six months. Meanwhile a new "pay later" option was added, and no test touches it.

What it means for you: keep regression tests (they still protect against old bugs returning), but review and extend them regularly. Add tests for new features and new risks, vary the test data, and mix in exploratory testing to find what scripts miss.

6. Testing is context dependent

There is no single right way to test. The right approach depends on what you're testing and why.

A banking app, a mobile game, a hospital system and a startup's first prototype need very different testing: different risks, rules, depth and speed.

Example: for the food app, a bug that charges the wrong amount is critical and gets deep testing; a slightly misaligned icon on the help page is not. A medical device would need formal documentation and strict regulation that a food app doesn't.

What it means for you: don't copy another team's process blindly. Choose your test plan, level of documentation, amount of automation and coverage targets based on your product's risks.

7. The absence-of-defects fallacy

Finding and fixing lots of bugs doesn't guarantee success. Software with no known bugs can still be the wrong software.

If the system is hard to use, too slow, or simply doesn't do what users need, a clean bug list doesn't help.

Example: the new restaurant dashboard passes every test, with zero open bugs. But restaurants refuse to use it, because it takes six clicks to accept an order during the dinner rush.

What it means for you: test against users' real needs, not only the written requirements. That's what acceptance testing and usability testing are for, along with talking to real users early.

The seven principles at a glance

#	Principle	In one line
1	Testing shows the presence of defects	Passing tests never prove there are no bugs
2	Exhaustive testing is impossible	Choose tests by risk and technique
3	Early testing saves time and money	Start testing on day one
4	Defects cluster together	Test harder where bugs were found
5	Tests wear out	Review and refresh your tests
6	Testing is context dependent	Fit the testing to the product and its risks
7	Absence-of-defects fallacy	Bug-free isn't enough if it's the wrong product

How the principles connect to this series

Almost everything in earlier parts follows from these principles:

• Test design techniques (Parts 6 and 7) exist because of principle 2.
• The STLC and test planning (Parts 4 and 8) put principle 3 into practice.
• Risk-based testing (Part 8) uses principles 4 and 6.
• Regression maintenance (Part 15) answers principle 5.
• Acceptance testing (Part 2) protects against principle 7.
• Coverage (Part 18) is limited by principles 1 and 2.

What's next

In Part 20 we clear up three terms that are often mixed up: QA, QC and testing, and verification vs validation.

ProvaLab helps put the principles into practice: tests run on every change (principle 3), each test case keeps a history so you can see where failures cluster (principle 4), and coverage reports show which requirements have gone untested (principles 1 and 2). See it in the two-minute product tour.