agile-testing-quadrants

Agile Testing (Crispin & Gregory)

This skill operates at a higher altitude than the other testing skills in this repo. They tell you how to write or fix one good test; this tells you what kinds of testing a team and product need, who owns them, and how they fit together. Reach for it for strategy questions — planning a feature's or release's testing, deciding whether you need exploratory or performance testing, defining "done," or organizing testing across a whole team.

The book's two foundational ideas: quality is a whole-team responsibility (not a QA phase bolted on at the end), and the Agile Testing Quadrants give you a map for making sure no important kind of testing is forgotten. The other skills own the craft inside the quadrants; this skill owns the map.

---

The two axes

The quadrants come from Brian Marick's model. Classify any kind of testing on two independent axes:

• Who it's for: supporting the team vs. critiquing the product. Support tests guide development — they're written (often first) to help the team build the right thing correctly. Critique tests examine the finished product to find where it falls short (gaps, weaknesses, things only visible once it exists).
• What it faces: business-facing vs. technology-facing. Business-facing tests are expressed in the language of the customer/domain ("a gold customer gets free shipping"). Technology-facing tests are expressed in the language of programmers ("this function returns null on empty input").

Cross the two axes and you get four quadrants.

---

The four quadrants

Q1 — Technology-facing, supports the team. Unit tests, component tests, integration / API tests. Written by programmers (often test-first) to build the code right. Automated, fast, run constantly. → This is exactly the craft of khorikov-unit-testing, art-of-unit-testing, effective-software-testing, and xunit-test-patterns. This skill just places it on the map; those skills tell you how to do it well.

Q2 — Business-facing, supports the team. Functional tests, story tests, examples turned into executable acceptance tests, prototypes, simulations. They capture what the customer wants and drive development (ATDD/BDD/Specification by Example). Automated and manual — examples are automated; eliciting them is a human conversation.

Q3 — Business-facing, critiques the product. Exploratory testing, scenario testing, usability testing, user acceptance testing, alpha/beta. Humans using the product to find what automated checks can't — surprises, confusion, missing value. Largely manual (tool-assisted). → The exploratory mindset and techniques here belong to context-driven-testing.

Q4 — Technology-facing, critiques the product. Performance, load, stress, and scalability testing; security testing; reliability; and the other "-ility" / quality attributes. Tool-driven, often needing specialist tools and skills.

---

How to use the quadrants (and how not to)

• The numbers are labels, not a sequence. Q1 isn't "first" and Q4 isn't "last" — the four happen continuously and in parallel throughout development. Don't read them as phases.
• Use them as a coverage checklist, not a quota. For a feature or release, walk the four quadrants and ask "what testing does this need in each?" Some features need heavy Q4 (a payments service: performance + security); some need heavy Q3 (a new UI: usability + exploratory); all need Q1. The point is to not forget a whole category.
• Plan per context. The right mix depends on risk and product. A library has little Q3; a consumer app has lots. Let risk drive where the effort goes — this connects to the context-driven mindset in context-driven-testing.

A practical planning move: at the start of a story or release, sketch the quadrants and note which tests each quadrant calls for, who'll do them, and whether they're automated or manual. That sketch is the test strategy.

---

The whole-team approach

The single biggest shift the book argues for: the whole team owns quality, not a separate QA group at the end. Programmers write Q1 tests; the team collaborates with the customer on Q2 examples; testers bring an investigative eye to Q3 and specialist Q4 tools; everyone is responsible for the product being good. Testers stop being gatekeepers and become quality coaches who spread testing skill across the team.

The agile testing mindset is captured in the book's Ten Principles for Agile Testers: Provide Continuous Feedback, Deliver Value to the Customer, Enable Face-to-Face Communication, Have Courage, Keep It Simple, Practice Continuous Improvement, Respond to Change, Self-Organize, Focus on People, and Enjoy. Detail in references/whole-team-quality-and-done.md.

---

Define "done" explicitly

Agile teams get into trouble when "done" is vague. The book insists on an explicit, shared definition of done at multiple levels — a story isn't done when the code compiles; it's done when it's coded, its Q1–Q2 tests pass, it's been explored (Q3), relevant Q4 checks pass, and it's been shown to meet the customer's examples. Likewise a release has its own, larger definition of done. Make the checklist explicit and visible so "done" means the same thing to everyone. Detail in references/whole-team-quality-and-done.md.

---

Automation strategy in brief

• Lean on the test automation pyramid (Cohn): a broad base of fast Q1 unit tests, a smaller middle of Q2 functional/service tests, and a thin top of slow UI/end-to-end tests. Inverting it (mostly UI tests) gives a slow, brittle suite — the same trade-off Khorikov's four pillars describe.
• Automate regression testing so humans are freed for the work only humans can do (Q3 exploratory). Manual regression testing doesn't scale and burns out the team.
• Treat flaky/slow/duplicated tests as technical debt and pay it down; an untrusted suite gets ignored. (Diagnose with xunit-test-patterns.)

Detail, plus the scale/DevOps/continuous-delivery topics, in references/automation-strategy-at-scale.md.

---

Reference files

• references/agile-testing-quadrants.md — the two axes and four quadrants in full, the test types in each, and how to plan with them.
• references/whole-team-quality-and-done.md — the whole-team approach, the Ten Principles, shared responsibility, the definition of "done," and the seven key success factors.
• references/automation-strategy-at-scale.md — the automation pyramid, regression automation, managing test technical debt, and (from More Agile Testing) testing at scale, in DevOps/continuous delivery, and visualizing quality.

../../EXAMPLES.md (repo root) has worked examples under "Agile Testing." Because this skill is strategy-level, its "examples" are planning artifacts (a quadrant plan, a definition of done) rather than code before/after pairs.