Agile Testing Quadrants

Agile testing quadrants could be considered as a manual layout that divides the whole agile testing methodology into four quadrants for arranging the testing types to be performed at each different level to achieve the agile manifesto. It helps the testing team to identify, plan, and execute the testing needed.

Agile Test Quadrants (introduced by Brian Marick) enables us to understand the relationship between the various forms of tests using 4 different quadrants:

  1. Agile Quadrant 1: Technology-facing tests that support the team
  2. Agile Quadrant 2: Business-facing tests that support the team
  3. Agile Quadrant 3: Business-facing tests that critique the product
  4. Agile Quadrant 4: Technology-facing tests that critique the product

Agile Testing Quadrants

Agile Q1 – Technology-facing tests that support the team

This quadrant mainly focuses on the code quality of the software. It covers Unit tests, API tests, etc. which can be also automated. These tests help to get an initial overview of the product. It helps the developer to verify the acceptance criteria of the user story. They help in improving the design as a part of test-driven development as many design flaws are expected to get caught through this process.

They are written and maintained mostly by the developer. The main objective of these tests is to improve the Quality of the product by proper source code management, integrated with the development environment. Some of the commonly used frameworks support unit tests framework are Junit(Java), Nunit(C), etc.

Agile Q2: Business-facing tests that support the team

This quadrant mainly focusses on covering the business requirements of the software. Generally, functional tests, workflows, story tests, prototypes & simulations are done at the system level to validate the product behavior. The testing team also interacts with clients or stakeholders to understand better the workflows or requirements which would ultimately help in creating verification test cases.

These tests can also be automated to a certain level. Many tools and frameworks like Cucumber, Selenium, QTP, etc. can be used to automate the test cases. It is necessary to note that manual effort is still needed to test certain edge cases apart from having automated tests.

Agile Q3: Business-facing tests that critique the product

This quadrant mainly focusses on evaluating the product from the user’s face. Various type of tests such as Exploratory tests, Usability Tests, Alpha, and Beta tests is performed. The product is also evaluated by the actual user by means of the pilot test, demo, and feedback is collected about the user experience, improvements, etc.

These tests happen in the environment which is very similar to the actual one. Majorly performed are manual as it involves a lot of intuition and critical thinking about the product. It also requires the use of Simulators and Emulators.

Agile Q4: Technology-facing tests that critique the product

This quadrant focuses on verifying the non-functional requirements such as performance, security, database, etc. The objective of this is to verify the ultimate finished product. These tests are performed based on priorities as defined early in the SDLC phase.

The testing types covered are performance testing, load testing, stress testing, maintainability testing, security testing, reliability testing, recovery testing, etc. These tests are carried out with the help of various tools like Jmeter, Loadrunner, etc.


Test Strategy for Agile Testing

The purpose of the test strategy is to provide the best practices on strategize testing in an agile project. The document is used by the agile project team to plan the testing activities. Here below are the information added in the test strategy document:

1) Project Overview

This section briefs about the overview of the project. It can include below details

What was the need for the project?

What objectives the project will attain?

2) Requirements Scope

The requirement scope includes the user stories going to be covered in the sprint. It also includes the bug fixes from the previous sprint. It also defines the scope that might cause the impact on different modules within the system due to the new user stories or change requests.

3) High-Level Test Plan

Test Plan is a separate document. In the test strategy, a high-level test plan can be included. A high-level test plan can include test objectives and test scope.

4) Test Approach

This section describes the testing approach that will be followed during the testing life cycle. It defines the testing strategy, roles and responsibilities of various team members, and test types.

5) Test Coverage

This section describes the processes that the testing team will follow in order to optimize the coverage of product backlog/user stories in test scenarios and test cases. Requirement Traceability Matrix: (RTM) can be used to trace all the user stories with respective test scenarios and test cases.

6) Test Environment

It defines the environments where the testing is going to be performed. It also specifies the type of testing with the owner. If any testing tool is used in the sprint for test management, automation, performance, etc. then that is also specified in this section.

7) Test Deliverables

List out all the Testing deliverables

  1. Test Strategy Document
  2. Requirement Traceability Matrix
  3. Automated Test Scripts
  4. Test Summary Report

8) Defect Management

It defines the defect management workflow that is used for defect tracking & defect triage process in the sprint. Several methods for handling defects like defect prevention, defect discovery, and resolution are used by software developers, and testers are included in this section.

9) Assumptions, Risks, and Dependencies

It describes the assumptions on which the project is based. These may include timing, resources, and system capabilities.

10) Appendix

Include stuff like Roles & Responsibilities, Work Time Zone, and References in this section.