Agile testing quadrants

The American Software Testing Qualifications Board (ISTQB) has identified seven testing principles, one of which is “Exhaustive testing is impossible.” It’s not possible to test everything inside an application. Testing is complex, and testers are continually trying to identify what to test and which methodology to use.

Another principle states that “Testing is context-dependent.” How do we determine the type of testing that will best suit each situation? It’s not a simple decision and requires a lot of experience. This is where Agile testing quadrants come into play. Agile testing quadrants help us select the proper testing methodology to apply in different testing contexts. In this article, we’ll discuss Agile testing quadrants, how to utilize them, and some real-world situations where they have been applied.

What are agile testing quadrants?

The Agile testing quadrants are an evolution of the Agile testing matrix created by Brian Marick.

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 whether 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…”

1. On supporting the team that is developing the product or on criticizing the product?
2. 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-world examples

In this section, we will illustrate how to use the Agile testing quadrants to select the best methodology to apply, depending on the context presented in each example. The goal is to explain how you should think when selecting the correct testing methodology.

Use case #1

Simple business rule bugs are not being found. We know that:

• we are addressing business rule bugs, so we will not select quadrants 1 or 4
• we need to support the team to find more bugs before delivering to customers

We can infer from this that we should select either quadrants 2 or 3, but given that the team needs more support, we properly select quadrant 2.

Use case #2

The application has millions of users but was not built to handle higher loads. We know that:

• We are considering critiquing the application with a higher load, so we will not select quadrants 1 or 2.
• We are considering performance at higher loads, so we should examine whether the technology used to develop the product is suitable.

We can infer that we should select either quadrants 3 or 4, but given that we are focused on technology, we properly select quadrant 4.

Use case #3

A customer claims that the application does not work as defined in the requirements. We know that:

• We are addressing business rule bugs, so we will not select quadrants 1 or 4.
• We need to critique the application in order to find more bugs before delivering it to the customer.

We can infer we should select either quadrants 2 or 3, but given that we have to critique the application we properly choose quadrant 3.

Conclusion

Even though the agile testing quadrants theory is more than 20 years old, it is still relevant. It is a simple tool that can help QA professionals choose the best testing method in a specific context.

About the author

Paulo Oliveira

I’m a proactive, cooperative, and responsible Quality Assurance Engineer with more than 14 years of experience in software testing. I love to automate tests for all kinds of applications (both backend and frontend) to improve the team’s workflow, product quality, and customer satisfaction. Even though my main roles were hands-on testing applications, I’ve worked as QA Lead, planning and coordinating activities, as well as coaching and contributing to team members’ development. Mentoring people to achieve their goals is also something that makes my eyes shine.