Error guessing is a test design technique where testers actively test values and operations that are likely to trigger bugs, based on past experience, known bug patterns, and professional intuition. Because it complements other techniques by catching what they miss, it’s the technique where a QA engineer’s hands-on experience directly translates into software quality.
💡 In one sentence
Error guessing = “Converting ‘this feels risky’ — experience and intuition — directly into test cases”
Error guessing is the only test design technique built on experience, intuition, and gut feeling. By supplementing systematic techniques with “empirically risky values,” it raises the overall quality of your entire test suite by one full level.
📌 Who This Article Is For
- QA engineers who want to learn the concept and practical application of error guessing
- Anyone who feels equivalence partitioning and boundary value analysis alone aren’t enough
- Those looking for the finishing touch to complete the test design techniques series
- Engineers who want to systematically channel their experience and instincts into testing
✅ What You’ll Learn
- The concept behind error guessing and how it differs from other techniques
- A practical catalog of bug-prone value patterns used in production QA
- A workflow for combining error guessing with other test design techniques
👤 About the Author
Written by Yoshi, a QA and test automation engineer with 15+ years of hands-on experience. Error guessing is used daily as a complement to other techniques — and the more experience you accumulate, the more accurate it becomes. Code is publicly available on GitHub: github.com/YOSHITSUGU728/automated-testing-portfolio
Equivalence partitioning, boundary value analysis, decision tables, state transition testing — even applying all of these, some bugs still slip through. Why?
- Systematic techniques derive test cases from conditions written in the spec
- But pitfalls not written in the spec are hard to find with systematic techniques alone
- Experience-driven questions like “what happens with NULL?” or “what about whitespace-only input?” are critical
Error guessing converts these experience-driven questions into test cases. This article covers the concept, a practical bug pattern catalog, and how to combine error guessing with other techniques.
📌 Key Takeaways
- A test design technique that adds test cases based on experience, intuition, and known bug patterns
- Used as the finishing layer on top of the other six techniques (equivalence partitioning, boundary value, decision tables, etc.)
- Checklist-driven error guessing lets less experienced team members benefit too — not just senior QAs
What Is Error Guessing?
Error guessing is a test design technique that predicts values and operations likely to cause bugs — based on past experience, known bug patterns, and intuition — then adds those as test cases.
ISTQB defines it as “a technique based on the tester’s experience, intuition, and heuristics.” Where other techniques logically derive test cases from spec conditions, error guessing starts from an experiential sense of “this feels risky”.
| Aspect | Systematic Techniques (EP, BVA, etc.) | Error Guessing |
|---|---|---|
| Starting point | Spec conditions and requirements | Experience, intuition, past bug patterns |
| Coverage | Logically provable coverage | No coverage guarantee (supplementary) |
| Reproducibility | Same result regardless of who runs it | More accurate with more experience |
| Bugs found | Bugs from conditions in the spec | Off-spec pitfalls and implementation quirks |
Error Guessing in Practice: A Bug-Prone Value Catalog
Here’s a curated catalog of bug-prone value and operation patterns from 15+ years of production QA experience, organized by category. Use this as a checklist to make error guessing accessible to less experienced team members too.
① Numeric Bug Patterns
| Value | Why It’s Risky | Common Bug Example |
|---|---|---|
| 0 | Division by zero · boundary of conditional logic | ZeroDivisionError · discount calculation results in $0 |
| -1 / Negative numbers | Becomes a huge number in unsigned integer types | Entering -1 for stock count yields 4,294,967,295 |
| Max value + 1 | Integer overflow | 2,147,483,647 + 1 wraps to -2,147,483,648 in int32 |
| Decimals / Floating point | Floating point rounding errors | 0.1 + 0.2 = 0.30000000000000004 |
② String Bug Patterns
| Value | Why It’s Risky | Common Bug Example |
|---|---|---|
| Empty string (“”) | Confused with NULL · missing length check | Empty string saved to DB · name field accepts blank submission |
| Whitespace only (” “) | Treated differently from empty string | Judged as “has input” and passes validation |
| Very long string (1000+ chars) | Buffer overflow · DB column constraint exceeded | 1000 chars entered in a 500-char field with no error |
| Mixed multi-byte / single-byte | Character encoding / length calculation drift | String appears to be 2 chars but is 4 bytes |
| Newline / Tab characters | Corrupted CSV output · display misalignment | String with newline exported to CSV breaks row alignment |
③ Security Bug Patterns
| Value | Why It’s Risky | What to Check |
|---|---|---|
' OR '1'='1 | SQL injection | Can authentication be bypassed via the login form? |
<script>alert(1)</script> | XSS (Cross-site scripting) | Is user input rendered directly as HTML? |
../../../etc/passwd | Path traversal | Can a filename input traverse up the directory tree? |
④ NULL / Undefined Bug Patterns
| Value | Why It’s Risky | Common Bug Example |
|---|---|---|
| NULL / None | NullPointerException · unexpected behavior | NULL in optional field causes sort to crash |
| Unselected state | Default value handling is incomplete | Submitting a form without selecting a dropdown throws an error |
| Empty array / Empty list | Zero-item edge case missed in loop logic | Pagination crashes when search returns 0 results |
⑤ Date / Time Bug Patterns
| Value | Why It’s Risky | Common Bug Example |
|---|---|---|
| February 29 (leap year) | Leap year logic not accounted for | “1 year later” crashes because Feb 29 doesn’t exist next year |
| Last day of month (28/29/30/31) | Month length varies | “1 month later” becomes a date that doesn’t exist in the next month |
| Timezone boundary | UTC conversion drift | An 11pm booking in local time becomes the previous day in UTC |
| Year boundary (Dec 31 → Jan 1) | Year-crossing calculations missed | Weekly report shows only Dec 31 instead of Dec 31–Jan 6 |
Error Guessing Checklist: 10 Questions to Ask Before You Ship
After completing your test design, run through this checklist. Any “not tested yet” answer is a test case waiting to be written.
✅ Error Guessing Checklist
| 1 | What happens when you enter 0, a negative number, or max value + 1 in a numeric field? |
| 2 | What happens with empty string, whitespace only, or 1000+ characters in a text field? |
| 3 | What happens when a required field is submitted as NULL, empty, or unselected? |
| 4 | What happens when the same action is triggered twice in rapid succession? (double submit) |
| 5 | What happens with February 29, last day of month, or year boundary in a date field? |
| 6 | What happens when you enter a single quote, <script> tag, or SQL comment in a text field? |
| 7 | What happens to pagination and sorting when a list or search returns 0 results? |
| 8 | What happens when you upload an empty file, an extremely large file, or an invalid extension? |
| 9 | What happens when a network disconnect, timeout, or server error occurs mid-operation? |
| 10 | What happens with the browser back button, direct URL entry, or bookmark access? |
Closing the Series: Where Error Guessing Fits
As the final article in the 7 test design techniques series, here’s how each technique fits together.
| Technique | Role | When to Apply |
|---|---|---|
| Equivalence Partitioning | Group input value ranges | Always first |
| Boundary Value Analysis | Focus tests on group boundaries | Immediately after EP |
| Decision Table Testing | Organize multi-condition combinations | For business logic |
| State Transition Testing | Verify states and transitions | For stateful systems |
| Use Case Testing | Verify end-to-end user operation flows | For E2E test design |
| Pairwise Testing | Optimize large parameter combinations | For config/env combinations |
| Error Guessing ← you are here | Add empirically risky values | Last — after all other techniques |
🎯 Production Workflow
① Design baseline test cases with equivalence partitioning and boundary value analysis
② Apply decision tables to business logic
③ Reinforce flow-based systems with use case testing and state transition testing
④ Optimize large parameter sets with pairwise testing
⑤ Finally, run through the error guessing checklist and add any empirically risky values
⚠️ 4 Common Pitfalls in Error Guessing
Here are the mistakes that are easy to make when applying error guessing in practice.
① Using error guessing alone and skipping systematic techniques
“I have enough experience — I don’t need equivalence partitioning.” This is dangerous. Error guessing is a supplementary technique; used alone it provides no coverage guarantee. Always build the baseline with systematic techniques, then apply error guessing as the finishing layer.
② Over-relying on a single experienced team member
“Only the senior engineer can catch these bugs” is a team-level risk. Converting error guessing patterns into a shared checklist and documenting them means less experienced members can benefit too. Turn “one person’s instinct” into “the team’s asset.”
③ Skipping security-related error guessing because “that’s a security team job”
Basic patterns like SQL injection (single quotes) and XSS (<script> tags) are different from specialized penetration testing — they belong in everyday QA testing. Don’t wait for a security team to find these. QA engineers should have these in their standard checklist.
④ Adding test cases by gut feel without recording the rationale
Without a comment explaining why a particular value was tested, future team members may delete the case as unnecessary. Leave a one-line rationale: “Added because whitespace-only input has historically passed validation in similar systems.” This preserves the intent and prevents regression.
FAQ
Q. Can error guessing be used by less experienced team members?
Yes. The bug pattern catalog and checklist in this article make error guessing accessible to anyone — not just seasoned QAs. Start by using the catalog as-is, and add to your team’s version every time a new bug is found. The checklist gets more accurate over time.
Q. What’s the difference between error guessing and ad hoc testing?
Ad hoc testing is unplanned testing that goes wherever the tester’s attention leads. Error guessing designs test cases based on past experience and known bug patterns — it has intent and a purpose behind each case. Error guessing is more reproducible, more shareable, and more valuable to the team because it can be turned into a checklist.
Q. How is error guessing covered in ISTQB?
ISTQB Foundation Level covers “the definition of error guessing, how it differs from other techniques, and its nature as an experience/intuition/heuristics-based technique.” Understanding that “error guessing is a supplementary technique used in combination with others” is sufficient for the exam.
Q. How should a team grow its bug pattern catalog over time?
The most effective approach is “add to the catalog every time a bug is found.” In post-mortems, ask “could this bug have been caught with error guessing?” If not, add it. Managing the catalog in GitHub or a team wiki (like Confluence or Notion) makes it easy to maintain and share.
📖 Related Articles (Test Design Techniques Series)
In production, the workflow I follow is to run through this checklist once after completing test design. From 15+ years of experience, “running through this checklist consistently surfaces 1–2 additional bugs every single time.” Whitespace-only input, double-submit, and month-end date calculations have been recurring finds across many different projects.
📋 Summary
- Error guessing is a test design technique that converts experience, intuition, and known bug patterns into test cases
- Used as the finishing layer on top of the other six techniques — supplementing systematic approaches with empirically risky values
- A bug pattern catalog and checklist makes error guessing usable by the whole team, not just senior engineers
- The core value is turning “one person’s instinct” into a team asset
- All seven test design techniques are meant to be used together — error guessing is the final piece
Through this test design techniques series — from equivalence partitioning and boundary value analysis, through decision tables, state transition testing, use case testing, and pairwise testing, to error guessing as the finishing touch — you now have the full toolkit for building strong, systematic test design. Apply these techniques on real projects, and grow your own bug pattern catalog along the way.
