Learning Objectives
By the end of this lesson you will be able to:
- Define error guessing and distinguish it from ad-hoc testing
- Describe the role of bug taxonomies in making error guessing systematic
- Explain why error guessing complements specification-based techniques
What Error Guessing Is
Error guessing is a test design technique where the tester uses their knowledge of past defects, system behavior, and common developer mistakes to hypothesize where bugs are likely to be — and then design tests specifically targeting those hypotheses.
It is not random clicking. It is not "testing whatever feels interesting." Done well, it is one of the most efficient bug-finding strategies in a tester's toolkit: experienced testers can find more bugs in an hour of structured error guessing than in a day of scripted test execution.
Why It Works
Bugs are not random. They cluster. The same types of mistakes appear repeatedly across different teams, languages, and systems:
- Input validation is almost always incomplete (some edge case slips through)
- Off-by-one errors appear in loops, ranges, and counters
- Logical operators get flipped (AND/OR confusion)
- Boundary conditions for floating-point numbers are mishandled
- Empty strings and null values are not treated differently
- State transitions are assumed rather than enforced
A tester who has catalogued these patterns — through personal experience, defect databases, or published bug taxonomies — can walk up to any new system and immediately know where to probe.
Bug Taxonomies
A bug taxonomy is a structured classification of common defect types. Examples relevant to logic testing:
| Category | Common Instances |
|---|---|
| Operator errors | Wrong logical operator (&&/||), wrong comparison (</>/<=/>=) |
| Off-by-one | Range starts at 1 instead of 0, "less than" instead of "less than or equal" |
| Null/empty handling | null ≠ empty string ≠ whitespace, each treated differently |
| Type coercion | "0" is falsy in JS, "false" is truthy in PHP |
| State assumption | Assuming an object is in a certain state without checking |
| Missing cases | Forgetting to handle the "else" or the "final else" of an if-else chain |
Your personal checklist should be organized by these categories.
Making It Systematic
The difference between amateur and professional error guessing:
Amateur: "I'll try some weird inputs and see what happens."
Professional: "Based on the type of logic I see in this form, the highest-risk categories are: input validation boundaries, empty/null handling, and operator confusion. I'll design three test cases per category."
The professional approach is documented, repeatable, and defensible. You can explain why you chose each test — and when you find a bug, you can trace it to the category that predicted it.
Pro Tip: Keep a personal defect journal. Every bug you find in your career should be recorded: what type was it, what triggered it, what technique caught it? After 50 entries, patterns emerge that make you dramatically more effective.
Summary
Error guessing is experience translated into test cases. It is structured, not random, and it improves with practice and documentation. The next lesson catalogs the most common developer logic mistakes — giving you a taxonomy to start from, even before you've personally encountered them.