In software engineering, testing isn't just a "check-up" at the end of the project. It follows a set of universal laws known as the Seven Principles of Testing. These principles act as a guide to prevent the waste of time and resources while ensuring the highest possible quality.
🔒 Testing shows the presence of defects, not their absence
Testing can prove that bugs exist, but it can never prove that a system is 100% bug-free. Even if you run 1,000 tests and they all pass, it just means you haven't found the bugs yet—not that they don't exist.
🚫 Exhaustive testing is impossible
You cannot test every possible combination of data and preconditions. For example, a simple "Age" field that accepts numbers from 1 to 100 has millions of variations if you consider browser types, OS, and hardware.
The Solution: We use Risk Analysis and Equivalence Partitioning to focus testing on the most likely areas of failure.
⬅️ Early Testing (Shift Left)
Testing should start as early as possible in the Software Development Life Cycle (SDLC).
Why? Finding a flaw in the Requirements phase is cheap. Finding that same flaw after the code is written is incredibly expensive.
📉 Defect Clustering (Pareto Principle)
In most systems, about 80% of the bugs are found in 20% of the modules. If you find a bug in the "Payment Gateway," chances are there are ten more hiding in that same area.
The Strategy: Once you find a "hotspot" for bugs, double your testing efforts there.
🐛 The Pesticide Paradox
If you keep running the same set of tests over and over, they will eventually stop finding new bugs—just like pests build immunity to a single pesticide.
The Solution: Testers must constantly review and update their test cases to find "new" defects.
🏗️ Testing is context-dependent
A "one-size-fits-all" approach doesn't work.
Context A: An e-commerce site needs heavy performance testing for sales events.
Context B: A banking app needs heavy security testing.
Context C: A medical device needs rigorous safety testing.
❌ Absence-of-errors fallacy
A system that is "bug-free" is still a failure if it doesn't meet the user's needs. If the software is technically perfect but the user interface is impossible to navigate, the product is still unusable. Quality is about meeting requirements, not just avoiding crashes.
📊 Summary of Principles
Principle | Key Takeaway |
|---|---|
Early Testing | Start testing at the SRS phase. |
Defect Clustering | Bugs love to hang out together. |
Context Dependent | Match the test to the target (Bank vs. Game). |
No Absence of Errors | A "working" app that no one can use is still a fail. |
💡 Pro-Tip for the Exam
When asked about the "Goal of Testing," never say "to prove the software works." The correct answer is "to find as many defects as possible so they can be fixed." It is a destructive process used for a constructive goal.