Stats
Actions
Tags
From qa-process
Reference catalog of the four canonical heuristic test-design models - 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 use when the tester has no user story, no acceptance criteria, and no documentation. Distinct from `test-case-ideation-from-story` (which works from a written story) and from `exploratory-charter-author` (which produces session charters, not case sets). Use as the reference layer that `test-case-from-live-feature` and `exploratory-charter-author` cite when generating coverage from zero documented input.
How this skill is triggered — by the user, by Claude, or both
Slash command
/qa-process:heuristic-test-design-coachThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The exploratory-testing literature converged on four canonical heuristic test-design models, each cited inline at point of use below. This skill is a **pure reference** - no execution steps; it is the catalog `test-case-from-live-feature` and `exploratory-charter-author` consume to generate coverage when no documented input exists.
The exploratory-testing literature converged on four canonical heuristic test-design models, each cited inline at point of use below. This skill is a pure reference - no execution steps; it is the catalog test-case-from-live-feature and exploratory-charter-author consume to generate coverage when no documented input exists.
exploratory-charter-author) needs a structured prompt set instead of pure intuition.Do not use this skill alone to produce a deliverable. It is the input to a downstream authoring skill (test-case-from-live-feature, exploratory-charter-author, manual-test-script-author). The catalog tells you what to look at; the downstream skill turns observations into a matrix or charter.
James Bach's Heuristic Test Strategy Model (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.
James Whittaker's How to Break Software (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.
Michael Bolton's FEW HICCUPPS 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.
The canonical quality-attribute taxonomy from ISO/IEC 25010 (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.
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? |
Workflow: walk SFDPOT to enumerate coverage targets → apply Whittaker attacks to each target → as you find unexpected behaviour, classify with FEW HICCUPPS to write a defensible report → cross-reference 25010 to confirm you didn't miss a quality dimension.
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:
SUMMER2026 works but summer2026 doesn't. User expectations: case-insensitive coupons are the norm. Probably bug - file with the FEW HICCUPPS evidence and let product decide.The output is the input to test-case-from-live-feature which turns the SFDPOT + Whittaker walk into a structured test-case matrix.
| 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 skill 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. |
risk-matrix and risk-matrix-recommender) is the depth selector.test-case-from-live-feature, exploratory-charter-author, manual-test-script-author) turn prompts into deliverables.test-case-from-live-feature.exploratory-charter-author.manual-test-script-author.test-case-ideation-from-story.risk-matrix, risk-matrix-recommender.negative-test-generator, malicious-payload-bank, boundary-value-generator.test-case-from-live-feature, exploratory-charter-author - downstream skills that consume this catalog.npx claudepluginhub testland/qa --plugin qa-processProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.