fcc-cuts-vids-heuristic
Pure-reference catalog of James Bach's FCC CUTS VIDS heuristic - a 10-letter mnemonic for the dimensions a tester catalogs when *modelling* a system. FCC: Format, Constraints, Connections. CUTS: Coverage, Users, Tasks, Sequences. VIDS: Variables, Inputs, Data, Storage. Use as the system-modelling checklist that complements SFDPOT (what to vary) and HICCUPPS-F (what to compare against).
fcc-cuts-vids-heuristic
Overview
FCC CUTS VIDS is one of James Bach's lesser-known but powerful exploratory-testing heuristics. Where SFDPOT ( sfdpot-heuristic) catalogues what to vary, FCC CUTS VIDS catalogues what to model. The distinction: variation drives the session; modelling is what the tester learns about the system as exploration progresses.
Published in the Rapid Software Testing curriculum ( satisfice.com/rapid-software-testing) and referenced widely in Bach + Bolton teaching material.
This skill is a pure reference consumed by exploratory-charter-author and senior testers building system models.
When to use
The ten dimensions
FCC (the system shape)
F - Format
What is the shape / format of inputs + outputs?
Specific data formats the system reads + writes:
Modelling Format means listing every format the system touches - including where format boundaries are (parser, serialiser, transport layer).
C - Constraints
What are the rules the system enforces?
Constraints define what should happen; exploration tests whether the system holds them under stress.
C - Connections
What does the system integrate with?
Each connection is a potential boundary where things can fail - prime exploration territory.
CUTS (the user shape)
C - Coverage
What categories of behaviour does the system cover?
Where in the feature space does the system claim to operate? Not what tests cover the code (that's qa-test-impact-analysis) - this is what the product claims to do.
U - Users
Who uses the system, and how?
Modelling Users surfaces "who's a tester for this system?"
T - Tasks
What goals do users have when using the system?
Not features (that's part of F - Function in SFDPOT). Tasks:
Tasks span features. A bug that breaks a task (even if every feature works individually) is high-impact.
S - Sequences
What orderings of user actions are expected?
Sequences differ from Operations (SFDPOT) - Sequences is the shape of expected user paths; Operations is the variation of how users navigate them.
VIDS (the data shape)
V - Variables
What runtime values vary, and within what bounds?
System-level variables - settings, configs, feature flags. These aren't user inputs; they're values the system holds + uses to behave differently:
I - Inputs
What does the system receive from outside?
User-supplied data - distinct from system variables. Bach's distinction: Variables are internal state; Inputs are external data crossing into the system.
D - Data
What does the system store / process / produce?
The system's data lifecycle. What gets written + read + how it flows through the system. Different from Input - Data is what the system owns + transforms, not what arrives.
S - Storage
Where and how does data persist?
Storage matters because durability + consistency expectations differ across these layers.
Worked example - building a checkout-system model
**System:** Checkout flow (cart → payment → confirmation)
**F — Format:** Cart JSON; payment-intent JSON (Stripe); webhook
HTTP/JSON; receipt PDF; order email HTML.
**C — Constraints:** Cart total > $0.01; max 100 items; promo
expiry; tax-jurisdiction rules per locale; PCI scope for card
data.
**C — Connections:** Stripe (payment intent + webhook); SendGrid
(receipt email); inventory service (stock-lock); tax service
(Avalara); identity service (auth).
**C — Coverage:** Standard checkout; gift-card checkout; subscription
checkout; bulk-B2B checkout. NOT covered: split-tender, multi-currency
within one cart.
**U — Users:** Anonymous, free, paid, B2B admin, partner-integration.
**T — Tasks:** "Buy this item", "Apply my promo", "Use my saved
card", "Get a receipt for expenses".
**S — Sequences:** Add → cart → checkout → pay → confirm; resume
abandoned cart; refund flow.
**V — Variables:** `feature-new-checkout`, `max-cart-items`, `tax-fallback-rate`,
`stripe-timeout-ms`.
**I — Inputs:** Cart contents (user input); promo code (user input);
payment method (user input); shipping address (user input).
**D — Data:** Order record; payment record; tax record; promo-usage
record; inventory deduction.
**S — Storage:** Orders in Postgres; payments in Stripe (external);
cart in Redis (TTL 24h); receipts in S3 (immutable).Now the charter has a tangible model to reference: "Explore the checkout flow's data lifecycle (D + S in FCC CUTS VIDS) - focusing on edge cases where Postgres + Stripe + Redis disagree about state."
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Skipping FCC CUTS VIDS for "simple" systems | Even simple systems have model-able dimensions; skipping = under-prepared | Always do at least a sketched model |
| Confusing V (Variables) with I (Inputs) | Internal-state bugs masquerade as input-handling | V = system-owned; I = user-supplied |
| Confusing T (Tasks) with F (Function in SFDPOT) | Functions are mechanical; tasks are goal-oriented | Task = user's goal, not feature label |
| Modelling once, then never updating | System evolves; model gets stale | Update model per session |
| Trying to write a complete model before any session | Analysis paralysis; never starts exploring | Sketch the model; refine via sessions |