crusspic-stmpl-heuristic
Pure-reference catalog of James Bach's CRUSSPIC STMPL heuristic - thirteen quality criteria (quality attributes / non-functional requirements) a tester can evaluate a system against. CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility. STMPL: Supportability, Testability, Maintainability, Portability, Localizability. Use when checking a product's quality attributes or non-functional requirements, or picking which quality characteristics a test session evaluates - a checklist for judging product quality holistically; complementary to the ISO/IEC 25010 software product-quality model.
Install with skills.sh (any agent)
npx skills add testland/qa --skill crusspic-stmpl-heuristiccrusspic-stmpl-heuristic
Overview
CRUSSPIC STMPL is James Bach's quality-criteria mnemonic. The thirteen criteria are enumerated under "Quality Criteria Categories" in Bach's Heuristic Test Strategy Model (HTSM v6.3, 2024-11-05), which defines a quality criterion as "some requirement that defines what the product should be" (HTSM (opens in new window)). The HTSM prints the criteria as named categories; the CRUSSPIC STMPL letters are the memory aid taught over them, not an acronym the HTSM itself spells out.
It overlaps with ISO/IEC 25010:2023 (the formal software- quality model) but offers a more practitioner-friendly mnemonic form that fits in an exploratory tester's working memory.
This skill is a pure reference used when shaping a session's evaluation lens, and by product-risk-register-builder when categorising risks (see its "Quality characteristic" step).
When to use
The thirteen criteria
CRUSSPIC - primary criteria
C - Capability
Does the system do what's claimed?
Functional correctness - the product performs its stated functions. Maps to ISO/IEC 25010 "Functional suitability."
Test heuristics: HICCUPPS-F's Claims oracle + Coverage from FCC CUTS VIDS.
R - Reliability
Does the system work consistently over time?
Maps to ISO 25010 "Reliability."
U - Usability
Can the user figure out how to use it?
Per Nielsen's usability heuristics.
S - Security
Is the system safe from misuse?
Maps to ISO 25010 "Security." Composes with qa-sast, qa-dast, qa-secrets, qa-test-data-privacy.
S - Scalability
Does the system grow with load?
Composes with qa-load-testing.
P - Performance
Is the system fast enough?
Distinct from Scalability - performance is "fast for the user"; scalability is "still fast when load grows." Composes with qa-load-testing.
I - Installability
Can the user install + configure the system?
Maps to ISO 25010 "Portability - Installability."
C - Compatibility
Does the system work alongside other things?
Maps to ISO 25010 "Compatibility." Composes with qa-compatibility.
STMPL - secondary (operational) criteria
S - Supportability
Can the support team diagnose + fix issues?
T - Testability
Can the testers verify the system?
M - Maintainability
Can the team change the system?
Maps to ISO 25010 "Maintainability."
P - Portability
Can the system move between environments?
Maps to ISO 25010 "Portability."
L - Localizability
Can the system be adapted to other languages + cultures?
Composes with qa-localization.
Mapping to ISO/IEC 25010
ISO 25010 has 8 top-level characteristics:
| ISO 25010 | CRUSSPIC STMPL |
|---|---|
| Functional suitability | C (Capability) |
| Reliability | R (Reliability) |
| Usability | U (Usability) |
| Security | S1 (Security) |
| Performance efficiency | P1 (Performance), S2 (Scalability) |
| Compatibility | C2 (Compatibility) |
| Maintainability | M (Maintainability), T (Testability), S3 (Supportability) |
| Portability | I (Installability), P2 (Portability), L (Localizability) |
CRUSSPIC STMPL is more granular; ISO 25010 is more formal. The two are complementary, not substitutable. Per ISO/IEC 25010:2023 (cite by stable ID).
Worked example - applying CRUSSPIC STMPL to a release review
Pre-release review:
## Release v3.0 quality-criteria walkthrough
- **C - Capability:** Functional acceptance tests 98% pass. ✓
- **R - Reliability:** Last 30 days uptime 99.94% (SLA: 99.9%). ✓
- **U - Usability:** User research session N=8; 7/8 completed
signup without help (target: 6/8). ✓
- **S - Security:** Last pen-test 2026-03; all critical findings
fixed; SAST + DAST clean. ✓
- **S - Scalability:** k6 load test at 10x expected peak passed
with p99 < 800ms. ✓
- **P - Performance:** p95 latency 220ms (target 300ms). ✓
- **I - Installability:** New install flow 5 steps; user testing
4/5 completed. ✓
- **C - Compatibility:** Browser matrix Chrome / Firefox / Safari
all current + N-1 tested. ✓
- **S - Supportability:** All log lines structured; trace IDs
end-to-end. ✓
- **T - Testability:** E2E suite runs in 18 min; deterministic
mode available. ✓
- **M - Maintainability:** Sonar tech-debt rating A. ✓
- **P - Portability:** Cloud-portable (Terraform); no AWS-specific
primitives. ✓
- **L - Localizability:** All UI strings extracted to ICU
messages; 7 locales supported. ✓
Verdict: cleared for release.Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Treating CRUSSPIC STMPL as flat | Some criteria matter much more for some products (Security for fintech, Localizability for global B2C) | Weight per product context |
| Confusing Performance with Scalability | "Fast" doesn't mean "stays fast under load" | Test both independently |
| Treating Maintainability + Testability as "developer concerns" | They're quality criteria the tester evaluates | Include in release walkthrough |
| Skipping Supportability | Released system unmaintainable in production | Always walk S |
| One person evaluates all 13 | Inter-criterion expertise differs | Distribute walkthrough across team |
| Walkthrough at release time only | Quality criteria degrade silently between releases | Continuous monitoring per criterion |
Limitations
References
Related skills
bug-bash-facilitator
Builds a structured bug-bash session - pre-bash kit (charter, test-data prep, environment setup, sign-up sheet), in-bash structure (role rotation across cohorts, shared backlog board, real-time triage), scoring rubric (severity weighting, novelty bonus), and a post-bash same-day wrap-up authored by the facilitator (not a standalone debrief: for post-session writeups without a live bash, use manual-test-debrief). Use when a team needs a coordinated multi-tester sweep before a release or after a major change - converts an ad-hoc "everyone test for an hour" into a recorded, comparable session with deliverables.
decision-table-test-design
Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.
exploratory-tours-reference
Pure-reference catalog of the seven exploratory testing tours from Whittaker's Exploratory Software Testing (2009): Feature, Money, Landmark, Intellectual, Bad-data, Configuration, and Garbage-collector's, each a themed mission with the signal it surfaces and a worked example. Use as the menu a charter author picks session themes from. Distinct from the mnemonic catalogs sfdpot-exploratory-heuristic (what to vary) and hiccupps-f-heuristic (oracles), and from session-based-test-management-reference, which manages the sessions.
fcc-cuts-vids-heuristic
Pure-reference catalog of Michael Kelly's FCC CUTS VIDS touring heuristic (2005): eleven tours - Feature, Complexity, Claims, Configuration, User, Testability, Scenario, Variability, Interoperability, Data, Structure - each a reconnaissance sweep that builds familiarity with an unfamiliar application. Use when onboarding onto a product or opening a first session on an unknown area, before a charter is scoped. Distinct from exploratory-tours-reference (Whittaker's seven tours, which frame a bug-hunting mission on a product the tester already knows), sfdpot-exploratory-heuristic (what to vary), hiccupps-f-heuristic (oracles), and crusspic-stmpl-heuristic (quality criteria).
hiccupps-f-heuristic
Pure-reference catalog of Michael Bolton's HICCUPPS-F oracle heuristic - the reference points a tester consults to decide 'is this a bug?': History, Image, Comparable products, Claims, Users' desires, Product (internal consistency), Purpose, Standards/statutes, plus Familiar problems. Use mid-session to test an observation against each oracle. For what to VARY use sfdpot-exploratory-heuristic, for touring an unfamiliar product use fcc-cuts-vids-heuristic, for quality criteria use crusspic-stmpl-heuristic.
manual-test-debrief
Session debrief template + tour-coverage tracker - captures the SBTM PROOF format (Past, Results, Obstacles, Outlook, Feelings) plus three-bucket time accounting (test design / setup / bug investigation), the tours applied + areas covered + areas skipped, and the per-session quality-of-attention signal. Output is the artifact a charter delivers into; the team aggregates debriefs across sessions to track what's been explored vs what's still uncharted. Use after every exploratory session - without the debrief, the session's findings disappear.
manual-test-script-author
Builds stakeholder-readable scripted manual test cases from a feature spec - emits either a step-table format (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review or a Gherkin Given/When/Then format for BDD-aware teams. Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script - UAT, regression baselines, certification testing, exploratory follow-up scripts.
manual-testing-overview
Teaches human-driven testing end to end: when a predefined scripted test case is the right instrument versus a time-boxed exploratory session, how session-based test management works (charter with a stated mission, time box, session notes, debrief) with a worked charter and a filled-in session sheet, a decision rule for what to automate versus what to keep human, and what makes a manual bug report actionable (exact reproduction steps, observed versus expected, build and environment, evidence). Use when planning or running testing a person performs by hand, writing a charter for an exploratory session, deciding whether a check belongs in an automated suite or in a human session, or fixing bug reports that developers keep returning as not reproducible.
session-based-test-management-reference
Pure-reference catalog of Session-Based Test Management (SBTM) - the Bachs' framework for running exploratory testing as time-boxed sessions: the session (60-90 min), the charter (Explore X with Y to discover Z), the session-sheet structure, the TBS metrics, the cross-session dashboard, and the PROOF debrief. Use when authoring exploratory-testing charters, reviewing session sheets, or setting up time-boxed test sessions. Distinct from manual-test-debrief (the PROOF debrief template), exploratory-tours-reference (the session themes), and the heuristic catalog hiccupps-f-heuristic.
sfdpot-exploratory-heuristic
Pure-reference catalog of James Bach's SFDPOT heuristic - 'San Francisco Depot' - a 'you are here' framework that catalogues what a tester can vary in a system to find bugs. Six dimensions: Structure, Function, Data, Platform, Operations, Time. Use as a what-to-vary checklist during an exploratory session, complementing HICCUPPS-F (which catalogues what to compare against).
state-transition-test-design
Derives human-readable manual test cases from stateful behavior: identify states, events, transitions, and guard conditions, draw the state table including invalid (empty-cell) transitions, choose a coverage level (all states, valid transitions / 0-switch, transition pairs / 1-switch per Chow, all transitions including invalid ones), then derive one test case per coverage item as an event sequence with per-step expected states (ISTQB CTFL v4.0 section 4.2.4). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use for lifecycle entities (accounts, orders, subscriptions), workflows, and UI wizards where the response to an event depends on the current state.
test-execution-checklist
Converts a regression suite (or test plan) into an executable manual checklist for cases when automation isn't viable - a release-day smoke checklist, a post-incident verification list, or a periodic compliance check. Outputs a per-TC checkbox list with the minimal preconditions, the action, and a one-line "what to look for" - short enough to fit on one page per major flow. Use when the team needs a focused human-runnable list (not full step-tables), e.g., for production smoke after deploy or for the on-call rotation's quick verification.
uat-script-author
Emits User Acceptance Testing scripts in stakeholder-readable format - pre-conditions / business-language steps / expected business outcome / pass-fail / sign-off. Tailored for non-developer testers (end users, SMEs, solution owners) per the UAT canonical definition. Output is one TC per stakeholder-meaningful scenario with explicit sign-off, suitable for compliance / contract / audit records. Use when a release requires formal UAT before sign-off - typical for B2B contracts, regulated industries, or any delivery where the customer's acceptance is the contractual gate.