Experienced testers follow a set of guiding ideas that have been observed across decades of software projects. The internationally recognised seven testing principles, popularised by the ISTQB syllabus, explain what testing can and cannot achieve. In this lesson you will also learn the difference between verification and validation and how defects can be found without even running the software, through static testing and reviews. All of these are favourite interview topics.
The Seven Testing Principles
1. Testing shows the presence of defects, not their absence
Testing can prove that defects exist, but it can never prove that software is completely defect-free. If 500 test cases pass, it only means no defects were found by those tests. This is why testers report "no known critical defects" rather than "the app has no bugs".
2. Exhaustive testing is impossible
Testing every possible input and combination is not practical. A 10-digit mobile number field alone has 10 billion possible values, and combined with other fields, browsers and devices the numbers explode. Instead, testers use risk analysis and test design techniques such as equivalence partitioning and boundary value analysis to select a smart subset of tests.
3. Early testing saves time and money
Testing activities should start as early as possible in the life cycle. Reviewing requirements and designs catches defects when they are cheapest to fix. This is the idea behind shift-left testing.
4. Defects cluster together
A small number of modules usually contain most of the defects. This often follows the Pareto principle: roughly 80% of defects are found in 20% of modules. In a banking app, for example, the fund transfer and statement modules may be far more complex and defect-prone than the "Contact Us" page. Testers focus extra effort on these clusters.
5. Beware of the pesticide paradox
If the same tests are run again and again, they eventually stop finding new defects, just as insects become resistant to a pesticide used repeatedly. To overcome this, testers must regularly review and update test cases, add new scenarios and vary test data.
6. Testing is context dependent
The right testing approach depends on the context. A hospital management system, a UPI payment app and a simple college event website need very different levels of rigour, documentation and types of testing. Security and data accuracy dominate the payment app; usability and speed may dominate the event site.
7. Absence-of-errors is a fallacy
Finding and fixing many defects does not guarantee success. If the system does not meet the user's actual needs, it is still a failure. A train booking app that is technically bug-free but takes eight screens to book a ticket will lose users.
| # | Principle | One-line meaning |
|---|---|---|
| 1 | Presence of defects | Testing finds bugs; it cannot prove there are none |
| 2 | Exhaustive testing impossible | Prioritise using risk and techniques |
| 3 | Early testing | Start testing from requirements |
| 4 | Defect clustering | Few modules hold most defects |
| 5 | Pesticide paradox | Refresh tests regularly |
| 6 | Context dependent | Testing differs by domain and risk |
| 7 | Absence-of-errors fallacy | Bug-free but useless is still a failure |
Remember the order with the phrase "Present, Exhaustive, Early, Cluster, Pesticide, Context, Absence". In interviews, giving one quick example for each principle makes a strong impression.
Verification vs Validation
These two terms describe two complementary sides of quality checking.
| Aspect | Verification | Validation |
|---|---|---|
| Key question | Are we building the product right? | Are we building the right product? |
| Focus | Documents, design, code conforming to specifications | Working software meeting user needs |
| Code executed? | No | Yes |
| Methods | Reviews, walkthroughs, inspections, static analysis | Functional and non-functional testing, UAT |
| Timing | Starts early, before and during development | After a build is available |
| Example | Reviewing the SRS to confirm the refund rules are complete | Cancelling a booked ticket and checking the refund amount |
Static Testing vs Dynamic Testing
Static testing examines work products such as requirements, design documents, test cases and code without executing them. It includes manual reviews and tool-based static analysis (for example, a tool flagging unused variables). Dynamic testing involves executing the software with inputs and checking the outputs.
| Static testing | Dynamic testing |
|---|---|
| No code execution | Code is executed |
| Finds defects in documents and code directly | Finds failures caused by defects |
| Can start on day one | Needs a working build |
| Examples: requirement review, code review | Examples: functional testing, regression testing |
Static testing catches problems such as ambiguous requirements, missing validations and contradictory rules that dynamic testing may never reveal, and it does so at the lowest cost.
Types of Reviews
Reviews range from very informal to highly formal.
| Review type | Led by | Formality | Main purpose |
|---|---|---|---|
| Informal review | No formal leader; often a colleague | Lowest; no documented process | Quick feedback, for example asking a peer to check your test cases |
| Walkthrough | The author | Low to medium | Author explains the document to the team to share knowledge and gather feedback |
| Technical review | A trained moderator or technical lead | Medium | Peers with technical expertise evaluate the work product and reach consensus |
| Inspection | A trained moderator (not the author) | Highest; defined process, checklists, metrics | Find the maximum number of defects and improve the process |
Roles in a formal inspection
- Moderator: plans and runs the inspection meeting and ensures follow-up.
- Author: the person who created the document; fixes the defects found.
- Reviewers (inspectors): examine the document and identify defects using checklists.
- Scribe (recorder): records the defects and decisions during the meeting.
- Reader: in some processes, paraphrases the document section by section during the meeting.
The requirement says "Refund will be processed for cancelled tickets." During a walkthrough, the tester asks: within how many days, to which payment source, and what about partially cancelled bookings? Three gaps are fixed in the document before a single line of code is written.
Do not say that verification is "done by developers" and validation is "done by testers". Testers actively perform verification by reviewing requirements and designs, and developers also perform validation through unit tests.
