Error Guessing
Anticipate errors based on experience and attack them systematically. Fault lists and heuristics turn intuition into testable hypotheses.
1 The Hook — Why This Matters
A Christchurch online retailer ran a promotion: spend $50 and get free shipping. The test team applied equivalence partitioning and boundary value analysis. They verified that $49.99 charged shipping and $50.00 made it free. Every scripted test passed.
On launch day, customers discovered that applying a 10% student discount before the shipping check caused the system to evaluate the post-discount total ($45.00) against the $50 threshold. Hundreds of orders shipped free that shouldn't have. The formal techniques never caught it because "overlapping discount logic" wasn't in the specification.
An experienced tester would have guessed that discount in five minutes. Error guessing turns experience into test cases.
2 The Rule — The One-Sentence Version
Anticipate errors based on experience and attack them systematically.
Error guessing is not random clicking. It is the deliberate use of experience to build a list of likely failures — called a fault attack — and then designing specific tests to expose each one. The more systems you test, the better your guesses become.
3 The Analogy — Think Of It Like...
A Wellington plumber called to a leaky apartment building.
She doesn't test every pipe in the building. She knows from twenty years of experience that flats built in the 1990s with copper-to-galvanised junctions fail at the join. She tests those first. She still runs the formal pressure test, but she starts with the likely culprits because history says that's where the leaks live. Error guessing is the same: you run the systematic tests, but you also hit the known weak spots hard.
4 Watch Me Do It — Step by Step
Here is a real NZ example using an e-commerce discount feature. Follow these steps to turn experience into testable fault attacks.
Scenario: An online store offers free shipping on orders of $50.00 or more. A 10% student discount can also be applied. The system should evaluate the shipping threshold on the post-discount total.
- Understand the feature and its boundaries Read the specification, then ask: "Where have I seen this break before?" Discounts, thresholds, and rounding are common failure zones.
- Build a fault attack list using categories Use the six fault attack categories to guide your guesses: Input, Output, Logic, Computation, Interface, and Data.
- Form a specific, testable guess for each category Don't guess "discounts might break." Guess "overlapping discounts may cause the shipping threshold to be evaluated on the pre-discount total." Specific guesses become specific tests.
- Design the test and state the expected result Every guess needs a concrete input and a clear pass/fail criterion. If you can't write it down, it isn't a guess — it's a hope.
- Execute, document, and apply neighbourhood testing When a guess finds a bug, test the same failure pattern across every related field, form, and workflow. One good guess should multiply.
| Fault category | Specific guess | Test input | Expected result |
|---|---|---|---|
| Logic | Boundary at minimum threshold | Cart = $49.99, then $50.00 | No discount / Free shipping |
| Logic | Overlapping discounts | 10% student discount on $50 cart | Shipping evaluated on $45.00 post-discount total |
| Computation | Decimal precision | $33.33 × 3 items = $99.99 | System handles rounding vs $100.00 correctly |
| Data | Negative cart total | Return items so cart = −$10.00 | System rejects negative value gracefully |
| Input | Developer forgot to trim whitespace | Enter coupon code " SAVE10 " with spaces | Coupon applied after trimming |
| Interface | Price change mid-checkout | Admin changes item price while user is on payment page | Cart reflects correct locked price |
5 The Decision Tool — When to Use It
✅ Use error guessing when...
- You have prior experience with similar applications or domains
- You are supplementing systematic techniques (EP, BVA, use cases)
- You need to find bugs that specifications don't cover
- You have limited time and need to target high-risk areas first
- You are building or using a fault list / defect taxonomy
- You suspect common developer mistakes (null handling, off-by-one, copy-paste)
❌ Don't rely on it alone when...
- You are replacing structured test design entirely
- You are new to testing and have no experience base to draw from
- Regulatory or safety requirements demand complete coverage
- You need traceability back to documented requirements
- The system is novel — no historical failure patterns exist
- You haven't documented your guesses as test cases
Before you rely on error guessing, ask:
- Do you have domain experience or a track record of similar defects?
- Are you using guessing to supplement formal techniques, not replace them?
- Can you document why you think a particular error is likely to occur?
6 Common Mistakes — Don't Do This
🚫 Replacing formal testing entirely
I used to think: Error guessing found so many bugs that I didn't need systematic techniques.
Actually: Error guessing finds what specs miss, but it doesn't verify that the system meets requirements. Equivalence partitioning and boundary value analysis prove the system does what was asked. You need both. Guessing without structure is gambling.
🚫 Treating guessing as "random clicking"
I used to think: Error guessing meant clicking around until something broke.
Actually: Random clicking is ad-hoc testing. It finds bugs by accident. Error guessing is deliberate: you identify a specific failure mode based on experience, design a test to trigger it, and document what you found. The test is targeted, not random.
🚫 Stopping after the first bug
I used to think: I found one bug with my guess, so that area was done.
Actually: Finding one bug is evidence that the area is fragile, not that it's clean. Fragile code tends to cluster. If overlapping discounts break shipping, what about loyalty points? Gift vouchers? One good guess should multiply into several related tests.
When error guessing fails
Guessing without systematic backing (EP, BVA, use cases) becomes time-wasting instead of testing. You test hunches instead of requirements. Also, if you don't have domain experience, your guesses are just random clicking, which is neither repeatable nor defensible for audit trails.
7 Now You Try — Login Form Fault Attack
Scenario: You are testing a login form. The specification says: "User enters email and password. System validates credentials and logs the user in."
Your task: Using the six fault attack categories (Input, Output, Logic, Computation, Interface, Data), list at least four specific guesses and the test you would run for each.
Model fault attack list:
| Category | Guess | Test input |
|---|---|---|
| Input | Developer forgot to trim whitespace | " john.doe " with correct password |
| Input | SQL injection vulnerability | Email: ' OR '1'='1 |
| Input | XSS payload in email field | Email: <script>alert('xss')</script> |
| Logic | Rapid double-submit | Click Login 10 times in 1 second |
| Data | Case sensitivity mismatch | Register with "User@Email.com", login with "user@email.com" |
| Interface | Browser autofill conflict | Let browser autofill, then edit password field |
Tip: None of these guesses require a specification. They come from knowing how login forms are built, how databases handle strings, and how browsers manage events. Each guess is a specific, testable hypothesis.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. What is a fault attack?
A fault attack is a structured approach where you create a list of possible errors based on experience, and then design specific tests to expose them. It turns general intuition into targeted, repeatable test cases with clear pass/fail criteria.
Q2. Why should error guessing supplement, not replace, systematic techniques like EP and BVA?
Systematic techniques guarantee coverage of the specification — they answer "Does the system do what was asked?" Error guessing targets gaps between specifications — it answers "What did nobody think to ask?" Using both together gives you verified requirements coverage AND protection against real-world failure modes that requirements miss.
Q3. You find a bug: a search field crashes when you paste an emoji. What is the most valuable next step in error guessing?
Apply neighbourhood testing — test every other text field in the application with emoji input. If one field mishandles Unicode, others probably do too. Also test related Unicode edge cases: right-to-left text, zero-width spaces, and combined characters. One good guess should multiply across the system.
9 Interview Prep — Know These Cold
These are questions Kiwi employers actually ask junior testers. Have an answer ready.
Q1. What is a fault attack?
A fault attack is a structured approach where you create a list of possible errors based on experience and design tests to expose them. It is the formalisation of error guessing: instead of vague intuition, you write down specific failure modes and test each one systematically.
Q2. When is error guessing most effective?
Error guessing is most effective when you have domain experience, when specifications are incomplete or silent on edge cases, and when you are supplementing — not replacing — systematic techniques. It is also highly effective in time-constrained situations where you need to target the highest-risk areas first.
Q3. How does the SFDPOT heuristic help with error guessing?
SFDPOT provides six lenses for generating guesses: Structure (files, APIs), Function (features, calculations), Data (nulls, special characters), Platform (OS, browser), Operations (user misuse), and Time (timeouts, concurrency). It ensures you don't just test input fields.
Q4. Can a junior tester use error guessing effectively?
Yes. Juniors can build fault lists from day one using common patterns: empty input, spaces, special characters, very long strings, zero, negative numbers, and rapid clicks. These break systems regardless of domain. Every bug found adds to the personal catalogue.
10 Link to Reference
Want the full theory, ISTQB syllabus mapping, and the complete NZ-specific fault list?
→ Error Guessing — Full Library Reference
Includes the formal ISTQB definition, the full SFDPOT heuristic guide, and a reusable fault attack template for any application.
11 Next Step
You now know how to turn experience into targeted fault attacks. The next skill is exploratory testing: simultaneous design, execution, and learning in a disciplined session.