Error Guessing
Anticipate where the system is likely to break, based on experience and knowledge of common failure patterns. Formalised intuition — not random guessing.
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:
| 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
| 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.
| 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 |
Build your own fault list
You are testing a NZ address form with these fields: Street address (text), Suburb (text), City (text), Postcode (4-digit number), Country (dropdown: NZ / AU / GB).
Expert fault list — NZ address form
- ✓ Postcode field accepts letters or special characters (should be digits only)
- ✓ Postcode accepts fewer than 4 digits (NZ postcodes are always 4 digits)
- ✓ Postcode accepts more than 4 digits
- ✓ Rural Delivery format “RD 2, Masterton” has no street number — form may reject it
- ✓ Apartment/unit notation “2/14 Main St” vs “Flat 2, 14 Main St” — form may only accept one format
- ✓ Street address field has no maximum length — could accept 10,000 character input
- ✓ Street address field accepts only numbers (e.g. “123”) — no alpha characters required
- ✓ City field accepts single character (e.g. “A”) — unlikely to be a valid city
- ✓ Country dropdown defaults to wrong country (AU instead of NZ on a NZ site)
- ✓ Form submits with all fields blank (no required field validation)
How many did you find? Even getting 4–5 of these on your first go is a solid result. Experienced testers build this intuition over years.