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
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:
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: