Error guessing: how senior testers find bugs juniors walk past

Two testers get the same new feature and twenty minutes each. The junior tester runs the eight cases in the ticket, finds nothing, and reports it as passed. The senior tester finds six problems, including one that would have taken the site down at month end.

Ask her how she knew where to look and she will say something unhelpful, like "it felt like the kind of thing that would break".

She is not guessing. She is running a list she has built over years without writing it down. This article writes it down.

Short version

• Error guessing means using experience to predict where bugs are likely to hide.
• It works because the same mistakes appear in every codebase.
• Turn the intuition into a written checklist and juniors can use it immediately.
• The strongest source of guesses is your own team's bug tracker.
• Use it after the planned tests, never instead of them.

---

What error guessing actually is

Error guessing is a testing technique where you use what you know about how software fails to choose what to try next. There is no formula. The input is experience; the output is a list of things worth attacking.

It sits in a family called experience-based techniques, alongside exploratory testing. Formal techniques such as boundary value analysis tell you what to test from the specification. Error guessing tells you what to test from the specification's silence — the things nobody wrote down.

Both are needed. The specification says what should happen. Most bugs live in situations the specification never mentioned.

Why it is not really guessing

Software fails in patterns. The same handful of mistakes shows up in every language, every framework, and every team.

Developers forget the empty case, because they build with data on screen. They assume input is the right type, because their test data always is. They handle the success path first and run out of time for the failure path. They write validation in the browser and forget the server. They test with three records and ship to customers with thirty thousand.

None of that is specific to your product. Which means the list is transferable, and which means it can be taught.

Junior move, senior move

The difference is rarely effort. It is usually the second question.

Every row in the right column takes under a minute. That is the point.

The reusable checklist

Keep this near your desk. Work through the groups that apply to whatever you are testing.

Nothing at all

• Empty list, empty search result, empty inbox, brand new account with no data
• Empty string, only spaces, only a newline
• Optional fields left blank
• A file with 0 bytes

Too much

• 10,000 characters in a text field
• 500 items in a cart, 50,000 rows in a table
• 40 tabs open on the same page
• A name longer than the column it sits in

The wrong type or shape

• Letters in a number field, 25.5 where a whole number is expected
• Negative numbers where only positive make sense
• A .pdf renamed to .png
• null, undefined, NaN, and 0 treated as if they were the same thing

Timing

• Double click, triple click, click during the loading spinner
• Press back, then forward, then refresh
• Two browser tabs doing the same action at once
• Let the session expire, then act
• Start an action offline

Identity and permissions

• Log in as a Viewer and open an Admin URL directly
• Change a user's role while they are logged in
• Remove a user from a team while they have a page open
• Try another customer's record ID, for example /api/invoices/1042

Money and numbers

• 100% discount making the total 0.00
• A refund larger than the payment
• Splitting an amount three ways and adding it back up
• Currency with no decimals, such as JPY
• Very large amounts that overflow the field width

Text and language

• Emoji, accented letters, Chinese characters
• Right-to-left text such as Arabic
• Strings that look like code: <script>, '; DROP TABLE, {{7*7}}
• Leading and trailing spaces on an email address

The environment

• A slow connection, throttled to 3G in browser dev tools
• A narrow window, 320 pixels wide
• Browser zoom at 200%
• A blocked third-party script

Building your own list

The generic list above is a starting point. Your own list will be better, because it comes from your product.

1. Open your bug tracker and export the last 100 closed bugs.
2. Read only the titles and root causes. Ignore severity for now.
3. Group them by trigger, not by feature. "Empty state", "concurrent action", "role change", "timezone".
4. Count the groups. You will usually find three or four groups covering half the bugs.
5. Write one check per group in the form of an action: "delete all records and reload".
6. Add the list to your pull request template or test charter so it gets used.

Do this once a quarter. It takes about an hour and it is the highest-value hour in the quarter.

Two extra sources are worth mining. Support tickets show you what real users do that you never imagined. Post-incident reviews tell you exactly which assumption broke, and that assumption is almost always present elsewhere in the codebase.

Using it in a session

Error guessing works best in a short, focused burst after the planned testing is done.

Give yourself 30 minutes and one goal, for example "break the invoice screen". Pick three groups from the checklist and work through them. Write down what you tried, even when nothing happened, so the next person does not repeat it.

Bugs found this way are often intermittent, which makes them easy to dismiss and hard to reproduce. Capture the evidence the moment it happens rather than trying to recreate it later. Reporting straight from the page with a tool like Crosscheck, which attaches the screenshot, console errors, network calls, and browser details automatically, means a one-in-ten bug still arrives as a complete report.

Bad: "Search sometimes breaks with weird characters."

Good: "Searching for % on https://staging.example.com/invoices returns a 500 and logs SyntaxError: unterminated format specifier. Happens every time. Searching for laptop% also fails."

Where error guessing goes wrong

Using it as a replacement. It has no coverage measure. Nobody can say what you did or did not check. It supplements the formal techniques; it does not replace them.

Keeping it in one person's head. If the list is not written down, it leaves when that person leaves.

Guessing without recording. Untracked exploration cannot be repeated or reviewed. A rough note per session is enough.

Reporting weak findings. A guess that produces "this feels slow" wastes everyone's time. Turn each finding into a reproducible case with a specific input and a specific expected result, or drop it.

Frequently asked questions

Is error guessing a real technique or just experience?

It is a recognised experience-based technique and appears in standard testing syllabuses. What makes it a technique rather than luck is writing the heuristics down and reusing them.

Can a junior tester do error guessing?

Yes, from day one, using a borrowed checklist. The list is the shortcut around the years of experience. They will add their own entries within a few months.

How is it different from exploratory testing?

Exploratory testing is a broader way of working where you design and run tests at the same time. Error guessing is one of the tools you use while doing it.

Should error guessing findings become automated tests?

The ones that matter, yes. If a guess finds a real bug, add a regression test so the same mistake cannot come back.

How much time should a team spend on it?

A common split is a short session per story, plus a longer session before a significant release. Even 20 minutes per feature finds things the scripted cases miss.