| name | agile-testing-quadrants |
| description | Plan a team's test strategy and decide what kinds of testing a product actually needs, using Lisa Crispin and Janet Gregory's "Agile Testing" — the Agile Testing Quadrants, the whole-team approach to quality, and an explicit definition of "done." Use this skill whenever the user asks what kinds of tests they need, how to plan testing for a feature or release, where exploratory / performance / usability / acceptance / security testing fit, who owns quality on a team, what "done" should mean, how to balance manual vs. automated testing, or how to shape a test-automation strategy — even if they never mention the book or Crispin & Gregory. Also for questions like "what should our test strategy be", "do we even need exploratory testing", "what's our definition of done", or "how do we split testing work across the team". This skill is strategy/process advisory — for writing an individual unit test use khorikov-unit-testing / art-of-unit-testing. Enforces: classify testing with the four quadrants; treat quality as a whole-team responsibility; and define "done" explicitly at story and release level. |
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.
