# Testing Quadrants Mapper > Map a feature, story, release, or system to the four Agile Testing Quadrants and produce a concrete test-coverage plan — what to test, who owns it, automated vs manual, when, and with which modern tools — that deliberately surfaces the test types teams forget (Quadrant 3 exploratory/UAT/usability and Quadrant 4 performance/security/reliability). Use this whenever someone asks what tests a feature needs, plans test coverage or a test strategy for a story or release, asks "am I missing any kinds of testing", wonders how to balance unit vs functional vs exploratory, or mentions the testing quadrants. Trigger even when the user only describes a feature and asks "how should I test this" — the quadrants are the right lens for a complete answer. - Skill: `iggmasterdev/testing-quadrants-mapper` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add iggmasterdev/testing-quadrants-mapper` - Raw SKILL.md: https://api.skillmd.com/api/skills/iggmasterdev/testing-quadrants-mapper/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: iggmasterdev (https://skillmd.com/u/iggmasterdev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/iggmasterdev/testing-quadrants-mapper --- # Testing Quadrants Mapper You produce a **complete test-coverage plan** for a feature, story, release, or system by mapping it across the four Agile Testing Quadrants. The value of this tool is not novelty — it's **completeness**. Left to memory, teams reliably cover Quadrant 1 and 2 (the tests that drive development) and forget Quadrant 3 and 4 (the tests that critique the finished product). Your job is to make the whole picture visible and force the forgotten quadrants into the open. ## The model Two axes. One axis: **support the team** (guide development, written before/with code) vs **critique the product** (evaluate the built thing, find where it falls short). Other axis: **business-facing** (in the customer's language) vs **technology-facing** (in technical terms). | | Business-facing | Technology-facing | |---|---|---| | **Support the team** | **Q2** — functional/story/acceptance tests, examples, prototypes, API tests | **Q1** — unit & component tests, TDD | | **Critique the product** | **Q3** — exploratory, usability, UAT, scenario/soap-opera testing | **Q4** — performance, load, security, reliability, the "-ilities" | **Critical caveat to state in every output:** the quadrant *numbers are not an order*. You do not do Q1 then Q2 then Q3 then Q4. Timing depends on risk — e.g., if performance is critical, Q4 load testing happens as soon as testable code exists, often before functional testing is complete. Lead with risk, not numbers. ## When to use Planning what to test for a story or release; building a test strategy; auditing an existing plan for gaps; deciding the automated/manual split; or any "how do I test this thoroughly" question. Works at any altitude — a single story or a whole system. ## Inputs to gather - What's under test (feature/story/release/system) and what it does - Known risks, SLAs, or non-functional requirements (response time, security posture, compliance, expected load) - Tech stack (so the tooling map is real, not generic) - Whether this is greenfield or legacy (changes where the effort goes) If non-functional requirements are unknown, that itself is a Q4 finding — say so. ## The procedure For the thing under test, fill in all four quadrants. For **each** quadrant produce: what to test (specific to this feature, not generic), **owner**, automated vs manual, suggested **modern** tools, and rough timing. ### Quadrant 1 — Technology-facing, support the team Unit and component tests; test-driven development. Verifies internal quality — defined by programmers, not negotiated with the customer. Fast, runs on every check-in. **Owner: developers.** This is where the bulk of automated tests live (base of the test pyramid). Modern tools: JUnit5/TestNG (Java), pytest (Python), Vitest/Jest (JS/TS), xUnit/NUnit (.NET), Go testing, RSpec (Ruby). ### Quadrant 2 — Business-facing, support the team Functional / story / acceptance tests derived from customer examples; they define external quality. Run below the GUI / at the API level where possible for speed. Also includes non-automated support artifacts: mock-ups, wireframes, prototypes. **Owner: tester + developer + customer together.** Modern tools: Cucumber/SpecFlow/pytest-bdd for example-driven acceptance tests; REST-assured/Playwright API/Postman/Schemathesis for API-level functional tests. (For deriving the examples themselves, use the `example-mapping` skill first.) ### Quadrant 3 — Business-facing, critique the product Manual, human-judgment testing of the working software: **exploratory testing** (central to this quadrant), usability testing, user acceptance testing (UAT), scenario / soap-opera testing, persona testing. This is where the most serious bugs are usually found, because here you discover the examples that were *wrong* or missing. Only a human can do this well; automation just sets up the data. **Owner: testers, real users, customers.** Modern aids: Playwright/Selenium for data setup, session-based test management; for charters use the `exploratory-charter` skill. ### Quadrant 4 — Technology-facing, critique the product Performance, load, stress, scalability, security, reliability, installability, interoperability, maintainability, compatibility — the "-ilities." Needs specialized tools and sometimes specialized skills. **Do not leave to the end** — if a non-functional attribute is critical, test it as soon as testable code exists. **Owner: developers + specialists.** Modern tools: k6/Gatling/JMeter/Locust (performance/load), OWASP ZAP/Burp Suite/Semgrep/Dependabot (security), Lighthouse (web perf), chaos tooling (reliability). ## Output format Produce a document titled **`Quadrant Coverage Plan: `** with: 1. **One-line summary** of what's under test and the dominant risks. 2. **The four-quadrant table** — one row per quadrant with columns: *What to test* (specific), *Owner*, *Auto/Manual*, *Tools*, *When/Timing*. 3. **Gaps & risks** — the most important section. Call out explicitly: - Any quadrant the team is likely under-investing in (usually Q3 or Q4). - Any non-functional requirement that's unknown and must be pinned down. - The recommended *sequencing by risk* (not by quadrant number). 4. **Pyramid note** — a one-line check on the automated split: the bulk of automation should sit in Q1 (unit/component), a solid middle of Q2 (API/functional), and a thin tip of GUI tests. If the user's described approach is GUI-heavy ("inverted pyramid"), flag it. No preamble — just the plan. ## Quality bar - Every quadrant has **feature-specific** entries, not boilerplate. "Q4: do performance testing" is useless; "Q4: the search endpoint must return < 300ms at 500 concurrent users — load-test with k6 before functional sign-off" is useful. - The **Gaps & risks** section actually names what's likely missing. If Q3 and Q4 are thin, say it plainly — that's the whole point of the tool. - Tooling matches the user's **actual stack**. - You stated that quadrant numbers are not an execution order. ## Background Grounded in long-established agile testing practice: the four agile testing quadrants (organizing tests by business- vs technology-facing and support- vs critique-the-product) and the test automation pyramid.