1.4 The Seven Testing Principles

The Seven Principles Defined

CTFL v4.0 names exactly seven testing principles. Questions describe a project situation and ask which one best explains it, so define each precisely rather than memorizing slogans.

1. Testing shows the presence of defects, not their absence. Testing can show that defects are present, but cannot prove that there are no defects. Passing tests reduce the level of risk but never prove the software is defect-free.
2. Exhaustive testing is impossible. Testing everything (all input and precondition combinations) is not feasible except in trivial cases. Instead of exhaustive testing, risk analysis, test techniques, and priorities focus the test effort.
3. Early testing saves time and money. Defects are cheaper to find and fix the earlier they are found. Static testing of requirements and design, and early dynamic testing, are sometimes called shift left.
4. Defects cluster together. A small number of modules usually contain most of the defects or are responsible for most failures. This supports risk-based and focused testing.
5. Tests wear out (the pesticide paradox). If the same tests are repeated unchanged, they stop finding new defects. Tests must be reviewed and revised, and new and different tests written, to find new defects.
6. Testing is context dependent. Testing is done differently in different contexts — a safety-critical control system is tested differently from an e-commerce app. There is no single universal approach.
7. Absence-of-defects is a fallacy. Finding and fixing defects does not help if the system built is unusable or does not meet users' needs and expectations. A product can be defect-free and still be the wrong product.

Putting Principles To Work

Defect clustering means defects are unevenly distributed. If a complex pricing component produces many failures, it may deserve more attention than a stable static page — though other areas are not ignored; evidence guides focus. The pesticide paradox says repeating identical tests becomes less effective; tests need review, new data, new paths, and exploratory variation. The metaphor is that pests develop resistance to a pesticide used repeatedly.

Early testing supports shift-left thinking, but it is not exclusive to agile or DevOps — reviewing a requirements document on a traditional project is also early testing. Context dependence means a payroll system, an aircraft control component, a public website, and a classroom prototype have different risks, regulations, users, and acceptable evidence; a one-size-fits-all process is unrealistic.

The absence-of-defects fallacy closes the set: a system can have few known defects and still be poor quality because it does not meet business goals or user needs. A perfectly coded reporting tool that answers the wrong regulatory question is still a failure.

Exam Tactics

Watch for absolute language. Statements such as test everything, prove no defects, or reuse the same tests forever each conflict with a specific principle. When a scenario fits several true principles, choose the one that most directly matches the described situation — for example, a regression suite that no longer finds defects is the pesticide paradox, not merely context dependence. Knowing the exact name and one-line consequence of each of the seven principles is enough to answer the K1/K2 questions in this area.

How the Principles Reinforce Each Other

The seven principles are not independent rules; they form a coherent argument about why testing must be smart rather than exhaustive. Because exhaustive testing is impossible (principle 2), the team must select tests — and the best selection criterion is risk, which connects to defect clustering (principle 4): concentrate where defects are likely. Because testing shows presence, not absence (principle 1), no amount of passing tests proves the product is safe, reinforcing the need for early testing (principle 3) so defects are removed cheaply rather than discovered late.

Because tests wear out (principle 5), the suite must evolve, and because testing is context dependent (principle 6), the right evolution differs between a banking core system and a marketing site. Finally, the absence-of-defects fallacy (principle 7) reminds the team that even a flawless build is worthless if it solves the wrong problem — which loops back to validation and to testing's true objective of reducing meaningful risk. Seeing the principles as one system, rather than seven memorized lines, makes scenario questions far easier.

Common Misreadings to Avoid

Several subtle misreadings cost marks. First, early testing does not mean only dynamic testing early; it explicitly includes static testing of requirements and design — reviewing a specification on day one is early testing. Second, defect clustering describes an observed tendency, not a guarantee, and it does not justify ignoring low-defect areas entirely, because those may carry high impact. Third, the pesticide paradox is solved by changing and adding tests, not by simply running the old ones more often.

Fourth, context dependence is sometimes mistaken for an excuse to skip rigor; in fact it means rigor should be calibrated to risk and context, which can mean more testing for safety-critical systems, not less. Fifth, the absence-of-defects fallacy is about meeting user needs, not about defect counts being unreliable — a product can have zero known defects and still be a commercial failure. Memorize the precise statement of each principle, because CTFL distractors are often almost correct paraphrases that subtly invert the principle's meaning.