# Testing Principles

The 7 Testing Principles are the fundamental principles that guide an effective testing approach.

<div data-full-width="true"><figure><img src="https://i.gifer.com/RrVB.gif" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
**The goal is to design a thorough yet feasible set of test cases that exercises the system as thoroughly as possible within time and resource constraints.**
{% endhint %}

<table data-full-width="true"><thead><tr><th>Principle</th><th>Definition</th><th>Explanation</th><th>Example</th></tr></thead><tbody><tr><td>🔁 Testing shows the presence of defects</td><td>Testing can only identify the <mark style="background-color:yellow;">presence</mark> of defects, not their <mark style="background-color:red;">absence</mark></td><td>Testing should be continued to ensure that all defects are caught and resolved</td><td>A defect is found during testing, corrected, and then retested</td></tr><tr><td>❌ Exhaustive Testing is not possible</td><td>A black box testing technique where you systematically test all possible combinations of inputs and conditions to uncover errors.</td><td>To "exhaust" 💯 all possibilities in order to have high confidence ✅ in the stability and robustness of the system.</td><td>Test valid values 🟢, invalid values 🔴, edge cases 🟠, repetition of valid/invalid values 🎡, and different combinations.</td></tr><tr><td>🚀 Early testing</td><td>Start testing <mark style="background-color:green;">early</mark> in the SDLC to capture and eliminate defects in the early stages</td><td>By identifying and resolving issues early on, the cost and time required for testing and rework can be significantly reduced</td><td>Testing during the requirement gathering and design phases</td></tr><tr><td>🔍 Defect clustering</td><td>A small number of modules usually contain most of the defects detected during pre-release testing or operation</td><td>More testing efforts can be focused on these modules, which can help to reduce the number of defects in the software</td><td>Modules that contain most of the defects are identified and more testing is focused on them</td></tr><tr><td>🤝 The pesticide paradox</td><td><mark style="background-color:yellow;">Vary the testing techniques and methods</mark> used to ensure that all defects are caught and resolved</td><td>Repeating the same testing techniques may not catch defects that were caught and resolved initially</td><td>Using a variety of testing techniques such as unit testing, integration testing, and system testing</td></tr><tr><td>👨‍👩‍👦‍👦 Testing is context-dependent</td><td>Consider the <mark style="background-color:blue;">context</mark> in which the software is being developed and tested</td><td>The testing approach and techniques used may vary depending on the context</td><td>Testing approaches and techniques used for web-based software may differ from those used for mobile applications</td></tr><tr><td>📈 Pareto principle</td><td>80% of the defects are likely to be caused by 20% of the modules</td><td>Focusing on this 20% of modules can help to improve the quality of the software</td><td>Identifying and focusing on the 20% of modules that are likely to have the most defects</td></tr></tbody></table>