Question 1

What does error guessing add that EP and BVA don’t?

Accepted Answer

EP and BVA systematically cover the specification. Error guessing goes after what the spec doesn’t mention — the failure patterns experience says are likely (encoding, double-submit, injection, null handling). You use the systematic techniques first, then guess at the gaps.

Question 2

Why is “just try weird stuff” not really error guessing?

Accepted Answer

Error guessing is formalised intuition: specific inputs tied to specific known failure modes, written down so they’re reproducible. “Weird stuff” can’t be repeated, reviewed, or handed to another tester. The discipline is in the fault list, not the vibe.

Question 3

What is a fault list and how do you build one?

Accepted Answer

A personalised catalogue of inputs and conditions that tend to cause failures — empty/spaces-only/max+1 for text, 0/-1/overflow for numbers, leap-day and month-length edges for dates, double-submit for actions. You build it over a career by adding every new way you see software break, and reuse it on every project.

Question 4

At senior level, what replaces an informal fault list, and why?

Accepted Answer

A formal defect taxonomy — a classification of defect types such as Logic, Computation, Interface, Data, Timing, and Environment. Working through the categories ensures you don’t skip whole classes of failure, which informal guessing tends to do (it over-tests the familiar and ignores Timing and Environment).

Question 5

Give an NZ-specific input that breaks systems built without local knowledge.

Accepted Answer

Several: a name with a macron (Māori) that mangles to mojibake if encoding is wrong; a rural address like “RD 2, Masterton” with no street number; a mobile number with or without its leading zero; or a date read as MM/DD/YYYY when NZ uses DD/MM/YYYY, silently corrupting 03/07/2024.

Question 6

Your team is testing a new Benefits NZ benefit payment portal. Time is short — two days to sprint sign-off. How do you decide which error guesses to run first, and why?

Accepted Answer

A: Prioritise by consequence and likelihood: first run guesses that could cause a payment to be processed twice or not at all (concurrent submit, session timeout mid-form, zero-dollar or negative amounts). Next target NZ-specific data fields — Revenue NZ numbers, NZ bank account format (BB-bbbb-AAAAAAA-SS), and addresses with RD notation — because Benefits NZ claimants often have non-standard details that offshore-built validation patterns reject. Leave low-risk cosmetic guesses for later or cut them entirely. The principle: order by probability of a showstopper, not by creativity.

Question 7

What is the key difference between error guessing and exploratory testing?

Accepted Answer

A: Error guessing is input-driven — you start with a fault list of known failure patterns and design specific tests to trigger them. Exploratory testing is charter-driven — you roam the system guided by a question or risk area, using what you discover to steer the next action. In practice the two work together: your fault list seeds the "what to attack" section of an exploratory charter, and things you discover during exploration get added back to your fault list. Confusing them in an interview signals you think experience-based testing is just "playing with the app".

Question 8

A developer says "error guessing only works for experienced testers — juniors should stick to test cases from the spec." What is wrong with this view, and how do you respond?

Accepted Answer

A: The misconception treats error guessing as purely personal intuition, but a team-maintained fault list externalises that intuition so any tester can use it. A junior given the starter fault list on this page can immediately apply guesses for null handling, whitespace, double-submit, and NZ-specific inputs — all without personal experience. What juniors lack is calibration (knowing which guesses matter most for this sprint), not the ability to execute guesses. The right response is: build a shared fault list, pair juniors with it, and let them grow their calibration over time. Restricting them to spec-only tests guarantees they miss the failure classes specs never mention.

Question 9

When should you NOT rely on error guessing, and what technique should you use instead?

Accepted Answer

A: Avoid relying on error guessing alone in three situations: (1) compliance or audit contexts — NZ Privacy Act assessments, ISO 25010, or health system certification require demonstrable, systematic coverage that intuition-based tests cannot provide on their own; (2) safety-critical features such as CoverNZ claim calculations or medication dosing logic, where missing a boundary case has serious consequences and formal coverage criteria (BVA, decision tables) are required; (3) brand-new domain territory where nobody on the team has prior experience — guesses made without domain knowledge are likely to miss the failure modes that actually matter. In these cases, lead with equivalence partitioning, boundary value analysis, or decision tables, then layer error guessing on top to catch what the spec left out.

Question 10

What is error guessing, and how is it different from just randomly trying things in a system?

Accepted Answer

Strong answer:  Error guessing is a structured, experience-based technique where you use knowledge of common failure patterns to design specific tests aimed at likely weak spots — things the spec doesn’t cover. The key word is “structured”: every guess is a specific input tied to a known failure mode and written in a fault list so another tester can repeat it. Randomly trying things produces noise; a fault list produces repeatable evidence.

Question 11

When would you use error guessing on a project, and when would you not rely on it?

Accepted Answer

Strong answer:  I use it after systematic techniques like equivalence partitioning and BVA — once I’ve covered the spec, I switch to error guessing to attack the gaps. I’d also lean on it heavily for legacy NZ government systems where the defect backlog is the best fault list available. I wouldn’t rely on it alone for NZ Privacy Act compliance reviews, CoverNZ claim calculation logic, or any safety-critical feature — those need formal coverage criteria that intuition-based testing can’t satisfy in an audit.

Question 12

You’re joining a team testing the Revenue NZ’s income tax return portal and have two days before go-live. How do you prioritise your error guessing?

Accepted Answer

Strong answer:  I’d order guesses by consequence first — anything that could cause a payment to be processed twice, miscalculated, or lost gets tested before cosmetic edge cases. That means: concurrent submit and session timeout mid-form (duplicate transactions), zero and negative income values (integer handling), NZ bank account format (BB-bbbb-AAAAAAA-SS) rejection, and the DD/MM/YYYY vs MM/DD/YYYY date trap that silently corrupts filing dates. I’d also mine recent defect history — if six of the last ten bugs were encoding issues with macrons in taxpayer names, that jumps to the top of the list.

Question 13

How does using a defect taxonomy improve error guessing compared to relying on a personal fault list alone?

Accepted Answer

Strong answer:  A personal fault list reflects the failures I’ve personally seen, so it tends to over-represent the categories I work in most — usually Logic and Data — and under-represent Timing and Environment entirely. Walking through a formal taxonomy (Logic, Computation, Interface, Data, Timing, Environment) forces a guess in every category before I move on. For a KiwiSaver contribution-rate change feature that means I can’t skip “double-submit on a slow mobile connection” (Timing) or “behaviour after a session timeout on iOS Safari” (Environment) just because I haven’t hit them personally.

Question 14

A developer on your team says senior testers should do error guessing but juniors should stick to scripted test cases from the spec. How would you respond, and what would you do differently as a lead?

Accepted Answer

Strong answer:  I’d push back on that — it treats error guessing as purely personal intuition, but a well-maintained shared fault list externalises that intuition so any tester can use it from day one. As a lead I’d build a team fault list in Confluence covering the NZ-specific entries (macrons, RD addresses, Revenue NZ numbers, bank account format) plus the universal ones (null, empty, double-submit, max+1). I’d pair juniors with it, review their guesses in sprint retros, and use each project post-mortem to add new failure modes. That way the knowledge survives staff turnover — which is a real risk I’ve seen cost teams heavily when the one “experienced” tester leaves.

Question 15

Give me two NZ-specific error guesses you’d add to a fault list for any form collecting personal details from New Zealanders.

Accepted Answer

Strong answer:  First, a name containing a macron — like “Māori” or “Whānau” — to catch encoding failures that turn te reo Māori characters into mojibake; this is a real failure mode on legacy NZ health and government platforms. Second, a rural delivery address in RD notation such as “RD 2, Masterton”, which has no street number and will fail any validation that requires a numeric house number — a common issue on platforms built offshore without NZ addressing standards in scope.

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

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

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

Context	Priority	Why
Legacy NZ government or banking system (Revenue NZ, Benefits NZ, CoverNZ, KiwiFirst Bank)	Essential	Decades of accumulated technical debt make legacy codebases fault-rich; the defect backlog is your best fault list, and experienced testers surface more bugs per hour here than any structured technique.
Agile sprint with a narrow time window (1–2 days to sign-off)	High	A prioritised fault list lets you triage to the highest-consequence guesses first — far faster than building full scripted coverage under deadline pressure.
Regulated system requiring audit trail (NZISM, NZ Privacy Act, health certification)	Medium	Useful as a supplement after EP/BVA and decision tables have established systematic coverage — but auditors require demonstrable criteria, so error guessing alone cannot satisfy a compliance review.
Enterprise greenfield build with a well-documented spec	Medium	Run systematic techniques first to cover the spec; use error guessing afterwards to target the gaps around concurrency, encoding, and session state that requirements never mention.
Small startup with limited tester headcount and frequent releases	High	Low overhead and no tooling required; a shared team fault list punches well above its weight when there is no time for full scripted suites between releases.
Brand-new domain where no team member has prior experience	Low	Guessing without domain knowledge targets the wrong failure modes; build domain understanding first via structured exploratory charters and developer conversations, then layer error guessing on top.

Advantage	Disadvantage	Use instead when…
Finds real bugs fast — experienced testers using a fault list routinely discover defects in minutes that scripted test suites miss entirely	Coverage is invisible — there is no systematic way to prove what you have and haven’t checked; auditors cannot accept "my gut says we’re covered"	You need auditable, repeatable coverage (NZ Privacy Act review, ISO 25010 assessment, health system certification)
Scales with time pressure — a two-minute triage pass with a fault list beats an incomplete scripted suite when the sprint deadline is in an hour	Quality depends on the tester — a weak or unfocused fault list produces weak guesses; the technique transfers poorly without explicit knowledge sharing	The team lacks domain experience and guesses blind — use structured exploratory testing charters instead to build domain knowledge first
Targets the gaps specs ignore — encoding, concurrency, and session-state bugs rarely appear in requirements documents but appear constantly in fault lists	Misses boundary correctness — without equivalence partitioning and BVA first, you can have a rich fault list and still leave the specified input ranges untested	The feature has well-defined input/output rules (e.g. tax bracket thresholds, loan repayment calculations) — lead with BVA and decision tables
Cheap to start — no tooling or long setup needed; open a session note, pull out the fault list, and start	Hard to reproduce and maintain — guesses run ad hoc are not easily turned into regression tests unless the tester explicitly writes them up	You are building a long-term regression suite that other testers will maintain — write structured test cases from defect data instead
Compounds across a career — each new defect you add to your fault list makes every future project better; it is a genuinely appreciating asset	Skews toward familiar failure types — informal fault lists over-represent Logic and Data defects and chronically under-represent Timing and Environment categories	You are testing distributed or async systems where timing failures dominate — combine with a formal defect taxonomy and dedicated performance/load testing

Error Guessing

1 The Hook

2 The Rule

3 The Analogy

What it is

Building a fault list

Common failure areas by domain

Using a defect taxonomy

ISTQB mapping

NZ example — NZ-specific edge cases

4 Industry Reality

5 When to Use It — and When Not To

✓ Use it when

✗ Skip it when

Context guide

Trade-offs

6 Best Practices

7 Common Misconceptions

8 Now You Try