Agile Testing Quadrants Explained, With Examples
Four quadrants, two questions, one balanced test strategy: what belongs in each quadrant and how to use them to plan a release.
For QA engineers and leads building an agile test strategy, and teams that want a quick way to see what their testing covers.
What Are the Agile Testing Quadrants?
The agile testing quadrants are a model that sorts tests into four groups using two questions: is the test business-facing or technology-facing, and does it support the team during development or critique the finished product? Teams use the resulting grid to plan a balanced mix of testing and to spot the kinds they are missing.
The model started as Brian Marick's testing matrix and was developed by Lisa Crispin and Janet Gregory in their book Agile Testing. It describes why a test exists, which makes it a planning tool as much as a classification.
The Two Axes
| Axis | What it means |
|---|---|
| Business-facing | Described in terms a product owner or customer understands: features, rules, workflows |
| Technology-facing | Described in terms of the code and the system: units, interfaces, response times, vulnerabilities |
| Supporting the team | Written before or during development to guide the work and catch regressions |
| Critiquing the product | Run against working software to find what the specification did not anticipate |
The Four Quadrants
The grid below follows the usual layout: business-facing tests on top, technology-facing below, supporting tests on the left and critiquing tests on the right.
Q2: Business-facing, supporting the team
Confirm each story does what the business asked for.
Examples: Functional tests, story and acceptance tests, examples, end-to-end flows, prototypes
Usually: Manual and automated
Q3: Business-facing, critiquing the product
Find out whether the product works well for real people.
Examples: Exploratory testing, usability testing, user acceptance testing, alpha and beta tests, demos
Usually: Mostly manual
Q1: Technology-facing, supporting the team
Give developers fast feedback that the code works as designed.
Examples: Unit tests, component tests, API contract tests
Usually: Automated
Q4: Technology-facing, critiquing the product
Check quality attributes beyond functionality.
Examples: Performance and load testing, security testing, reliability, compatibility across browsers and devices
Usually: Specialist tools, plus manual checks
Definitions of the individual test types, with when to use each, are in Software Testing Types Explained.
How to Use the Quadrants to Find Gaps
The quadrants are most useful as a checklist at the start of a release or a large feature. List the testing you have planned, place each item in a quadrant, and look at the empty or thin ones.
| Quadrant | Planned testing | Result |
|---|---|---|
| Q1 | Unit tests for the new tax calculation | Covered by developers in CI |
| Q2 | Functional and boundary cases for the new checkout steps; regression for saved cards | Covered |
| Q3 | Nothing planned | Gap: add a time-boxed exploratory session and a usability check on mobile |
| Q4 | Load test from last quarter | Gap: re-run the load test and a cross-browser pass on the new pages |
The check took five minutes and added two activities that the plan would otherwise have left until after launch: real users struggling on mobile, and slow pages under peak traffic.
Quadrants in Practice
- Use the quadrants at the release or feature level; a single small story rarely needs all four.
- Plan Q1 and Q2 tests before development, from the acceptance criteria, so they guide the work.
- Book Q3 sessions as soon as a working build exists, while feedback is still cheap to act on.
- Schedule Q4 tests early for high-risk areas such as payments and logins, since they often need setup time.
- Revisit the grid in the retrospective: which quadrant found the most important defects this release?
Mapping the Quadrants in Evaficy Smart Test
Evaficy Smart Test manages manual and AI-generated test cases, so most of its work sits in the business-facing quadrants. Each generation produces cases for one test type, and the nine available types map onto the grid like this:
| Quadrant | Evaficy test types |
|---|---|
| Q1 | Outside the scope of test case management; unit tests live in your codebase and CI |
| Q2 | Functional, Acceptance, End-to-End, Smoke, Regression, Boundary Edge Case |
| Q3 | Exploratory, Usability, and Acceptance for UAT sessions |
| Q4 | Compatibility for browser and device checks; performance and security need dedicated tools |
To make gaps visible across a project, add the quadrant to each scenario's name or description, for example Q3 Checkout: exploratory charter. On the Enterprise plan, a Test PlanA test plan is a document defining the scope, approach, resources, and schedule for a testing effort. A test plan answers: what will be tested, what will not be tested, who will test it, what environments are needed, what the entry and exit criteria are, and what the risk mitigation strategy is. For agile teams, a lightweight test plan per sprint is more practical than a single upfront document.Full definition → groups the scenarios for a release and shows coverage as the share of its scenarios with at least one completed run, so an untouched Q3 scenario stands out before release day. Executing scenarios as test runs is covered in QA Test Run Execution.
Common Questions
Who created the agile testing quadrants?
Brian Marick introduced the testing matrix in 2003. Lisa Crispin and Janet Gregory developed it into the agile testing quadrants in their book Agile Testing (2009), and it remains one of the most widely used models for planning tests in agile teams.
Do the quadrant numbers mean an order?
No. The numbers are labels for discussion, not a sequence. Teams work in all four quadrants throughout a project, often within the same sprint.
Which quadrants should be automated?
Q1 is almost always automated. Q2 is a mix of automated and manual tests. Q3 is mostly manual, because it relies on human judgment. Q4 uses specialist tools for performance and security, plus manual checks for compatibility.
Are the agile testing quadrants the same as the test pyramid?
They answer different questions. The test pyramid suggests how many tests to have at each level, with many unit tests at the base. The quadrants describe why a test exists and who it serves, so a team can see which kinds of testing it is missing.
Does every story need tests in all four quadrants?
No. Use the quadrants at the release or feature level to check balance. A small story may only need Q1 and Q2 tests, while a new checkout flow probably needs all four.
Key Takeaways
- The quadrants sort tests by two questions: business or technology facing, and supporting the team or critiquing the product.
- Q1 is unit and component tests, Q2 is functional and story tests, Q3 is exploratory and usability testing, Q4 is performance, security and compatibility.
- The numbers are labels, not an order; teams work in all four throughout a project.
- Place your planned testing on the grid at the start of a release to find empty quadrants early.
- In Evaficy Smart Test, most test types map to Q2 and Q3, with Compatibility covering part of Q4.
Fill the business-facing quadrants faster
Create a free account and generate Functional, Exploratory or Usability cases from your acceptance criteria. The Basic plan includes 5 AI generations.
Create your free account