sfdpot-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).
sfdpot-heuristic
Overview
SFDPOT is James Bach's "San Francisco Depot" heuristic - a catalogue of what can be varied during testing. Published at satisfice.com and in James Bach's testing-curriculum materials.
If HICCUPPS-F (hiccupps-f-heuristic) catalogues what to compare against (oracles), SFDPOT catalogues what to change during exploration. Together they form a complete "how to think about a session" pair.
This skill is a pure reference consumed by exploratory-charter-author and by testers mid-session.
When to use
The six dimensions
S - Structure
What can I vary about how the system is built?
The internals of the system. Includes:
A "Structure" exploration might toggle internal options, route through a non-standard code path, or inspect how the system behaves under a non-default build.
F - Function
What can I vary about what the system does?
The feature surface area. Includes:
A "Function" exploration runs each function - and especially combinations - that the test plan didn't enumerate.
D - Data
What can I vary about the values the system handles?
The input + state space. Includes:
A "Data" exploration feeds pathological inputs - see malicious-payload-bank for canonical payloads.
P - Platform
What can I vary about the environment the system runs on?
The deployment platform. Includes:
A "Platform" exploration tests across the matrix. Compose with qa-compatibility for systematic matrix testing.
O - Operations
What can I vary about how the system is used?
User behaviour patterns. Includes:
An "Operations" exploration simulates real user workflows rather than test scripts.
T - Time
What can I vary about when / for how long things happen?
Temporal dimensions. Includes:
A "Time" exploration is the hardest to plan - many time-related bugs require deliberate clock manipulation. See qa-time for clock-mocking tooling (Tier 2 ROADMAP - not yet shipped at this writing).
Worked example - applying SFDPOT to a checkout charter
Charter: "Explore the checkout flow to discover bugs."
Apply SFDPOT to plan the session:
- **S — Structure:** Toggle the `feature-new-checkout=true` flag
in middle of the session to compare old vs new code paths.
- **F — Function:** Stack multiple promos; combine with gift card;
combine with store credit. Trigger refund mid-checkout.
- **D — Data:** Cart with 0 items, 1, 100, 1000 items. Cart with
free items only. Cart with $0.01 total. Cart with $9999.99
total. Invalid product IDs.
- **P — Platform:** Safari iOS (autofill / Apple Pay), Chrome
desktop, low-bandwidth Android.
- **O — Operations:** Add → remove → re-add an item. Navigate
away and return. Refresh during payment processing.
- **T — Time:** Apply a promo that expires in 1 minute, then
delay 70 seconds. Open two tabs simultaneously and check out
from each.This shapes a richer session than "click around the checkout page."
SFDPOT vs other heuristics
| Heuristic | What it catalogs |
|---|---|
| SFDPOT | What to vary during exploration |
| HICCUPPS-F | What to compare against when interpreting observations |
| FCC-CUTS-VIDS | What to list about the system (specification-style) |
| CRUSSPIC-STMPL | Quality criteria to evaluate against |
| Tours (Whittaker) | Themed exploration missions |
They're complementary, not competing - a strong session uses multiple. Bach + Bolton's Rapid Software Testing curriculum teaches all of them as a toolkit.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Picking one dimension only | Other dimensions yield bugs the chosen one misses | Mention each dimension's pick in the charter |
| Skipping Time | Time bugs are common but easy to forget | Always consider T in any session involving state |
| Confusing Data + Operations | Variants overlap | Data = what values; Operations = how the user moves through |
| Pre-scripting SFDPOT into test cases | Defeats exploration | SFDPOT is for generating ideas; the tester decides moment-to-moment |
| Operations as "user persona testing" | Not exactly: Operations is variant-of-use, not variant-of-user (which is Platform's locale + skill / familiarity) | Treat O as variation of use-patterns |