How do you use the agile testing quadrants to decide which checks a release needs?

## The two axes The agile testing quadrants are a two-by-two grid, and both axes are worth stating precisely because candidates routinely substitute the wrong ones. The horizontal axis is **who the check speaks to**. A *business-facing* check is expressed in the vocabulary of the people who asked for the system: accounts, tariffs, entitlements, workflows. A *technology-facing* check is expressed in the vocabulary of the people building it: modules, interfaces, latency, memory, error handling. This is not the same as the functional/non-functional split, and it is not about who runs the check. The vertical axis is **what the check is for**. Checks that *support the team* are written to guide work while it is being done: they say quickly and unambiguously whether the thing under construction still behaves, and they are cheap to re-run. Checks that *critique the product* are aimed at something that already exists, and their job is to find problems that nobody anticipated well enough to encode in advance. ## The four cells - **Technology-facing, supporting the team.** Developer-owned component and integration-level checks. Fast, deterministic, owned by whoever wrote the code, run constantly. - **Business-facing, supporting the team.** Worked examples and business-readable functional checks agreed before the work starts; prototypes and simulations that settle what "done" means in domain language. - **Business-facing, critiquing the product.** Exploratory sessions against charters, usability observation, user acceptance work — a human exercising the built product and judging it, with judgement rather than a script as the oracle. - **Technology-facing, critiquing the product.** Quality-attribute work: load and stress behaviour, resilience under failure, security probing, resource behaviour over time. Usually needs specialist tooling and a realistic environment. The numbering that usually accompanies the grid is a **conventional label, not a sequence**. Nothing says the first cell runs before the fourth, and the authors of the model are explicit about that. The exact cell some check types belong in is argued over — that argument is far less interesting than what the grid is for. ## Using it as a diagnostic The grid earns its place when you stop treating it as a taxonomy and start using it as a coverage map for **kinds of evidence**. Plot what a release actually plans, then look at the shape. A smart-meter reading feed ships on a 3-week release train, and the release plan for the coming train lists 1,140 automated checks. Plotted, almost all of them sit in the technology-facing supporting-the-team cell, with a thin band of business-readable functional checks. Both critique cells are empty. Two consequences follow directly, and neither is visible from a pass-rate figure. No business-facing critique means nobody exercised the product as a real operator would. That is the gap that let a permission escalation through: the entitlement rule for reading a household's consumption history was implemented exactly as specified and checked exactly as specified, and only a technician actually using the thing would have noticed that the rule granted far more than anyone intended. Scripted checks confirm known expectations; they cannot notice something nobody thought to expect. No technology-facing critique means nothing established how the ingest path behaves when the half-hourly meter window bunches up after an outage and 218,400 readings arrive in one burst instead of spread across the window. Every functional check passes at trivial volume. The grid does not tell you how much of each cell you need — that is a risk judgement, and it depends on what the release actually changes. What it gives you is a quick, honest picture that a count of automated checks cannot: a release can be extremely well covered in one cell and have no evidence at all of the kind another cell produces. ## Its limits The grid says nothing about depth, sequencing, or how much is enough. It has no notion of risk weighting on its own, so a full grid with shallow work in every cell can look healthier than a deliberately lopsided plan that concentrates effort where the change is. Cell assignment gets argued about — where a contract check or an accessibility check belongs is a genuine debate — and those arguments are usually a waste of a planning session. Treat the model as a conversation starter that exposes a missing kind of evidence, then make the actual sizing decision on risk. ## Answering it well State both axes precisely, name what lives in each cell, say the numbers are labels rather than an order, and then show the diagnostic use: a real release whose plan was all one cell, and what that cost. Reciting four cell names without the diagnostic use is the weak version of this answer.