Error Guessing

Error Guessing Skill

Overview

Error Guessing is an experience-based test design technique defined in ISTQB Foundation Level Syllabus where testers use their knowledge, intuition, and experience to anticipate where defects are likely to occur — then design test cases specifically targeting those areas.

Unlike black-box techniques (EP, BVA, Decision Table, State Transition), Error Guessing has no formal derivation procedure. Its effectiveness depends on the tester's ability to reason about:

• Common programming mistakes and error-prone constructs.
• Historical defect patterns in the system or similar systems.
• Boundary and special-value behavior beyond formal BVA.
• Interactions between components, configurations, and data states that create unexpected behavior.

Core purpose: Supplement systematic techniques by targeting the gaps they leave — the "middle of the valid class" defects, integration edge cases, data combinations, and implementation-specific failure modes that rules-based techniques cannot reliably surface.

ISTQB classification: Experience-Based Test Design Technique. Also known in practice as Fault Attack — a structured variant where guesses are organized into lists or taxonomies rather than applied ad hoc.

→ For full theoretical background, see resources/theory.md.

Invoke Syntax

/error-guessing [--file="path/to/output.md"]

Modes:

Notes:

• --file mode requires a file-capable environment (e.g., claude.ai with computer tools enabled). If file tools are unavailable, AI will notify the user and fall back to conversation output.
• The path in --file is the desired output location. If the file already exists, AI will ask before overwriting.
• Both modes produce identical content — only the delivery differs.
• --file can be combined with any input: /error-guessing --file="path/to/output.md" then paste the requirements.

When to Use

• After systematic techniques have been applied — Error Guessing supplements, never replaces, black-box techniques.
• When a tester has domain knowledge, system knowledge, or historical defect data about the area under test.
• When reviewing an existing test suite for gaps — "what has the systematic approach missed?".
• When time permits additional high-value test cases beyond the formal coverage baseline.
• When the feature involves: boundary conditions not covered by formal BVA, complex data interactions, third-party integrations, concurrency, configuration-dependent behavior, or known defect-prone constructs.
• When defect data from similar past projects suggests specific failure patterns.
• During exploratory testing sessions to guide investigation.

When NOT to Use

• Instead of systematic techniques — Error Guessing cannot replace EP, BVA, Decision Table, or State Transition Testing as the primary technique; it has no coverage guarantee.
• When the tester has no relevant experience or domain knowledge about the area under test — uninformed guessing adds noise without value.
• As the sole basis for test coverage reporting — Error Guessing produces no formal coverage metric; it cannot be cited as a coverage criterion.
• When requirements are unclear — clarify requirements first; guessing on top of ambiguous specs produces test cases that cannot be evaluated.

Inputs Required

Before applying this skill, you must have:

1. Completed systematic test suite — the existing test cases from black-box techniques; Error Guessing identifies what they missed.
2. Feature/component description — FR, BR, user stories, or API spec being tested.
3. Tester's domain knowledge — experience with the technology stack, business domain, or similar systems.
4. Historical defect data (when available) — past bugs in this system or similar systems; defect taxonomies.
5. Risk information (when available) — which areas are highest risk, most complex, or most recently changed.
6. Error taxonomy reference — resources/error-taxonomy.md — structured catalog of common error categories to guide systematic guessing.

Core Principles

1. Supplement, never replace: Error Guessing adds value only when systematic techniques have already been applied. It fills gaps — it is not a starting point.
2. Guesses must be justified: A good error guess is not random — it is based on a specific rationale: known defect pattern, implementation risk, historical data, or heuristic reasoning. Unjustified guesses waste effort.
3. Structure the guessing: Apply the Fault Attack approach — organize guesses into categories (input faults, boundary faults, computation faults, etc.) using an error taxonomy. Structured guessing finds more defects than unstructured intuition.
4. Each guess → one test case: Every error hypothesis must be translated into a specific, executable test case with defined input, expected result, and rationale.
5. Document the rationale: Record why each test case was added — what defect is being targeted and why it is suspected. This enables test suite maintenance and defect root cause analysis.
6. Prioritize by risk: When time is limited, order error guesses by defect probability × impact. Test the most likely and most damaging failures first.

Design Process

Follow these steps sequentially. Do not skip any steps.

Step 1 — Review the Existing Test Suite

Examine the test cases already produced by systematic techniques. Identify:

• Which equivalence classes and boundaries are already covered.
• Which conditions, combinations, and paths have been exercised.
• Which areas of the specification received less attention (complex logic, implicit behavior, integration points).

This prevents duplicating existing coverage and focuses Error Guessing where it adds new value.

Step 2 — Gather Error Guessing Inputs

Collect all available information that informs error guessing:

Domain knowledge sources:

• Personal experience with similar systems, technology stacks, or business domains
• Team knowledge (developers, architects, business analysts) about implementation risks
• Code review findings or known technical debt

Historical defect data:

• Past bug reports for this system (look for recurring defect patterns)
• Defect data from similar past projects
• Industry defect taxonomies relevant to the technology (web, API, mobile, embedded)

Risk information:

• Recently changed or newly developed components (higher defect density)
• Complex algorithms or business logic
• Third-party integrations and external dependencies
• Concurrency, multi-threading, or race condition risks
• Configuration-dependent behavior

→ Use resources/error-taxonomy.md as a structured checklist to ensure all major error categories are considered.

Step 3 — Generate the Error / Fault List

Produce a structured list of error hypotheses — specific defect scenarios the tester suspects may exist.

For each hypothesis, document:

• Category: Which error category it belongs to (input, boundary, computation, state, integration, etc.)
• Hypothesis: What specific defect might exist and where
• Rationale: Why this defect is suspected (experience, historical data, known risk)
• Risk: Probability × impact estimate (High / Medium / Low)

Structured approach (Fault Attack): Work through each category in resources/error-taxonomy.md systematically. For each category, ask: "Does this apply to the feature under test? What specific failures could occur here?"

→ See resources/fault-attack-guide.md for the structured Fault Attack procedure.

Step 4 — Prioritize the Error List

Rank error hypotheses by: Risk = Defect Probability × Defect Impact

When time is constrained, design test cases for High priority first, then Medium. Document Low priority items as acknowledged risks even if not tested.

Step 5 — Design Test Cases from Error Hypotheses

Translate each error hypothesis into one or more executable test cases:

• One hypothesis → one test case (or more if multiple specific values need to be tested for the same hypothesis)
• Input: Specific values chosen to trigger the suspected defect
• Expected result: What the system should do if the code is correct (not what the defect would produce)
• Rationale: The error hypothesis this test case is designed to expose
• Priority: From the risk ranking in Step 4

→ Use resources/output-template.md for the recommended format.

Step 6 — Review Against Quality Checklists

Before finalizing, verify the test suite against the Test Case Quality Checklist in resources/quality-checklist.md.

Anti-Patterns

→ Full detail: resources/anti-patterns.md

Critical anti-patterns:

• Using Error Guessing instead of systematic techniques — no coverage guarantee; systematic gaps become production defects
• Unjustified guesses — test cases added by "gut feel" with no documented rationale; cannot be evaluated, maintained, or defended
• Duplicating existing systematic coverage — adding error guessing test cases that test the same classes/boundaries already covered; wastes effort without adding value
• Random special value testing without taxonomy — testing null, 0, "" without reasoning about why these would expose a defect in this specific feature
• No prioritization — treating all error guesses as equal; when time runs out, highest-risk guesses may not have been tested
• Forgetting expected results — writing "input X" without specifying what correct behavior looks like; test case is not executable

Best Practices

→ Full detail: resources/best-practices.md

Key best practices:

• Always apply systematic techniques first; apply Error Guessing only to supplement.
• Use a structured error taxonomy (Fault Attack approach) rather than pure intuition — structured guessing finds more defects.
• Mine historical defect data: defects cluster; where bugs were found before, they are likely to be found again.
• Consult domain experts (developers, architects, business analysts) — their implementation knowledge is a high-value input.
• Document every test case rationale — "why do I suspect this?" is as important as "what am I testing?".
• Prioritize by risk: test the most likely and most damaging failure modes first.
• Revisit and update the error list when requirements change or new defects are found.

Process Quality Checklist

Use this to verify the Error Guessing process was applied correctly — before reviewing individual test cases.

• Systematic techniques (EP/BVA, Decision Table, State Transition, etc.) were applied first; Error Guessing is supplementing, not replacing them.
• The existing test suite was reviewed before generating error hypotheses (no duplicate coverage).
• Error taxonomy was used as a structured checklist — all major categories considered, not just intuition.
• Historical defect data was consulted where available.
• Domain experts were consulted where their knowledge was relevant and accessible.
• Every error hypothesis has a documented rationale (not "gut feel" without basis).
• Error hypotheses were prioritized by risk (probability × impact) before test case design.
• High-priority hypotheses were addressed first.
• Each hypothesis was translated into at least one specific, executable test case.

→ For the full Process Quality Checklist should be verified, see resources/quality-checklist.md.

Common Rationalizations to Reject

• "I have years of experience — I don't need a taxonomy, I'll just guess" → Unstructured guessing misses entire categories of defects that a taxonomy would surface; experience and structure are complementary, not alternatives
• "We've already done EP and BVA — that's enough coverage" → Systematic techniques have known blind spots (middle-of-class defects, interaction faults, implementation-specific failures); Error Guessing targets exactly these gaps
• "I don't have time to document the rationale" → Without rationale, the test case cannot be evaluated (is it testing the right thing?), maintained (what does it cover?), or defended (why is this test here?); rationale is not optional
• "We didn't find any defects with error guessing — it wasn't worth it" → Absence of findings does not mean the technique failed; it increases confidence that the suspected failure modes are not present; this is valid quality evidence
• "That edge case is too unlikely — no one would do that" → Users, integrations, and automated systems routinely produce inputs that "no one would do"; attackers deliberately craft them; error guessing explicitly targets the unlikely

Red Flags

Stop and re-evaluate if you observe:

• Error Guessing test cases overlap entirely with the existing systematic test suite — the gap analysis in Step 1 was not performed.
• Every error guess is in the same category (e.g., all boundary-related) — the taxonomy was not used; entire categories of failures are unaddressed.
• No test case has a documented rationale — the "guesses" are arbitrary; the test suite cannot be maintained or evaluated.
• Error Guessing is being used as the primary test design technique for a feature — systematic techniques were skipped.
• Expected results are missing or vague ("system should work", "no error") — test cases are not evaluable.

Output

The design process produces:

1. Error / Fault List — structured list of error hypotheses with category, rationale, and risk priority, organized by error category
2. Test Case Suite — supplementary test cases derived from high and medium priority hypotheses, using the template in resources/output-template.md

Examples

→ examples/user-registration-api.md — Error Guessing applied to a REST API user registration endpoint: demonstrates taxonomy-driven fault attack, historical defect mining, prioritization, and full test case suite with rationale