test-case-ideation-from-story
Turns a thin or ambiguous story into a reviewable test list - a backlog item that is a short paragraph plus the click-through support recorded for themselves, a spec that is mostly a list of accepted formats, or a tech design pasted into the ticket while the last few releases still shipped missed cases. Takes the story or feature spec and emits a markdown test-case matrix, one row per case (id, title, precondition, steps, expected, tier), covering happy path, alternate paths, boundaries, and negative paths, before any test code is written. Output is the human-reviewable matrix that goes into TestRail / Qase / Xray, not Gherkin scenarios. Use when a story needs its cases enumerated and agreed before automation starts.
Install with skills.sh (any agent)
npx skills add testland/qa --skill test-case-ideation-from-storytest-case-ideation-from-story
Overview
A user story is not a test plan. The "three amigos" hand-off from product to QA needs an intermediate artifact: a human-reviewable test-case matrix that enumerates the cases the story implies, before anyone writes Gherkin or test code. This skill produces that matrix.
The matrix is what manual testers paste into TestRail / Qase / Xray. It is also the contract that the downstream automation engineer reads when picking up the story - gherkin-from-stories (in qa-bdd) needs a stable AC layer, and the AC layer is derived from this matrix, not the other way around.
The PractiTest 2026 State of Testing Report finds 70% of teams already use AI for test-case creation but only 40.7% report achieving "more diverse and complex test cases" (https://www.practitest.com/state-of-testing/) - the dominant failure mode is shallow output (one happy path × three trivial restatements). This skill exists to constrain the output shape so that the matrix is forced through equivalence-partitioning, boundary, and negative-path lenses.
When to use
Do not use this skill when:
Step 1 - Extract the story's testable claims
Read the user story (and any attached AC, mockups, or rejection notes) and extract:
If any of (1) - (5) is missing from the story, stop and request clarification. A matrix derived from incomplete input will mask the gap rather than surface it. ISTQB's test analysis (opens in new window) step is explicit that test conditions must trace to identified test bases; an unclear story is not a test basis.
Step 2 - Enumerate cases per ISTQB test design technique
For each (action, object) pair, generate cases by walking three lenses (equivalence partitioning (opens in new window), boundary value analysis (opens in new window), decision table testing (opens in new window)):
Lens 1 - Equivalence classes (one row per class)
For each input parameter, identify the valid and invalid equivalence classes. One representative case per class.
| If parameter is… | Valid classes | Invalid classes |
|---|---|---|
| String with format constraint (email, URL, phone) | Conformant | Empty / wrong format / null / oversized |
| Numeric with range | Min ≤ x ≤ max | x < min, x > max, NaN, negative, zero (if not in range) |
| Enum | Each documented value | Undocumented value, mixed case |
| Reference (foreign key, file path) | Existing | Missing, deleted, belongs-to-other-tenant |
Lens 2 - Boundaries (one row per boundary)
For numeric / length-bounded parameters, add cases at min, min-1, max, max+1. Skip if the parameter is unbounded (free-text comment, etc.).
Lens 3 - Decision conditions (one row per branch)
If the story implies decision logic (role-based access, plan tier, feature flag, A/B variant), add one case per condition combination. Use a decision table to be exhaustive; collapse rows that have the same outcome.
Step 3 - Emit the matrix
Output is a markdown table. Required columns:
| Field | Notes |
|---|---|
| ID | <story-key>-TC-<n>, e.g. CART-142-TC-03. Stable across iterations. |
| Title | Imperative single sentence: "Adds a product to the cart as an anonymous user". No "should". |
| Tier | smoke / regression / edge / negative. Tier rationale belongs in the next column. |
| Precondition | One sentence; references fixtures by name where possible. |
| Steps | Numbered. Declarative (per Cucumber better-gherkin guidance (opens in new window)) - describe behavior, not UI mechanics. |
| Expected | One sentence per observable post-condition. |
| Source claim | Which sentence in the story / AC this case traces to. Forces traceability. |
Worked example
Story: "As an anonymous shopper, I want to add a product to my cart, so that I can check out without signing in first."
| ID | Title | Tier | Precondition | Steps | Expected | Source claim |
|---|---|---|---|---|---|---|
| CART-142-TC-01 | Adds an in-stock product to an empty cart | smoke | Anonymous session; product SKU-001 in stock | 1. Open product page for SKU-001. 2. Add to cart with default qty. | Cart count = 1; product line shows SKU-001. | Story sentence 1 |
| CART-142-TC-02 | Adds a second product to a cart that already has one | regression | Anonymous session; cart already contains SKU-001 | 1. Open product page for SKU-002. 2. Add to cart. | Cart count = 2; both SKUs present. | Implied by "add" semantics |
| CART-142-TC-03 | Rejects adding an out-of-stock product | negative | Anonymous session; SKU-099 is out of stock | 1. Open product page for SKU-099. 2. Attempt to add to cart. | Add-to-cart control disabled or 409 returned. Cart count unchanged. | Story constraint (implicit) |
| CART-142-TC-04 | Rejects adding when cart is at the per-session limit | boundary | Anonymous session; cart has the maximum number of items per the documented MAX_CART_ITEMS | 1. Open any product page. 2. Attempt to add to cart. | 409 / cart-full message. Cart count unchanged. | Constraint: MAX_CART_ITEMS |
| CART-142-TC-05 | Persists cart across page refresh | regression | Anonymous session; cart has 1 item | 1. Refresh the page. | Cart still shows the same item. | Implied by "without signing in" |
The matrix is the authoring artifact. The next steps in the workflow are:
Step 4 - CI / tracker integration
The matrix is plain markdown. Common integrations:
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| One row per UI step ("user clicks button", "user types email") | Matrix becomes a script, not a case list. ISTQB calls these procedures, not cases. | One row per case; UI mechanics live in manual-test-script-author (in qa-manual-testing). |
| Five rows that all assert the same happy-path outcome with cosmetic variation | Same equivalence class repeated; doesn't add coverage. | One row per equivalence class (Step 2 Lens 1). |
| No negative cases at all | This is the PractiTest 2026 "test factory" (opens in new window) failure mode. | Mandate at least one negative-tier row per story unless the story has no error contract. |
| Source-claim column blank or "Story" | Blocks traceability; if the story changes, you can't tell which rows need re-review. | Cite the specific sentence / AC bullet. |
Cases that depend on implementation choices ("user clicks the React <AddToCartButton> component") | Implementation-coupled cases churn with refactors. | Declarative phrasing per Cucumber better-gherkin (opens in new window). |
| Matrix produced from a story missing actor / postconditions | The matrix masks the gap; downstream sees noise. | Step 1 explicitly halts on missing fields. |
Limitations
Hand-off targets
References
Related skills
attack-surface-test-checklist
Maps a code change to the security tests worth running against it. Classifies changed paths and file contents into nine attack surfaces (authentication, session management, input handling, file upload, deserialization, access control, API and web service, cryptography, data protection), attaches the matching OWASP ASVS 4.0.3 verification requirements, OWASP Top 10 2021 category IDs, and OWASP WSTG section numbers to each active surface, then emits a per-surface manual and automated test checklist bounded by what actually changed. Surfaces with no changed lines are excluded rather than carried as filler. Use when a pull request, release branch, or feature is about to be security tested and the team needs a targeted test list instead of a generic application-wide checklist.
definition-of-done
The team's Definition of Done (DoD), both halves of the lifecycle: authoring and auditing. Explains the Scrum Guide's DoD definition ("a formal description of the state of the Increment when it meets the quality measures required for the product"), proposes a starter DoD with the 7-10 lines most teams need (code reviewed, unit tests, docs, AC met, deployed to staging, smoke passed, no a11y regressions, telemetry wired), emits a per-PR checklist a reviewer enforces, and audits work against an existing DoD line by line with repository evidence (review records, diffs, CI runs, coverage reports), tagging every line met, not met, or unverifiable - never passing a line on self-attestation. Use when the team doesn't have a DoD, wants to revise theirs, or is about to mark a story or PR done and nobody has checked the work against the committed checklist.
e2e-suite-budget
Caps E2E suite size by computing per-test ROI - (regressions caught × value) ÷ (runtime × flake rate × maintenance) - then ranks every end-to-end test and recommends which bottom-decile ones to retire, move to a lower layer, or fix. Use when CI is slow or E2E-dominated, flaky failures are rising, or quarterly to keep suite size within maintenance capacity. For strategic unit:service:UI layer ratios use test-pyramid-balancer, for the minimal per-deploy critical-path gate use smoke-suite-gate, and for quarantining flaky tests use flaky-test-quarantine; this prunes low-signal tests by ROI.
framework-choice-advisor
Reference catalog for picking a test automation framework or QA tool - covers Playwright / Cypress / Selenium / WebdriverIO / Appium / Espresso / XCUITest / RestAssured / Karate / k6 / Locust with side-by-side tradeoffs on speed, cross-browser, mobile, parallelisation, language support, ecosystem maturity, CI integration; a decision tree matching project NFRs to framework choice; and reference layouts for the chosen stack. references/ extends the same decision to commercial procurement (seven-axis vendor evaluation for TCM platforms, no-code tools, visual-regression services) and to recording the outcome (ADR-based tool-selection decision record with signal, one recommendation, flip conditions). This is the upstream selection step: it decides which tool to adopt, not how to configure one already chosen. Use when starting a new test-automation suite, evaluating commercial QA vendors, or writing down a tool decision.
post-mortem-author
Build-an-X workflow that produces a blameless post-mortem from an incident - captures the timeline (chronological event sequence with sources), root cause analysis (what + why, not who), impact (users / revenue / SLO debt), action items (with owners + due dates + measurable success criteria), and "what went well" (intentional). Per Google SRE: "Blameless postmortems are a tenet of SRE culture." Use after every user-visible incident, not just severe ones.
risk-matrix
The risk-based testing (RBT) umbrella: risk matrix and risk register authoring, likelihood x impact scoring, risk storming, calibration, and risk-to-test coverage mapping. Produces the per-feature / per-release matrix artifact (structured intake: feature, category, impact 1-5 by likelihood 1-5, score; heatmap; mitigations with owners and due dates), supporting lightweight and heavyweight (FMEA / Cost of Exposure) methods per RBT canon, plus a risk coverage mapping workflow that proves which tests, cases, or monitors back each registered risk. references/ carries the product-risk and project-risk register variants, the risk-storming facilitation guide, matrix calibration against observed defect data, and a register review checklist. Use for any risk-based-testing artifact: building a matrix or register, running a risk-storming session, calibrating ratings against defects, or mapping risks onto test coverage.
smoke-suite-gate
Build-an-X workflow for a critical-path smoke suite that runs in <5 minutes - picks the 5-15 highest-business-value journeys (login, hero flow, checkout, payment, primary read), implements as fast E2E or API tests, gates per-deploy, retries on transient failures with quarantine. Use as the canary-precursor or per-deploy verification gate; the team's "if this fails, the build can't proceed" floor.
test-case-from-live-feature
Build-an-X workflow that produces a test-case matrix from a **live, undocumented feature** - running app at a URL, screen recording, screenshot, or verbal brief - by combining structured exploration (Playwright trace / DevTools / accessibility tree) with the four canonical heuristic test-design models bundled in references/ (Bach's HTSM / SFDPOT product elements, Whittaker's How-to-Break-Software attacks, Bolton's FEW HICCUPPS consistency oracles, ISO/IEC 25010 quality characteristics). Output is a structured case matrix, not an exploratory session charter. Use when there is no story, no AC, and no documentation - only a live feature - or as the heuristic reference layer for zero-documentation test design.
test-effort-estimation
Turns a list of testable areas plus a change-shape distribution into a PERT three-point test effort estimate, reporting every row as a range around the expected value rather than a single number, requiring a named assumptions ledger across six mandatory categories, and recommending a per-layer ownership split across developer, automation, and exploratory roles. Bundles the change-shape classifier (pure-logic / service-layer / ui-heavy / data-heavy from git-history path and content signals, with the relative per-layer cost model) as a reference, so the shape distribution the estimate consumes can be produced here too. Does not choose which tests to run or how deep coverage should go. Use when an epic or release has been broken into testable areas and someone is about to commit test capacity for a sprint, or when a change set needs its shape classified before planning.
test-pyramid-balancer
Build-an-X workflow that analyzes a repo's test mix (unit / integration / E2E counts + runtimes) and recommends rebalancing toward the test pyramid ratios per the change-set shape - pure-logic-heavy repo wants ~80/15/5; UI-heavy repo wants ~60/25/15. Detects 'ice-cream cone' (E2E-heavy) and 'hourglass' (integration-thin) anti-patterns. Use when the user asks about test distribution, test strategy, test balance, too many E2E tests, slow CI caused by tests, testing best practices, or rebalancing their test suite; also suitable for quarterly calibration of the test mix to codebase reality.
test-strategy-author
Authors a test strategy document (a master test plan) for a project, release, or feature - covers scope, in/out, test types per layer (unit / integration / contract / E2E / perf / security / a11y), risk-based test prioritization that maps top risks to test investment (per `risk-matrix`), tooling stack, environments, exit criteria, and ownership. Includes a risk-based test-planning workflow that turns a feature scope plus the risk matrix into a budgeted per-risk test plan with owners, effort estimates, and an explicit risks-not-addressed section. Use when a team needs the release-readiness artifact stakeholders sign off on before significant test investment, or a risk-prioritized test plan for a feature or quarter.