Error Guessing and Experience-Based Techniques

The first four lessons of this chapter all derive test cases from a structure — a state diagram, a decision table, a parameter set, a use case. Error guessing is the deliberate complement: tests that come from a tester's experience with where bugs tend to live, not from any artefact the team has written. In the hands of a junior tester, "error guessing" sounds suspiciously close to "guessing." In the hands of an experienced one, it is one of the highest-yield techniques in the toolkit. The difference is that the experienced tester is not really guessing — they are pattern-matching against a catalogue.

What error guessing actually is

Error guessing is a structured form of intuition. The tester walks through a feature mentally and asks, at every input, "what is the kind of value that has historically broken this kind of feature?" Because the catalogue of "bug-prone places" is finite and well-documented, error guessing is teachable — you do not have to wait years to acquire it.

It is most powerful when layered on top of the formal techniques in this chapter, not used as a replacement. The structured techniques give you coverage of the spec. Error guessing gives you coverage of the gaps in the spec — the places where the spec is silent and a bug can live unnoticed.

Common error-prone areas

Most bugs cluster in a small number of categories. The map below shows the recurring patterns and the application areas they typically appear in. Train yourself to recognise each one on sight.

Common error categories

– Min / max values
– Off-by-one
– First / last item
– Pagination edges

– Empty strings
– Null fields
– Missing optional fields
– Whitespace only

– Unicode & emoji
– Quotes & apostrophes
– Script & SQL
– Newlines & tabs

Timezones –
Daylight saving –
Leap years –
Month rollovers –

Two tabs at once –
Race conditions –
Large datasets –
Slow networks –

A great manual tester carries this catalogue in their head. When they look at a date field, the four "Date & time" patterns light up automatically. When they look at any input field, the four "Empty & null" patterns light up. The patterns become reflexes.

Building a personal error taxonomy

The best testers maintain a written catalogue of error patterns — not one in their head. Each entry answers two questions: what is the pattern? and where in this product might it appear? Writing it down survives memory loss, transfers to the team, and gets sharper every quarter as you update it after each incident.

A taxonomy entry is short — three lines is enough. Pattern: apostrophes in user names break SQL queries. Where it lives: any text input later used in a query. Test: try O'Brien and John "JJ" Smith. Build 50 of these and you will find bugs in the first hour of any new feature.

Checklist-based testing

Once you have a taxonomy, run through it as a checklist on every new feature. The discipline is to apply the whole list every time, not just the entries that "feel relevant." For a search field, that produces something like:

Empty search.
Single character.
Very long string (500+ characters).
Special characters: <script>alert(1)</script> (XSS probe), '; DROP TABLE-- (SQL injection probe).
Emoji: 🔍 🌍 👨‍👩‍👧‍👦 (the last one is a single grapheme made of multiple code points).
Leading and trailing spaces.
Unicode look-alikes: a Cyrillic а instead of a Latin a.
Search that returns zero results.
Search while the database is artificially slow.
Search submitted twice in quick succession (race condition).

That is 10 test cases derived in 60 seconds, all from a checklist. None of them appeared on a state diagram or a decision table — they came purely from the catalogue.

Ad-hoc vs experience-based testing

Error guessing is sometimes confused with ad-hoc testing, but they are not the same. Ad-hoc is unstructured clicking around without a plan. Experience-based is informed by a written taxonomy and applied as a checklist. Ad-hoc finds whatever the tester happens to think of in the moment and is not repeatable; experience-based gets the same level of coverage every time, regardless of the tester's mood. The structured form is also called exploratory testing when it is time-boxed and charter-driven — the exploratory testing heuristics cheat sheet is a good starting catalogue if you have not yet built your own.

When error guessing pays off most

This technique pays off best:

At the end of structured testing, as a final pass to find what the structure missed.
When the spec is incomplete and structured techniques have nothing to anchor on.
For input-heavy features like search bars, sign-up forms, and data importers, where the bug-prone categories above all apply.

It is least useful for purely deterministic, well-specified flows where the spec really does enumerate every case — though those are far rarer than testers tend to assume.

⚠️ Common mistakes

Treating it as random testing. "I will just click around and see what happens" is not error guessing — it is ad-hoc testing. Always carry a checklist; the catalogue is what makes the technique reproducible.
Skipping the writing-down step. A taxonomy in your head is not a taxonomy. Without writing it down, you forget half of it within months and cannot share it with the team.
Using it instead of structured techniques. Error guessing is most powerful as a layer on top of state transition, decision table, pairwise, and use case testing — not as a replacement. Use the structured techniques first; use error guessing to fill the gaps.

🎯 Practice task

Spend 30 minutes building the first version of your personal error taxonomy.

Pick three input-heavy features you have used recently — a search bar, a sign-up form, and a payment screen are good defaults.
For each, write down at least 8 error-guessing test ideas — including at least one from each of the five categories in the visual: boundaries, empty/null, special characters, date/time, concurrency/scale.
Combine the lists into a single document. Group the entries by category, deduplicate where the same pattern appears across features.
Run the resulting checklist on a fourth feature you have not yet examined. How many test ideas does the checklist generate in five minutes? How many of them feel like they could find a real bug?
Save the document. Open it before the start of every new testing assignment. Add an entry every time you find a bug that surprises you. After three months you will have a checklist worth more than any external resource.

This concludes Chapter 3. The next chapter shifts from designing test cases to running them across the full surface area where users actually meet your product — different browsers, different devices, different platforms.