Agile Testing Quadrants: Plan a Balanced Test Mix for Each Feature

A delivery-address change can have plenty of automated checks and still leave important questions unanswered. The save handler might persist the expected fields, while the screen makes a rejected edit look successful. The business examples might cover an ordinary update, while nobody has discussed what happens when dispatch starts during the save.

The agile testing quadrants help a team notice these different purposes before adding more tests of the same kind. They organize conversations along two axes: business-facing versus technology-facing concerns, and tests that guide development versus tests that critique the product. A balanced testing approach gives important risks relevant evidence and an explicit decision about remaining gaps. It does not require an equal share of tests or time in every quadrant.

Read the Two Axes by Purpose

Lisa Crispin and Janet Gregory describe the quadrants as a thinking and planning tool. Use the model to ask what the team needs to learn, which skills and environments that learning requires, and who should discuss the answer. It is a planning lens within a wider quality strategy, rather than a complete strategy or a release-readiness certificate.

Business-Facing and Technology-Facing Questions

Business-facing tests express concerns in terms that customers, product specialists, and other business participants can evaluate. For an address change, those concerns include who may change the destination, when the change is allowed, and whether the customer understands the outcome. Examples, prototypes, workflow evaluation, and exploratory testing can contribute different kinds of evidence.

Technology-facing tests examine how the implementation behaves and what technical conditions it can withstand. Component behavior, persistence failure, concurrency, performance, and access-control enforcement may need attention. The relevant question could be whether a failed write preserves the previous address, rather than whether the confirmation message is understandable.

These categories do not separate manual work from automation. A business rule can become an automated example below the user interface. A technical risk can require an expert's investigation and interpretation. Choose the implementation method after clarifying the question and the evidence needed to answer it.

Guiding Development and Critiquing the Product

Tests that guide development help people decide what to build and provide feedback while they build it. A reviewed example of a locked order can clarify an ambiguous rule. A component check can shape failure handling and give feedback when that code changes.

Tests that critique the product investigate the behavior of a working increment and challenge the team's current understanding. Exploration may reveal confusing feedback that the original examples missed. A controlled concurrency investigation may expose an unsafe interaction between address updates and dispatch processing.

Using the familiar quadrant labels, the purpose pairs are:

• Q1: Technology-facing tests that guide development, such as unit and component checks.
• Q2: Business-facing tests that guide development, such as examples and story acceptance tests.
• Q3: Business-facing tests that critique the product, such as exploration, workflow evaluation, and usability testing.
• Q4: Technology-facing tests that critique the product, such as performance, security, and recoverability investigations.

Terminology and diagrams can vary, so keep the purpose names beside the labels. The numbering does not prescribe a Q1-to-Q4 sequence. Crispin explicitly describes starting with an architectural performance investigation when that uncertainty dominated a feature. Investigation of a working increment needs something relevant to inspect, but planning its environment, skills, and criteria can begin earlier.

A test can also serve more than one purpose. An exploratory finding may become a business example that guides a fix, then a repeatable regression check. Forcing it into one permanent, exclusive bucket would hide that feedback.

Plan One Delivery-Address Change

Consider a fictional feature: a signed-in customer edits the delivery address of their own unshipped order. The following worksheet is an unexecuted design illustration. No application tests, customer observations, security investigations, or load tests were performed for it.

For discussion, propose that an authorized customer can save before dispatch starts, that rejected changes preserve the last committed address, and that a success indication corresponds to an address available on reload. These are starting assumptions for review, not accepted requirements. The business must still define the dispatch cutoff and what should happen if dispatch and an address update compete.

Keep the feature boundary narrow. Confirm whether repricing, shipment rerouting, or changes after dispatch belong to another feature instead of silently adding them. Approved address-validation examples, supported locales, workload expectations, safe test access, and decision authority are also unknown. Record those gaps before turning assumptions into test expectations.

Connect Each Purpose to Evidence and a Conversation

Use each quadrant to challenge the same feature. The proposed owners below identify useful conversations, not people who have accepted assignments. The evidence column describes what future work should retain, not results already obtained.

Check	Feature Risk or Question	Proposed Activity	Evidence to Seek	Proposed Conversation Owner
Q1: Technology-Facing, Guide Development	Can a failed save leave a partially changed address?	Component checks around validation and persistence failure	Approved address fixtures, unchanged prior record after rejection, failure-path assertions	Developer and tester confirm storage boundaries
Q2: Business-Facing, Guide Development	When may the customer change the destination?	Agree examples for own order before dispatch and locked order after dispatch	Reviewed examples with allowed or rejected outcomes and unchanged address on rejection	Product representative clarifies dispatch cutoff with fulfillment specialist
Q3: Business-Facing, Critique Product	Could the customer believe an unsaved address is confirmed?	Explore stale tabs, interrupted saves, correction messages, and reload behavior	Session notes and visible state compared with the persisted address; new questions recorded	Tester and designer review customer interpretation
Q4: Technology-Facing, Critique Product	Could another account change this order, or a race overwrite the dispatch address?	Authorized isolated access-control and concurrency investigations; plan workload checks if relevant	Account-boundary results, durable records, agreed invariants, and unresolved workload limits	Developer and security or operations specialist agree access and safe conditions

Follow a Risk Across Several Purposes

Take the possibility that another customer's order can be changed. In Q2, the team needs an explicit business rule about which identity may edit which order. In Q1, developers can check the relevant authorization decision at a suitable component boundary. In Q4, an authorized investigation can challenge whether the deployed feature enforces that boundary under the selected conditions. These activities support related claims, but one passing component check does not establish end-to-end account isolation.

The same approach applies to misleading confirmation. A Q2 example can state that a rejected update must not be presented as saved. Q3 exploration can investigate interrupted requests, stale tabs, and how a person interprets the resulting screen. If the interface says the new address is confirmed while reload shows the old one, retain the observation and ask which behavior is intended. Do not invent an answer to close the worksheet.

For the dispatch race, both the expected business outcome and the technical mechanism need attention. Until the responsible participants define the cutoff and the required consistency behavior, a test can reveal what the system does but cannot prove that behavior meets an unspecified requirement. Mark the decision as unresolved and identify the next conversation needed to establish a trustworthy expected result.

Choose the Next Activity by Risk and Readiness

A populated quadrant diagram can still conceal shallow coverage. Several successful ordinary saves provide little evidence about a partial write or an ownership boundary. Review the failure scenarios and ask what additional evidence each proposed activity would contribute.

For this address-change feature, use a collaborative planning sequence that follows the decisions rather than the quadrant numbers:

1. Identify a credible failure and its consequence. Changing another account's order, preserving the wrong destination, and confusing the customer are different scenarios with different consequences.
2. Find the largest decision-relevant uncertainty. If the dispatch cutoff is unknown, clarify it before treating a race outcome as a pass. If ownership enforcement is uncertain, agree the required investigation and safe access with the relevant specialists.
3. Check prerequisites and feasibility. Name the build, environment, accounts, controlled data, observation points, skills, and cleanup needed. An unavailable environment is a blocker, not evidence that a purpose has been covered.
4. Choose the next useful activity and record the remaining gap. Ask a responsible person to accept the proposed work and identify who can decide whether unresolved exposure is acceptable. Role suggestions in a worksheet are not commitments.

This procedure may lead to examples, a component change, exploration of a prototype, or preparation for a technical investigation. Dependencies can constrain execution even when a risk is important. If no safe way exists to create a dispatch race, record that limitation and discuss alternatives rather than improvising against live orders.

Balance means that significant risks have been considered from the relevant purposes. It does not mean equal test counts, equal time, or a fixed allocation across four boxes. Some features need substantial technical investigation; others need more work to understand customer behavior. Explain why a purpose needs little additional work, using existing relevant evidence or a documented decision. An empty box without an explanation leaves a question open.

Use Automation and the Pyramid Without Losing Purpose

The test pyramid complements the quadrants by prompting a different design conversation: at which abstraction level should a repeatable check run, and what feedback will it provide? The quadrants organize purposes. They do not decide whether every check belongs at unit, service, or user-interface level, and they are not another shape for the pyramid.

For the address-change rule, a focused component check might exercise persistence-failure handling without driving a browser. A business-facing example might exercise the allowed edit through a service boundary. A selected workflow check could confirm that the customer-facing path connects those parts correctly. Choose the layers according to the claim each check must support, the available observation points, and the setup and diagnosis costs. A lower-level check cannot verify a user interaction it never observes.

Avoid building duplicate checks solely to make the quadrant chart look full. Reuse relevant evidence where a check supports several purposes, and record its limits. Automation can make a known comparison repeatable; it does not establish that the comparison represents the right customer expectation or explores every unexpected interaction. Human exploration can challenge those expectations, while its findings can improve the automated examples.

Continuous delivery adds questions about when feedback is available and how the team observes a deployed change. The quadrants can help plan automated feedback, exploratory opportunities, monitoring, environments, and specialist involvement together. They do not make every investigation suitable for a pipeline or authorize production experiments.

Discuss performance and security concerns while the feature is being shaped, even if the eventual investigation needs a working increment. Any load, access-control, or resilience activity needs an authorized scope, controlled data, a suitable environment, and agreed stop conditions. For this example, no workload target, system capacity, or permission to test a real service is known. Those remain prerequisites to resolve, not values to invent from the diagram.

Review Evidence Before Calling the Mix Balanced

Keep the worksheet connected to future execution evidence. For an implemented check, record the question, approved expected outcome, tested build and environment, relevant conditions, observation, and unresolved limitations. A plan shows intent. A result supports only the conditions and behavior it actually examined.

Keep passed, failed, blocked, and not-run activities distinct. A component failure-path check could support preservation of the old address under its simulated failure, while leaving a real dispatch race unexamined. An exploratory session could identify confusing confirmation without establishing how often customers encounter it. Neither result justifies marking the whole feature safe.

Revisit the purposes when a business rule changes, an investigation finds a new interaction, or a prerequisite proves false. If a stale-tab session exposes an overwrite, bring that finding back to the business examples and technical checks. Preserve the original observation, agree the intended behavior, then choose confirmation and regression work that addresses the actual mechanism.

Before the next feature discussion ends, identify its most consequential unanswered question, the evidence that would reduce that uncertainty, and the person who should join the conversation. That produces a usable next action without turning the quadrants into phases or treating a completed diagram as proof of quality.