Exploratory Testing Heuristics and Charters

A 90-minute exploratory session has a built-in problem: where do you actually look? Modern applications have thousands of features, dozens of edge cases per feature, and effectively infinite possible interactions. Heuristics are the mental shortcuts experienced testers use to focus a session on the places bugs are most likely to live. Combined with sharp charters, they turn time-boxed exploration into a disciplined hunt.

A heuristic wheel

The most-used heuristic frameworks come from James Bach's school of exploratory testing. Three are worth memorising.

SFDPOT (San Francisco Depot) — a tour heuristic for any feature:

• Structure. What is the feature made of? Pages, fields, components, modules.
• Function. What does it do? Capabilities, operations.
• Data. What does it process and remember?
• Platform. What does it depend on? Browser, OS, network.
• Operations. How is it used? Workflows, user intent.
• Time. What changes over time? Sessions, expirations, dates.

Touring a feature through SFDPOT generates dozens of test ideas in minutes, and forces coverage of dimensions a tester might naturally skip.

HICCUPPS — for "oracles" (how do I know if it's wrong?):

• History — does it match how it used to work?
• Image — does it match brand and design standards?
• Comparable products — does it match what competitors do?
• Claims — does it match what we said it would do?
• User expectations — does it match what users assume?
• Product — is it consistent with itself?
• Purpose — does it actually solve the user's problem?
• Standards — does it follow accessibility, security, legal standards?

For each "wrong" you find, HICCUPPS gives you a way to articulate why it is wrong — turning a vague "feels off" into a specific, actionable bug.

The Goldilocks heuristic — for any input or condition, what happens with too little, too much, and just right? Tiny inputs, huge inputs, missing inputs, default values, null, zero, negative, infinity.

Charter patterns that produce results

Some charter shapes consistently produce useful sessions. Steal these and adapt:

• Tour charter. "Tour the [feature] using the [heuristic] heuristic, looking for [type of issue]." Example: "Tour the checkout flow using SFDPOT, looking for state-management bugs."
• Persona charter. "Test [feature] as [specific user type] would." Example: "Test the onboarding flow as a non-technical user on a slow rural connection."
• Risk-based charter. "Probe [feature] for risks related to [risk category]." Example: "Probe the password reset flow for security risks."
• Variation charter. "Repeat [scenario] under [N variations]." Example: "Run checkout under 5 different network conditions: fast, slow, intermittent, offline mid-flow, returning from offline."
• Hostile charter. "Try to break [feature]." Example: "Try to break the file upload feature with malformed, oversized, and adversarial input."
• Comparison charter. "Compare [our feature] with [competitor's]." Example: "Compare our search results against Google's for the same queries — what does the user expect?"

A good rule: every charter should fit on one line. If yours is longer, you have multiple charters mashed together.

Common bug patterns to keep in mind

A starter library of patterns to chase:

• Empty states. What does the page look like with zero data? With one item? With 10,000?
• Error states. What happens when the network drops mid-action? When the API returns 500? When the user is logged out unexpectedly?
• Loading states. Is there one? Does it cover slow connections? Does double-clicking submit twice?
• Concurrency. What happens when two users edit the same record? When a user opens two tabs?
• Time travel. What happens at midnight? Daylight saving? Year boundary? Leap day?
• Locale. What happens in non-English languages? Right-to-left? With non-Latin characters?
• Accessibility. Can it be operated by keyboard alone? With a screen reader? With high contrast mode?
• Recovery. What happens after a crash, a network drop, a session expiry?

Each of these can become its own charter, and most produce bugs in features the team thought were "done."

Note-taking during sessions

Heuristics generate ideas; notes capture results. A simple structure works well:

• Done: what you tested
• Found: bugs and concerns
• Skipped: things you noticed but did not investigate (deferred to follow-ups)
• Questions: spec ambiguities or open issues for product
• Risks: areas you didn't get to but think need attention

Even shorthand notes are valuable. The goal is not a polished report — it is enough state for the debrief and any follow-up sessions.

Debriefing as a craft

The debrief converts session output into team knowledge. A skilled lead asks questions that draw out tacit findings:

• "What surprised you?"
• "What would you have explored if you had another hour?"
• "Where do you think the next bug will come from?"
• "Did anything feel slow, weird, or off — even if you couldn't pin it down?"

The answers often produce more insight than the formal bug list.

What you should walk away with

Heuristics turn open-ended exploration into focused investigation. Charters set the boundary; heuristics provide the lens; notes capture the findings; debriefs share the knowledge. The next chapter takes everything you have learned and grounds it in the practical reality of your first day as a QA engineer.