Experience-Based · ISTQB 4.4.1

Error Guessing

Anticipate where the system is likely to break, based on experience and knowledge of common failure patterns. Formalised intuition — not random guessing.

Junior Senior ISTQB CTFL v4.0 — 4.4.1

1 The Hook

An Auckland team launches a donations page for a charity. The specification is simple: enter an amount, enter your card, donate. They write equivalence and boundary tests for the amount field — small, large, zero, negative — all pass. The build ships clean.

A week later a supporter pastes a name with a macron into the donor field — “Māori Education Fund” — and the receipt comes back with a string of mojibake where the name should be. Another donor double-taps the Donate button on a slow connection and is charged twice. Neither bug was in the spec, so no spec-based test went near it. But an experienced tester would have guessed both before opening the app: text fields break on accented characters, and slow networks invite double-submits.

That instinct — knowing where software tends to break before anyone tells you — is error guessing. The spec tells you what should work; experience tells you what usually doesn’t. The two together catch far more than either alone.

2 The Rule

Use experience and a catalogue of common failure patterns to aim tests straight at the likely weak spots — the things specifications don’t mention. It is formalised intuition backed by a fault list, not random guessing.

3 The Analogy

Analogy

A WOF inspector who knows where rust hides.

When a car comes in for its Warrant of Fitness, an experienced inspector doesn’t check the panels at random. They go straight for the spots that fail on cars like this one: the bottom of the door sills, the strut towers, the chassis rails near the back wheels. They have seen a thousand of these, so they know where the rot starts. A first-week apprentice with the same checklist would still find some faults — but the veteran heads for the trouble first and finds more, faster.

Error guessing is testing with that inspector’s nose. Your fault list is the memory of every car you’ve seen rust through, and you point your tests at the sills before you bother with the bonnet.

What it is

Error guessing is a technique where you use experience, knowledge of the application, and a list of common failure patterns to design tests that target likely weak spots. It supplements systematic techniques — you use EP/BVA to cover the spec, then use error guessing to go after the things specs don’t cover.

The key word is anticipate. An experienced tester knows that text fields often crash on emoji, that date fields break at year boundaries, that "0" and "-1" cause integer overflow bugs. Error guessing turns that knowledge into specific test cases.

Building a fault list

A fault list (or attack list) is your personalised catalogue of things that tend to go wrong. Build one over your career and use it on every project. Examples:

Starter fault list — common failure triggers

Input type	Values to try	Why
Numeric fields	0, -1, very large numbers, decimals	Off-by-one, integer overflow, type mismatch
Text fields	Empty, spaces only, 1 char, max+1 chars, SQL injection strings, emoji, null	Boundary, encoding, injection, null handling
Dates	29 Feb non-leap year, 31st in 30-day month, past date, future date, epoch	Calendar edge cases, timezone bugs
File uploads	0 byte file, max size + 1, wrong extension, executable disguised as image	Validation bypass, security
Dropdowns	First option, last option, default/empty, — option	Off-by-one in arrays, unhandled null
Concurrent actions	Double-submit, two tabs, race conditions	Duplicate records, state corruption

Common failure areas by domain

E-commerce: price = 0, quantity = 0, empty cart checkout, expired discount code
Authentication: empty password, password with spaces, case sensitivity, concurrent logins
Search: empty search, single character, wildcard characters, XSS payloads
Reports / exports: 0 rows, thousands of rows, columns with null values, special characters in data

Using a defect taxonomy

At senior level, replace informal fault lists with a formal defect taxonomy — a classification scheme of known defect types. The IEEE Standard Classification for Software Anomalies and ISTQB’s taxonomy include categories like: Logic, Computation, Interface, Data, Timing, and Environment. Using a taxonomy ensures you don’t skip whole categories of failure.

ISTQB mapping

ISTQB CTFL v4.0 reference

Ref	Topic
4.4.1	Error Guessing — anticipating errors, faults, failures based on experience
4.4.1	Fault lists, defect taxonomies, tester experience as a test basis

Practice this technique: Try Junior Practice 02 — Email & phone validation, Senior Practice 03 — Async & loading states.

NZ example — NZ-specific edge cases

New Zealand has several input edge cases that catch systems out. Add these to your NZ fault list.

NZ fault list — inputs that break non-NZ-aware systems

Input area	NZ edge case	Common failure
Rural addresses	"RD 2, Masterton" — no street number	System requires numeric house number; rejects valid rural address
Unit notation	"2/14 Main Street" or "Flat 2, 14 Main Street"	System expects one format; rejects the other
Mobile numbers	021, 022, 027, 028, 029 prefix (10 digits with leading zero; 9 without)	Field requiring exactly 10 digits rejects numbers entered without leading zero
Landline numbers	09 Auckland, 04 Wellington, 03 South Island	Validation pattern built for one region rejects others
Date format	NZ uses DD/MM/YYYY; US software defaults to MM/DD/YYYY	03/07/2024 = 3 July (NZ) vs March 7 (US system) — silent data corruption
Bank account numbers	BB-bbbb-AAAAAAA-SS format (2-4-7-2 or 2-4-7-3 digits)	Form expects 16-digit card number format; many wrong submissions

4 Now You Try

Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.

🔍 Exercise 1 of 3 — Spot: name the likely failures

A NZ Post parcel-tracking form has one field: a tracking number (free text), and a Search button. The spec only says “accept a valid tracking number and show the parcel status”. Using error guessing, list at least six likely failure points the spec doesn’t mention, and say what bug each one is hunting for.

Show model answer

Likely failure points for a free-text tracking field:
1. Empty search — submitting with nothing entered (no required-field handling).
2. Leading/trailing spaces — " ABC123 " pasted from an email (whitespace not trimmed → "not found").
3. Wrong case — abc123 vs ABC123 (case-sensitive lookup rejects a valid number).
4. Very long string / 10,000 characters pasted in (no max length → crash or slow query).
5. Special characters and injection strings — '; DROP TABLE…,