Brian Marick's Agile Testing Quadrants have been part of the agile testing vocabulary for over twenty years. They appear in ISTQB syllabi, in Lisa Crispin and Janet Gregory's influential "Agile Testing" book, and in countless QA presentations. They're also almost universally misapplied — usually because teams treat them as a classification taxonomy rather than a planning tool.
This distinction matters practically: using the quadrants as a taxonomy produces an interesting diagram. Using them as a planning tool produces better test coverage and clearer team responsibilities. Let's do the latter.
What the quadrants are
The Agile Testing Quadrants arrange testing activities on two axes:
- Vertical axis: technology-facing (tests that evaluate the code) vs. business-facing (tests that evaluate behaviour in terms meaningful to business stakeholders)
- Horizontal axis: supporting the team (tests that guide development, written alongside the code) vs. critiquing the product (tests that evaluate the finished product against expectations)
This creates four quadrants, each representing a distinct category of testing activity with different tooling, different ownership, and different timing in the delivery cycle.
ISTQB FL The ISTQB Foundation Level syllabus incorporates the testing quadrants as part of its agile testing context, framing them as a way to categorise different testing activities and their relationships to development work.
Q1: Technology-facing, supporting the team
Bottom-left. These are the tests developers write to support their own work: unit tests and component integration tests. They are automated, run continuously, and provide immediate feedback during development. They test code in isolation — a function, a class, a service boundary — and their purpose is to verify that the code does what the developer intends.
Q1 tests are owned by developers. They run in CI on every commit. They're fast — a full Q1 suite should run in under a minute. When a Q1 test fails, it tells you exactly which unit of code has broken and usually exactly why.
The common failure mode for Q1 is writing tests that mirror the implementation rather than testing behaviour. A unit test that essentially re-reads the code back to itself isn't testing anything useful. Q1 tests should be written against the intended behaviour — what should this function return given these inputs — not the implementation details.
Q2: Business-facing, supporting the team
Top-left. These are the tests that verify user stories and features from a business perspective, written to guide development and form the acceptance criteria for done. They include functional tests, story tests, and prototype/simulation tests.
Q2 tests are where the three-amigos session outputs live. The acceptance criteria from a story — "given a logged-in user, when they add an item to the cart, then the cart count increments" — become Q2 tests. They are often automated using BDD frameworks (Cucumber, SpecFlow) that express tests in business-readable language, or using Playwright/Cypress tests that exercise complete user flows.
Q2 is where QA and development collaborate most intensively. QA brings the perspective of what the business actually needs; development brings the context of what's being built. Tests in this quadrant are the executable specification — they define done, not just verify it.
Q3: Business-facing, critiquing the product
Top-right. These are the testing activities that evaluate the completed product from a user and business perspective — exploratory testing, usability testing, user acceptance testing, scenario testing. They are largely manual, require human judgment, and cannot be automated without losing the value they provide.
ISTQB FL Q3 is the quadrant most often underinvested by teams that chase automation coverage metrics. The pressure to automate everything naturally deflects effort away from the quadrant that is, by its nature, un-automatable. But Q3 is where a large category of important defects live: the bugs that result from incorrect requirements, unexpected user behaviour, usability failures, and interactions between features that no individual test case anticipated.
Exploratory testing — unscripted, curiosity-driven, hypothesis-testing — is the primary Q3 activity. The ISTQB Foundation Level syllabus defines exploratory testing as a technique where test design and execution are simultaneous and where the tester's knowledge, experience, and intuition guide the process. This is exactly what it sounds like: an experienced tester using professional judgment to probe the software's boundaries.
The output of a Q3 exploratory session is typically a session report: what was explored, what was found, what questions were raised, what areas need more structured testing. It is not a set of test scripts that can be replicated — and that's intentional. Each session is a unique investigation.
Q4: Technology-facing, critiquing the product
Bottom-right. Performance tests, security tests, load tests, stress tests — tests that evaluate the non-functional characteristics of the completed system. They are largely automated (you can't manually simulate 10,000 concurrent users) but they evaluate the finished product rather than guiding its construction.
Q4 is often treated as a release-gate activity — run the performance tests before go-live, check they pass, deploy. This is better than not doing them at all. It misses the value of integrating Q4 tests earlier. A performance regression introduced in sprint 3 is much cheaper to fix in sprint 3 than it is to diagnose and remediate in the release candidate phase. Q4 tests that run on a schedule against integration environments catch regressions close to their origin.
How teams misuse the model
The most common misuse is treating the quadrants as a completion checklist. "Do we have Q1 tests? Yes. Q2? Yes. Q3? We did some exploratory. Q4? We have load tests. We're done." This uses the quadrants to generate a status report rather than to plan effort.
The second misuse is automation dogma applied to Q3. Teams try to "automate Q3" by converting exploratory testing into scripted test cases. The scripted test cases then get automated. The exploratory intent is completely lost. The coverage that results is Q2 (structured, business-facing, supporting) rather than Q3, and the actual Q3 gap remains unfilled.
The third misuse is neglecting the vertical axis — treating all testing as either "business" or "technical" without distinguishing the supporting/critiquing dimension. This conflates test automation (supporting the team, built during development) with regression testing (critiquing the product, run after the fact). They serve different purposes and should be managed differently.
Using it correctly
Used correctly, the quadrants are a planning tool. At the start of a sprint or release cycle, map your planned testing activities to the quadrants:
- Q1: What unit and component tests will developers write for this sprint's features?
- Q2: What acceptance criteria have been specified, and how will they be verified?
- Q3: What exploratory testing will be done, by whom, and on what areas?
- Q4: What non-functional testing is required, and when will it run?
Gaps in this mapping are gaps in your coverage. A sprint that has Q1, Q2, and Q4 covered but no Q3 activity is a sprint that ships without anyone having used the software as a real user would.
The quadrants don't tell you how much to invest in each area — that requires risk analysis and context. What they do tell you is whether you've considered all four dimensions of testing. A mature QA function has activity in all four quadrants. An immature one, regardless of how sophisticated its Q1 automation is, has blind spots.
References: ISTQB Foundation Level Syllabus v4.0; Brian Marick, "Agile Testing Quadrants" (2003); Crispin & Gregory, "Agile Testing: A Practical Guide for Testers and Agile Teams" (2008).