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.
Install with skills.sh (any agent)
npx skills add testland/qa --skill test-case-from-live-featuretest-case-from-live-feature
Overview
A tester is told "test the new checkout flow" with no story, no AC, no design doc, but the feature is deployed to staging. The right path is to reverse-engineer a test-case matrix from the live feature, anchored on the four heuristic models in references/heuristics.md, and emit a structured matrix that downstream skills (manual-test-script-author, gherkin-from-stories, ai-test-generator) can consume.
The output is the same shape as test-case-ideation-from-story - one row per case with id / title / tier / precondition / steps / expected / source claim - but the source claim column points at observed behaviour rather than a story sentence, and each row is tagged with the heuristic that surfaced it so the team can audit the coverage logic.
When to use
Do not use this skill when:
Step 1 - Probe the live feature
Capture concrete observations from the running surface. Sources, in order of preference:
| Source | What to capture | Tool |
|---|---|---|
| Live URL / app | All visible actions, fields, validation messages, error states; the URL pattern; the network requests; the rendered DOM | Browser DevTools, Playwright trace, axe-core accessibility tree |
| Screen recording / Loom | The flow the engineer / PM walked through; the implicit assumptions about state | Annotate the recording with timestamps |
| Screenshot set | Static state; what fields exist; what labels say | Inspect element labels and ARIA |
| Verbal brief from an engineer | "It does X and Y" - capture as a quote, do not transcribe as fact | Mark as [verbal, unconfirmed] |
| Existing code (the spec-in-code case) | Public API surface, route definitions, validation rules, DB schema | git log to see recent change scope |
Output of Step 1 is an observation log:
## Observation log - checkout flow @ staging.example.com (2026-05-11 14:00 UTC)
### URLs probed
- `/cart` - cart view; lists line items.
- `/cart/checkout` - multi-step flow: address → shipping → payment → review → confirm.
- `/cart/confirm/:order_id` - confirmation page.
### Network calls observed
- `POST /api/cart/items` (add to cart) → 201, body `{ sku, qty, addedAt }`.
- `POST /api/coupons/apply` → 200 on valid, 409 on already-applied, 422 on expired.
- `POST /api/checkout/payment` → 201 on success, 402 on declined, 5xx on provider-down.
### UI affordances observed
- Coupon field accepts up to 32 chars; case-insensitive in client validation (DOM `text-transform: uppercase`).
- "Place order" button disabled on submit (good - prevents double-click).
- No client-side qty boundary; server returns 422 above qty=99.
### Accessibility tree (axe-core)
- 3 violations on /cart/checkout: missing label on shipping-method radios; insufficient contrast on disabled button; missing live-region on validation errors.
### Verbal brief (engineer Slack message, 2026-05-10)
- "It uses Stripe for cards and PayPal for wallets, and we have a feature flag `new_checkout_v2` defaulting on." [verbal, unconfirmed]Inputs that cannot be confirmed by direct observation are tagged [verbal, unconfirmed] or [claim, unverified] and tracked through the matrix as source claim: observation + [unverified]. This is the audit trail that lets the team disambiguate "tester observed" from "tester was told."
Step 2 - Walk the heuristic models
Apply each model in references/heuristics.md to the observation log, in order:
The full walk applied to the checkout observation log - the SFDPOT table, the per-function Whittaker attacks, the FEW HICCUPPS pre-flight, and the ISO 25010 cross-check - is in references/heuristic-walk-example.md.
Step 3 - Emit the matrix
Same shape as test-case-ideation-from-story output, with two added columns:
| Column | Notes |
|---|---|
| ID | <feature>-LIVE-<n>, e.g. CHECKOUT-LIVE-03. The LIVE infix marks it as heuristically-derived. |
| Title | Imperative single sentence. |
| Tier | smoke / regression / edge / negative / a11y / perf / sec. |
| Precondition | Observed (or [unverified - confirm with PM]). |
| Steps | Numbered, declarative (per Cucumber better-Gherkin (opens in new window)). |
| Expected | Observed behaviour or the FEW HICCUPPS-derived expectation. |
| Source claim | Observation log line + heuristic that surfaced the case (e.g., obs:cart.qty boundary @ DevTools; Whittaker input-attack). |
| Heuristic (new) | Which model surfaced this: SFDPOT-F, Whittaker-input, FEW-HICCUPPS-comparable-products, ISO25010-security, etc. |
| Confidence (new) | observed (saw it directly), inferred (heuristic surfaced it but not yet probed), verbal-unverified (came from a non-canonical source). |
Worked example row
| ID | Title | Tier | Pre | Steps | Expected | Source claim | Heuristic | Confidence |
|---|---|---|---|---|---|---|---|---|
| CHECKOUT-LIVE-07 | Rejects coupon when length exceeds 32 chars | negative | Authenticated session | 1. Open /cart/checkout. 2. Enter coupon of 33 chars. 3. Submit. | Either client validation blocks at 32; or server returns 422. Both behaviours are defensible - observe which the team chose and document. | obs:coupon-input maxlength=32 in DOM; Whittaker input-attack | Whittaker-input | inferred |
| CHECKOUT-LIVE-08 | Idempotent re-POST on /api/checkout/payment | regression | Authenticated session; payment about to submit | 1. Submit payment. 2. Network-throttle the response. 3. Re-submit with the same idempotency key. | Returns the original order id, does not charge twice. | obs:idempotency-key header observed; FEW HICCUPPS-purpose | FEW-HICCUPPS-purpose | inferred |
| CHECKOUT-LIVE-09 | Shipping-method radios have accessible labels | a11y | Authenticated session, address completed | 1. Inspect shipping-method radios. 2. Verify each has an associated <label> or aria-label. | Each radio has an accessible name; screen reader announces it. | obs:axe-core violation @ /cart/checkout; ISO25010-usability; WCAG 2.2 AA | ISO25010-usability | observed |
Confidence-tagged rows give the team an explicit gradient: observed cases can be run immediately; inferred cases are the heuristic's prediction the team should confirm-or-falsify on first run; verbal-unverified cases need product-side validation before they go into the regression suite.
Step 4 - Reconcile with downstream skills
The matrix is the input to the same downstream chain as test-case-ideation-from-story:
The matrix should also be filed with the team's PM / engineer as a documentation byproduct - the heuristic walk often surfaces things the team didn't realise were unspecified, and the matrix becomes the de facto spec for the feature going forward.
Step 5 - Tracker / test-management integration
Per the same conventions as test-case-ideation-from-story: import as CSV into TestRail / Qase / Xray; preserve the Heuristic and Confidence columns as tags so the team can filter "all SFDPOT-F-derived smoke cases" or "all inferred cases awaiting first-run confirmation."
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Skipping the observation log; jumping straight to heuristic walk | Without the observation log, the matrix's "source claim" column is empty - the team cannot audit which case came from where. | Step 1 produces the observation log first; it is the load-bearing artifact. |
Treating inferred rows as authoritative | Heuristics generate hypotheses, not facts; an inferred row that doesn't reproduce is the heuristic doing its job. | The Confidence column gates downstream automation - inferred cases are probed on first run, not blindly automated. |
| Filing FEW HICCUPPS-derived bugs without naming the lens | The bug report reads "this feels wrong" - undefensible. | Always cite the lens (e.g., FEW-HICCUPPS: Comparable-products + User-expectations). |
| Transcribing the engineer's verbal brief as fact | The brief is the engineer's mental model; mental models leak. | Tag verbal input [verbal, unconfirmed] and probe it against the live surface in Step 1. |
| Running this skill on a feature that already has a story | The story-driven path (test-case-ideation-from-story) is faster and more traceable when a story exists. | Use this skill only when no story / AC / spec exists; combine with the story-driven matrix for thin specs. |
| Probing production directly (instead of staging / canary) | Side effects on real users, real data, real money. | Step 1's "live URL" means staging / canary by default; production probes require a separate authorisation. |
Limitations
Hand-off targets
References
Heuristic walk - worked example
View source (opens in new window)Heuristic walk - worked example
Deep reference for the test-case-from-live-feature SKILL.md, Step 2. The four heuristic models from heuristics.md (opens in new window) applied to the checkout observation log from Step 1, turning observations into candidate test-case rows. The spine keeps the four-substep method; this file shows the walk in full.
2a - SFDPOT coverage walk
Per HTSM (James Bach (opens in new window)), enumerate cases per Product Element:
| Guideword | From the observation log |
|---|---|
| S - Structure | cart service, payment service, coupon service, idempotency layer (observed via network calls). |
| F - Function | add to cart, edit qty, apply coupon, choose shipping, choose payment, place order, see confirmation. |
| D - Data | SKU, qty, price, coupon code, address, payment method, order id, idempotency key. |
| P - Platform | desktop Chrome / Safari / Firefox; mobile iOS / Android web; observed responsive layout via DevTools. |
| O - Operations | feature flag new_checkout_v2 (verbal, unverified); rollback path unknown. |
| T - Time | cart expiry (unknown - to probe), coupon expiry (422 on expired observed), payment timeout (unknown). |
Each non-empty cell becomes one or more test-case rows.
2b - Whittaker attack overlay
For each function, enumerate the attacks from the Whittaker catalog (opens in new window) (in heuristics.md (opens in new window)):
2c - FEW HICCUPPS oracle pre-flight
For each observation that already looked wrong, pre-classify with Bolton's FEW HICCUPPS (opens in new window) so the test row carries a defensible verdict frame:
2d - ISO 25010 quality cross-check
Walk the eight (+2) ISO/IEC 25010 (opens in new window) characteristics; add rows for the quality dimensions SFDPOT didn't surface:
Heuristic test-design models
View source (opens in new window)Heuristic test-design models
Deep reference for the test-case-from-live-feature SKILL.md. The catalog of the four canonical heuristic test-design models the Step 2 walk consumes - Bach's Heuristic Test Strategy Model (HTSM) with SFDPOT product elements, Whittaker's 'How to Break Software' attack patterns, Bolton's FEW HICCUPPS consistency oracles, and the ISO/IEC 25010 quality characteristics - for the zero-documentation case: no user story, no acceptance criteria, no documentation.
The exploratory-testing literature converged on these four models, each cited inline at point of use below. This is a pure reference - no execution steps; the SKILL.md spine turns the walk into a case matrix.
How to use the catalog
Run the four models in sequence; each one narrows the next. No written story or acceptance criteria are required - that is the whole point.
Model 1 - HTSM / SFDPOT product elements (Bach)
James Bach's Heuristic Test Strategy Model (opens in new window) (HTSM v6.3) is the canonical "guideword heuristics" framework. The mnemonic SFDPOT covers the Product Elements dimension - the parts of the system that need coverage. The four HTSM focus areas are: Test Techniques, Project Elements, Product Factors, and Quality Criteria categories.
| Guideword | What to probe |
|---|---|
| S - Structure | Code, files, modules, services, infrastructure layers, dependencies. What does the product consist of? |
| F - Function | Each feature / capability the product offers. What does it do? (UI, API, scheduled jobs, side-effects.) |
| D - Data | Inputs, outputs, persistent stores, types, sizes, encodings, lifecycles, ownership. What does it operate on? |
| P - Platform | OS, browsers, devices, runtimes, third-party libs, network conditions. What does it run on? |
| O - Operations | How it's deployed, configured, monitored, upgraded, backed up, recovered. How is it used / operated? |
| T - Time | Speed, sequencing, concurrency, time-of-day effects, scheduling, race conditions, expirations. How does it behave over time? |
Each guideword expands the search space. SFDPOT applied to "checkout flow" generates: Structure (cart service, payment service, inventory service), Function (add to cart, apply coupon, choose shipping, pay, confirm), Data (cart items, coupon codes, addresses, payment tokens, order IDs), Platform (desktop / mobile, iOS / Android, Stripe / Adyen integrations), Operations (deploy, rollback, monitoring, alerting), Time (cart expiry, coupon expiry, payment timeout, idempotency keys).
Coverage check: a feature passed through SFDPOT that has zero notes under one guideword is a flag - either the guideword is genuinely n/a (rare) or the team has a coverage gap.
Model 2 - Whittaker "How to Break Software" attack patterns
James Whittaker's How to Break Software (opens in new window) (cited in the exploratory-testing literature as the canonical attack-pattern catalog) organises adversarial test ideas as attacks - explicit ways the software can fail. The canonical attack categories:
| Attack | What you do | Typical bug surface |
|---|---|---|
| Input attack | Feed inputs outside the documented domain - too long, wrong encoding, malformed format, empty, null, special chars, SQL-keyword strings | Validation gaps, injection, crashes |
| Output attack | Force outputs the system shouldn't produce - overflow buffers, wrong encoding, locale boundary | Display bugs, serialisation gaps |
| Stored-data attack | Manipulate the persistent store directly (DB row, file, cache) and then exercise the feature | State-handling bugs, cache inconsistency |
| Computation attack | Force the system to compute on the boundary (overflow, underflow, divide by zero, max-int, NaN) | Arithmetic / type / overflow bugs |
| User-interface attack | Click out-of-order, double-click, navigate away mid-action, browser-back, refresh during submit | State-machine bugs, race conditions |
| Configuration attack | Run with non-default config, missing env vars, mis-set flags, third-party API key revoked | Configuration brittleness, fail-open bugs |
Apply Whittaker after SFDPOT: SFDPOT enumerates what to cover; Whittaker enumerates how each thing can break.
Model 3 - FEW HICCUPPS consistency oracles (Bolton)
Michael Bolton's FEW HICCUPPS (opens in new window) is the canonical oracle heuristic - how do you decide a behavior is wrong when no spec says so? Each letter is a consistency lens:
| Letter | Consistency with… | What you compare |
|---|---|---|
| F | Familiarity | …problems we've seen before in this product or others - does this behave like a known bug? |
| E | Explainability | …a reasonable explanation a user could accept - does the behaviour make sense to articulate? |
| W | World | …how the world works (physics, math, calendars, currencies) - does it match reality? |
| H | History | …the product's prior behaviour - did this used to work differently? |
| I | Image | …the company / product's image - would a customer find this off-brand? |
| C | Comparable products | …how competitors / siblings handle it - is the deviation deliberate? |
| C | Claims | …what the docs / marketing / sales material promised |
| U | User expectations | …what users would reasonably expect from naming, layout, prior workflows |
| P | Product (itself) | …other parts of the same product - is the behaviour consistent across pages / endpoints / flows? |
| P | Purpose | …the feature's stated purpose / intent |
| S | Statutes / standards | …laws (GDPR, HIPAA, PCI-DSS, ADA), standards (W3C, RFCs, ISO), regulations |
A finding that violates at least one consistency lens is a defensible bug report even without a spec. The lens is the oracle.
Model 4 - ISO/IEC 25010 quality characteristics
The canonical quality-attribute taxonomy from ISO/IEC 25010 (opens in new window) (the system / software product quality model, successor to ISO 9126). The eight characteristics define what kinds of quality a feature can have - beyond "does it work":
| Characteristic | What to probe |
|---|---|
| Functional suitability | Does it do what it's supposed to? Completeness, correctness, appropriateness. |
| Performance efficiency | Time behaviour, resource utilization, capacity. |
| Compatibility | Co-existence, interoperability with other products / services. |
| Usability | Appropriateness recognisability, learnability, operability, error protection, UI aesthetics, accessibility. |
| Reliability | Maturity, availability, fault tolerance, recoverability. |
| Security | Confidentiality, integrity, non-repudiation, accountability, authenticity. |
| Maintainability | Modularity, reusability, analysability, modifiability, testability. |
| Portability | Adaptability, installability, replaceability. |
The 2023 revision adds Safety and Interaction Capability as additional top-level characteristics (cite by stable ID - ISO/IEC 25010:2023; the canonical ISO page sits behind a Cloudflare challenge). Apply 25010 alongside SFDPOT: SFDPOT enumerates what to cover; 25010 enumerates which kinds of quality to test for. A feature can be functionally correct but fail on performance, security, or usability - and 25010 is the prompt that reminds the tester to check.
How to combine the models
The four models are orthogonal:
| Model | Answers the question… |
|---|---|
| HTSM / SFDPOT | What parts of the system do I need to look at? |
| Whittaker attacks | How can each part fail? |
| FEW HICCUPPS | When I see weird behaviour, is it a bug? |
| ISO 25010 | What kinds of quality am I testing for? |
Apply them in the "How to use" order above: SFDPOT enumerates targets, Whittaker attacks each one, FEW HICCUPPS classifies the surprises, and 25010 confirms no quality dimension was skipped.
Worked example - "test the new checkout flow, no spec"
The four models applied end to end to a zero-documentation brief. Input: "We're shipping a new checkout next week. Test it." That's it.
SFDPOT walk:
Whittaker attacks applied to each function:
Quality cross-check (ISO 25010):
Oracle (FEW HICCUPPS) for ambiguous findings:
The output is the input to the SKILL.md spine, which turns the SFDPOT + Whittaker walk into a structured test-case matrix.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Using SFDPOT as a checklist to tick rather than a prompt to think | Box-ticking; the model produces lazy coverage. | Each guideword should generate observations and follow-up questions, not a done mark. |
| Citing FEW HICCUPPS without naming which lens fired | The bug report reads "this feels wrong" - undefensible. | Always name the lens: "violates Comparable-products consistency: every other site disables this button while the request is in flight." |
| Treating Whittaker attacks as exhaustive | The attack list is illustrative, not complete; new attack classes emerge with new tech (LLM prompt injection, supply-chain). | Apply the categories as prompts, then keep going. |
| Using ISO 25010 as the only model | Quality-attribute thinking without product-element thinking misses where the bugs live. | Always pair 25010 with SFDPOT. |
| Heuristic test design without a spec when the team has a spec | The spec is the better input; heuristics are the fallback. | Use test-case-ideation-from-story first; reach for this catalog when no spec exists. |
| Halting because "we have no docs" | The whole point of these models is that you don't need docs to start. | Apply the models; flag the documentation gap separately as a process issue. |
Limitations
References
Each model's primary source is cited inline at its section: HTSM / SFDPOT (satisfice.com), FEW HICCUPPS (developsense.com), ISO/IEC 25010 (Wikipedia), and Whittaker's attack patterns (via the exploratory-testing article). Additional references, not repeated inline:
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-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.
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.