logo logo

Agile Testing Quadrants

Agile Testing Quadrants

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.

Agile Testing Quadrants

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:

How to Use the Agile Testing Quadrants

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

Avatar

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 kind of applications (both backend and frontend) in order 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 member’s development. Mentoring people to achieve their goals is also something that makes my eyes shine.

Website- https://paulocoliveira.github.io/qa/

LinkedIn- https://www.linkedin.com/in/pcesar/

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now  

Leave a Reply

popup image

A new world for test automation

Join 150,000 testing & dev teams taking their web & mobile testing to new heights, using #1 FREE test automation platform, designed to help deliver quality at speed.
Get Started
FacebookLinkedInTwitterEmail