Agile Testing Quadrants
19th Apr, 2020
What is Agile Testing Quadrants?
It is a matrix that helps testers to ensure that they have considered all of the different types of tests that are needed to deliver value.
On one axis, we divide the matrix into tests that support the team and tests that critique the product. The other axis is divided into business-facing and technology-facing tests. The order of quadrants has nothing to do with the order and schedule of test execution. There are lot many factors that determine when to test, some of them are,
- Project risk factors
- The goal of the product
- Legacy code or a greenfield project
- Availability of testers to perform the testing
and so on.
Let us see the tests that support the team:
Agile Test Quadrant I
The purpose of Quadrant-1 tests or the "Technology facing tests that support the team" is test-driven development or test-driven design. Heard of TDD? That is it. The process of writing the tests first helps programmers to design their code better. These tests help the programmers write the code confidently to deliver a feature without worrying about leaving regression issues that lead to unintended changes in the system. The tests were written in the same programming language as the application. These tests are not for the customers or the Product Managers/Product Owners/Business Analysts as they will not understand a thing. These tests are automated and help in continuous feedback about the code quality.
Agile Test Quadrant II
Quadrant-2 tests are derived from examples provided by customers or by the business people (PO/PM/BA). These are "Business facing tests that support the team." They are also known as customer-facing tests. Business-facing tests run at a functional level, verifying business conditions, and use cases. These tests are understandable by customers and PO/PM/BA. The tests designed in this quadrant confirms the desired behavior of the product at a higher level. These tests are both automated and as well as manual. Frequently used test cases need to be automated to achieve more ROI. These automated tests should regularly run for the team to get faster feedback.
If you take a 3-tier application or product as an example, these automated cases have a focus on the application and business logic. These tests are not for the UI or Presentation tier. Mock-ups, wireframes, and other methods to validate the product's UI/UX comes within this quadrant. They are confirmed as part of this quadrant and not are automated.
Behavior Driven Development, Example Driven Development, and Specification by example are some types of tests that are executed as part of Quadrant-2 to help testers, programmers, and the business.
How Quadrant-1 and Quadrant-2 tests are supporting the team?
Faster feedback is the right word to use for these quadrants. They help the team is getting speedier feedback as the product is still under development. Verifying business logic at the early stage development helps the organizations to build a technically sound product and shield it from causing unexpected results at a later point. The team delivers the apt business value expected by the customers.
- The team writes code only for the feature that is under development, avoiding any unexpected code logic showing up.
- The team writes the code logic as per the business requirement, thus providing value to the customers.
Let us see the tests that critique the product:
"Critique" is considered as a negative term, while critique also means suggestions for improvement. In this context, critiquing means constructively reviewing the product to learn how to improve it.
Agile Test Quadrant III
Quadrant-3 tests are "Business Facing Tests that critique the product." How do we know whether we are delivering what customers want? We have created an excellent product as per our knowledge; the business people validated it as per the examples they have provided. What if the team misunderstood some cases even though they have the code and passed the business-facing tests? Now you will understand the need for critiquing the product.
These tests simulate the real-world application of the product through the eyes of real users. The tests in this quadrant are manual and are not automated. It needs a pair of human eyes to experience the UX of the product along with the functionality. Some of the automated flow of the product can be used to save time.
User acceptance (UAT), Usability, and exploratory testing activities are present in this quadrant. User acceptance tests provide a chance to the customers to perform tests on the product and help them in approving the completed features.
Exploratory Testing stands out in this quadrant. While conducting exploratory testing sessions, the tester simultaneously designs and as well as perform tests. These are not scripted tests and are not ad-hoc either. Test Engineers use their creativity and intuition to test the product just like an end-user. Many of the severe bugs were identified in this process.
Agile Test Quadrant IV
Quadrant-4 tests are "Technology Facing Tests that critiques the Product." These tests used to critique the product characteristics and not functionality. These tests are tools intensive and need expertise on the tools to test. The majority of the time, the non-functional requirements are not called out and are expected by the developers to cover them as part of their developmental activities. Some of the non-functional requirement is more important than the actual functionality. Take the example of an e-commerce website. How many of you are ready to wait until the pages load up every time you search for a product? Response time is more critical to the product like those. Some of the non-functional tests are Performance, Load, Stress, Security, etc.
Automation is very much mandatory for performance and load testing activities. These tests are too necessary and should not be ignored or kept last always. Either these tests should be completed along with the functional tests or even before them.
For the majority of the products, we need all categories of testing discussed under the four quadrants. Not every feature needs non-functional testing like performance, stress, security, etc. but it should not be omitted just because the team could not think of test cases for it. The technology-facing and the business-facing tests are core for any Agile Development. By identifying the tasks needed to perform the technology and business-facing tests that critique the product, one can understand what the product is missing. Each quadrant helps the team in delivering quality features to the customers.