> For the complete documentation index, see [llms.txt](https://qatesting.gitbook.io/qa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://qatesting.gitbook.io/qa/manual-testing/overview/testing-principles.md).

# 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>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://qatesting.gitbook.io/qa/manual-testing/overview/testing-principles.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.