Testland
Browse all skills & agents

crusspic-stmpl-heuristic

Pure-reference catalog of James Bach's CRUSSPIC STMPL heuristic - twelve quality criteria a tester can evaluate a system against. CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility. STMPL: Supportability, Testability, Maintainability, Portability, Localizability. Use as the quality-criteria checklist for evaluating a product holistically; complementary to ISO/IEC 25010 quality model.

crusspic-stmpl-heuristic

Overview

CRUSSPIC STMPL is James Bach's quality-criteria mnemonic - twelve categories of "what does it mean for this system to be good?" Published in James Bach's testing-curriculum materials (satisfice.com) and widely taught.

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 consumed by exploratory-charter-author when shaping a session's evaluation lens, and by the product-risk-register-builder when categorising risks (see its "Quality characteristic" step).

When to use

  • Authoring a charter - pick which quality criteria the session will evaluate.
  • Categorising risks in the product register (product-risk-register-builder).
  • Evaluating a vendor / framework (qa-vendor-evaluator).
  • Reviewing a release candidate - walk CRUSSPIC STMPL to confirm each criterion is addressed.

The twelve 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?

  • Mean Time Between Failures (MTBF)
  • Fault tolerance (degraded mode, retry, failover)
  • Recovery time + data preservation
  • Idempotency under retry

Maps to ISO 25010 "Reliability."

U - Usability

Can the user figure out how to use it?

  • Learnability for new users
  • Efficiency for repeat users
  • Memorability after time away
  • Error-recovery from mistakes
  • Satisfaction (qualitative)

Per Nielsen's usability heuristics.

S - Security

Is the system safe from misuse?

  • Confidentiality (PII / secrets not exposed)
  • Integrity (data not modified by attackers)
  • Availability (DoS resistance)
  • Authentication + authorization
  • Auditability

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?

  • Vertical scaling (bigger machines)
  • Horizontal scaling (more machines)
  • Data-volume scaling (more rows, bigger blobs)
  • User-count scaling (more concurrent users)

Composes with qa-load-testing.

P - Performance

Is the system fast enough?

  • Response latency (p50, p95, p99)
  • Throughput
  • Resource efficiency (CPU, memory, network, disk)
  • Startup / cold-start time

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?

  • Installer / setup wizard quality
  • Configuration documentation
  • Default values appropriate
  • Upgrade path from prior versions
  • Uninstall completeness

Maps to ISO 25010 "Portability - Installability."

C - Compatibility

Does the system work alongside other things?

  • OS / browser compatibility matrix
  • Backwards-compatibility (old data, old clients)
  • Forwards-compatibility (newer data, newer clients)
  • Coexistence (same machine, same network, with other software)
  • Interoperability (API consumers)

Maps to ISO 25010 "Compatibility." Composes with qa-compatibility.

STMPL - secondary (operational) criteria

S - Supportability

Can the support team diagnose + fix issues?

  • Log quality (useful, structured, searchable)
  • Observability (traces, metrics)
  • Self-service support materials (knowledge base)
  • Escalation paths
  • Reproducibility from logs alone

A system with terrible logs is hard to support even when it's otherwise high-quality.

T - Testability

Can the testers verify the system?

  • Test hooks / instrumentation
  • Deterministic-mode toggles
  • State-inspection endpoints
  • Test-data-management hooks
  • Mock-able external dependencies

A system that's hard to test usually has worse quality everywhere else.

M - Maintainability

Can the team change the system?

  • Code clarity / structure
  • Documentation
  • Test coverage
  • Dependency management
  • Tech debt accumulation

Maps to ISO 25010 "Maintainability."

P - Portability

Can the system move between environments?

  • Cloud-provider portability (AWS / GCP / Azure)
  • OS portability
  • Container / VM portability
  • Data portability (export + import)
  • Configuration portability

Maps to ISO 25010 "Portability."

L - Localizability

Can the system be adapted to other languages + cultures?

  • Translation support
  • Right-to-left layout
  • Locale-specific formatting (dates, numbers, currency)
  • Cultural appropriateness (icons, colours, idioms)
  • ICU MessageFormat / plural rules

Composes with qa-localization.

Mapping to ISO/IEC 25010

ISO 25010 has 8 top-level characteristics:

ISO 25010CRUSSPIC STMPL
Functional suitabilityC (Capability)
ReliabilityR (Reliability)
UsabilityU (Usability)
SecurityS1 (Security)
Performance efficiencyP1 (Performance), S2 (Scalability)
CompatibilityC2 (Compatibility)
MaintainabilityM (Maintainability), T (Testability), S3 (Supportability)
PortabilityI (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-patternWhy it failsFix
Treating CRUSSPIC STMPL as flatSome 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 evaluatesInclude in release walkthrough
Skipping SupportabilityReleased system unmaintainable in productionAlways walk S
One person evaluates all 12Inter-criterion expertise differsDistribute walkthrough across team
Walkthrough at release time onlyQuality criteria degrade silently between releasesContinuous monitoring per criterion

Limitations

  • Subjective weighting. Criteria importance differs per product / domain / regulatory context.
  • Some criteria are evaluatable only in production. Reliability
    • Supportability need real usage data.
  • Mnemonic overload. Twelve letters is at the edge of working memory; testers often print the catalog.
  • Doesn't replace ISO 25010 formal model. For regulated / compliance contexts use ISO 25010 + cite formally; use CRUSSPIC STMPL as the working-memory mnemonic.

References