The summary.
TESTING SHOWS THE PRESENCE OF DEFECTS, NEVER THEIR ABSENCE
It samples rather than exhausts, so it reduces risk without eliminating it. The real question is whether the remaining risk is acceptable — which makes it a business decision informed by technical work.
DEFECTS CLUSTER IN A SMALL PROPORTION OF MODULES
Follow the clusters rather than spreading effort evenly, using historical defect data by area.
THE SAME TESTS REPEATED STOP FINDING ANYTHING NEW
Review and extend the suite, and combine scripted testing with exploratory work — scripts encode only what was anticipated.
MANY FAST LOW-LEVEL TESTS, FEW SLOW END-TO-END ONES
Inverting that shape produces a slow suite that fails intermittently and locates nothing.
SOFTWARE MEETING ITS SPECIFICATION PERFECTLY MAY STILL FAIL THE USER
Testing against documents cannot detect that. Validate with users, not only verify against requirements.
DOCUMENT THE RISK ASSESSMENT, BECAUSE IT JUSTIFIES WHAT WAS NOT TESTED
That is the question asked after an incident. Never imply testing was complete.
SOME DEFECTS WILL ONLY APPEAR IN PRODUCTION
Build rapid detection, rollback and fixing deliberately.
