Error Guessing

Why it matters

Specification-based techniques test what the requirement says. Many costly defects sit in what it does not say: a double submit, a session that expires during payment, an empty list for a new user. Experience-based techniques complement black-box and white-box techniques because they can find defects those techniques miss.

For the tester, it puts the team’s defect history to work. Done casually, though, it depends on one person’s memory and nobody can say what was covered; this lesson makes it repeatable.

What you guess: errors, defects and failures

Reason along the chain from the lesson on error, defect and failure: a developer forgets that a customer can have no orders (error), the code has no branch for an empty list (defect), and the order history crashes for a new customer (failure). The test is cheap: open the order history as a brand-new customer.

The test basis is the tester’s knowledge, not a specification, so coverage is hard to measure. Some teams say "error guessing" for any unplanned clicking around; here it means tests derived from a stated expectation of what is likely to fail. The syllabus names three sources of that knowledge:

• How the application has worked in the past: its defect history and fragile modules.
• The errors developers tend to make: > instead of >=, a missing null check, a fix applied to one copy of the code but not another.
• Failures in similar applications: sign-up forms, checkouts and file imports fail in familiar ways.

A list of typical errors

The syllabus groups errors, defects and failures into six areas. Use them as the headings of your list; each bullet gives the syllabus examples, then ideas to try.

• Input: correct input not accepted, parameters wrong or missing. Try O'Brien, leading spaces, or an API request missing a field the app always sends.
• Output: wrong format, wrong result. Try amounts that need rounding, Arabic text in a PDF, and screens that may show null.
• Logic: missing cases, wrong operator. Try the case nobody listed, such as an order both discounted and partly refunded.
• Computation: incorrect operand, wrong computation. Try tax on a discounted price and a division by a count that can be zero.
• Interfaces: parameter mismatch, incompatible types. Try a number sent as a string and a date passed between systems in another format.
• Data: incorrect initialisation, wrong type. Try a new user with no history and a value too large for its column.

Try it: Negative Test Generator Try it: Special Character Dataset Generator

Fault attacks: guessing from a list

A fault attack is the methodical way to apply error guessing: create or acquire a list of possible errors, defects and failures, then design tests that expose those defects or cause those failures. The ISTQB glossary describes an attack as a directed, focused attempt to force specific failures to occur. It is not a security attack: you aim it at your own product, in a test environment.

Each entry, drawn from experience, defect data or common knowledge of why software fails, is a hypothesis about where the product is weak. The attack turns it into a test with concrete data and an expected result:

ID          FL-07
Area        Logic (missing case)
Hypothesis  A form submitted twice creates two records
Evidence    Found twice in our defect history: DEF-112, DEF-240
Attack      Double-click "Pay"; press Enter twice; go Back and resubmit
Expected    One order and one charge; the second submit is ignored
Applies to  Every form that creates, pays for or sends something

Worked example: a CSV employee import

Requirement: "HR admins can import employees from a CSV file with the columns employee_id, full_name, email and hire_date (DD/MM/YYYY). Valid rows are imported; invalid rows are listed in an error report with their row number. A summary shows how many rows were imported and how many were rejected."

The specification-based tests already exist. Now write one attack per area, with the expected result or, where the requirement is silent, a question.

• Input: a byte order mark (BOM) before employee_id, as some spreadsheet programs save it, and the quoted name "Al-Harbi, Sara" → header recognised, name stored whole.
• Output: rejected rows → the row numbers in the error report match the file, where the header is row 1.
• Logic: the same employee_id twice, or an ID that already exists → the requirement is silent: reject, update or skip? Ask the product owner.
• Computation: 100 data rows, 3 of them invalid → 97 imported, 3 rejected; the header is not counted.
• Interfaces: hire date 03/04/2026 → 3 April 2026, not 4 March, in the API response and database, not only on screen.
• Data: a header-only file → "0 imported" and no crash; a file ending in an empty line → the empty line is not reported as an invalid row.

Try it: CSV Dataset Generator Try it: Unicode Dataset Generator

Making error guessing systematic

Error guessing becomes a team method rather than one person’s talent when the list is written down, fed with evidence and maintained:

• Collect evidence: root causes of defects from testing and production, support tickets, developers’ worries about the change.
• Keep one shared fault list, grouped by the six areas; each entry has a hypothesis, evidence and a sample attack.
• Select the entries that fit the change, most likely and most damaging first; note what you skip.
• Attack in a time-box; record the entry, data and result, so the attack can be reported and repeated.
• Update the list: add new patterns, retire entries that never find anything, and turn steady finders into regression tests or checklist items (the next lesson).

Try it: Edge Case Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.