According to one of the 7 testing principles of the ISTQB Syllabus, “Exhaustive testing is impossible”, so it is not possible to test everything inside an application. Testing can be difficult in some situations and testers are always trying to identify what to test, and which technique to use.
Another testing principle states that “Testing is context-dependent”, telling us that we should do different tests depending on the context. However, how can we select what kind of testing will better satisfy each situation? 
This is not a simple decision and requires a lot of experience.
The agile testing quadrants are an interesting tool that helps us select techniques to apply in different testing contexts. They will be presnted in this article, and you will learn how to use them. We will also show some real situations where we can apply them.
What are the Agile Testing Quadrants?
The agile testing quadrants are an evolution of the agile testing matrix created by Brian Marick. Their concept is to give ideas on how to test an application, depending on the business context you are involved in.
https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
The matrix is divided into four quadrants (it does not inform priority, it’s just a number), and each side of the quadrant is related to one different aspect:
- Business Facing.
- Critique Product.
- Technology Facing.
- Supporting the Team.
The quadrants also suggest if the techniques are more suitable for manual testing, automated testing, or both. Each of the quadrants indicates different reasons for testing 
Let’s review them:
Quadrant 1
The first quadrant suggests some techniques that support the team, looking from a technological perspective. This is focused on testing the code using unit tests and component tests.
Quadrant 2
The second quadrant also suggests some techniques that support the team, but now from a business perspective. The goal here is to focus the testing activities on the business rules, by using functional tests, examples, story tests, prototypes, and simulations.
Quadrant 3
The third quadrant suggests techniques that can help the team to critique the product by focusing on the business perspective. Exploratory testing, scenarios, usability testing, user acceptance testing, alpha, and beta testing are some of the suggested techniques.
Quadrant 4
The fourth quadrant suggests techniques focused on criticizing the product from the technological perspective. It indicates the use of performance testing, load testing, security testing, and some other “ility” testing types such as accessibility, reliability, portability, etc..
How to Use the Agile Testing Quadrants
We can return to what Brian Marick created first- a simple matrix that only has the quadrants and their faces:
http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2
The first thing you should do is understand the context in which you have to test 
There are two questions that you should answer to define which quadrant you will use.
Before the questions, it is important to highlight that these questions should be answered for a specific context, and you should use the suggested techniques for that context. The agile testing quadrants do not indicate that you will only use that set of techniques in the whole project, but only where they are needed.
Going back to the questions, ask yourself: “In this context, should I focus my testing activities…”
- On supporting the team that is developing the product or on criticizing the product?
- On business requirements or on bugs that can be found in the technology used to build the product?
The combination of the answers to both indicates the quadrant you should select! You should select one of the indicated techniques in that quadrant and use it. Another important thing to mention is that there are a lot of other kinds of testing techniques that are suitable to be used but which are not shown in the matrix.
Remember that this is a 20-year tool that is still relevant, and even though it was updated throughout the years, new techniques are always being developed and could fit your purpose. The main idea is to understand what kind of test is applicable to that context, and then select a proper testing technique to use.
Real Use Cases
In this section, we will present 3 examples of how to use the agile testing quadrants to select the best suitable techniques to apply, depending on the context presented in each example. The goal of this section is to explain how you should think when you have to select the correct quadrant.
First example
Simple business rule bugs are not being found. Using the agile testing quadrants, we can reflect on:
- We are trying to deal with business rule bugs, so we will not select quadrants 1 or 4.
- They are simple bugs missed, so the idea is that we need to support the team to find more bugs, before delivering to customers.
We can infer that for question 1, we should select either quadrants 2 or 3. But given that in the second question we noticed that the team needs more support, we can finally select quadrant 2.
Second example
The application starts being used by millions of users but was not intended to be. Using the agile testing quadrants, we can reflect on:
- We are thinking about testing the application in a critique situation with lots of users starting to use the application, so we will not select quadrants 1 or 2.
- We are not worried about the business rule impact, but we are concerned with what will happen with the application when these millions of users are using it. So we should think about the technology used to develop the product to understand if it is suitable or not.
We can infer that for question 1 we should select either quadrants 3 or 4. But given that in the second question we noticed that we have to deal with technical problems, we can finally go for quadrant 4.
Third example
A customer said that the application is not working as defined in the requirements. Using the agile testing quadrants, we can reflect on:
- We are trying to deal with business rule bugs, so we will not select quadrants 1 or 4.
- We need to criticize the application, in order to stress it and find more bugs before delivering it to the customer.
We can infer that for question 1 we should select either quadrants 2 or 3. But given that in the second question we noticed we have to criticize the application, we can finally choose quadrant 3.
Conclusion
Even though the agile testing quadrants theory is more than 20 years old, it is still important and relevant. It is a simple tool that could help QAs choose the better method to test in a specific context. The agile testing quadrants is a decision-making tool and will be an excellent fellowship to have by your side in your day-to-day work 