Error Guessing and Exploratory Heuristics

The formal techniques you have learned so far — partitioning, boundary analysis, decision tables, state transitions — produce repeatable, defensible test cases. But the most experienced testers also use a less structured technique that is at least as powerful: error guessing. It is the practice of using pattern recognition, intuition, and accumulated scar tissue to predict where bugs are likely to hide, and looking specifically there.

What error guessing actually is

Error guessing is not random clicking. It is informed prediction. A senior tester looks at a feature and asks:

• Have I seen something like this break before? Where?
• What category of bug is this code most likely to introduce?
• Which inputs do developers typically forget to handle?
• Which integrations are usually rushed because they are tedious?

The output is a short list of specific things to try, drawn from an internal library of bugs they have seen across their career. Newer testers do not have that library yet — but they can borrow it through heuristics, which are codified versions of the same intuition.

Heuristic frameworks worth knowing

Several published heuristic frameworks exist. The most popular:

SFDPOT (San Francisco Depot) — James Bach's classic tour heuristic. Look at:

• Structure. What is the system made of? Files, modules, screens, services.
• Function. What does it do? Features, capabilities.
• Data. What does it remember and process?
• Platform. What does it run on? Browsers, OSes, networks.
• Operations. How will it be used? Workflows, intent.
• Time. What changes over time? Sessions, expirations, dates.

Walking a feature through SFDPOT generates dozens of test ideas in minutes.

HICCUPPS — another Bach acronym 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?

Goldilocks tests — for any input, what happens with too much, too little, and just right? Tiny inputs, huge inputs, missing inputs, conflicting inputs.

The "Evil User" tour — pretend you are trying to break the system. Inject scripts, paste URLs, hammer the back button, edit query parameters. Many security bugs hide here.

Common error patterns to keep in mind

A starter library, drawn from bugs that show up in almost every project:

• Empty strings in fields that "obviously" cannot be empty.
• Whitespace-only input — a string of just spaces often slips through length > 0 checks.
• Very long strings — names with 500 characters break things you would not believe.
• Unicode quirks — emojis, RTL text, combining characters, zero-width joiners.
• Negative zero, NaN, Infinity in numeric fields.
• Time zone edges — midnight, DST transitions, year boundaries.
• Leap day bugs — February 29 has tripped up countless date pickers.
• Concurrent actions — clicking submit twice, opening the same record in two tabs.
• Network failure — what happens if the request fails at exactly the wrong moment?
• Double-clicking anything that triggers a payment.
• Browser back button after submitting a form.
• Refresh mid-flow, especially mid-transaction.
• Session expiry mid-action — what happens when the user is logged out between two clicks?

Many of these are testable in seconds and find real bugs in features the team thought were "done."

Combining error guessing with formal techniques

Error guessing complements rather than replaces the formal techniques. A typical workflow:

1. Use equivalence partitioning and boundary value analysis to define the systematic test cases.
2. Use decision tables for combinations of conditions.
3. Use state transition testing for stateful features.
4. Use error guessing and heuristics to layer on top — testing scenarios the formal techniques would not generate.

The formal techniques give you breadth; error guessing gives you the specific edges you would otherwise miss. Together they produce test plans that are both defensible and creative.

How to develop the skill

Like any pattern recognition, error guessing improves with deliberate practice:

• Keep a bug journal. Every time you find an interesting bug — yours or someone else's — note the category, the cause, and the test idea that found it. Re-read the journal periodically.
• Read post-mortems. Other teams' incident reports are a free education in failure modes you have not personally encountered.
• Pair with experienced testers. Watch how they think out loud. Their intuition is mostly verbalised pattern matching that you can absorb.
• Test outside your comfort zone. Volunteer to test features in unfamiliar domains. Patterns transfer across product types in surprising ways.

What you should walk away with

Error guessing is not a license to skip structure — it is a power-up that sits on top of formal techniques. The next chapter takes you out of test design and into bug handling: how to track, report, and prioritise the issues you find.