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:

Mode	Syntax	Behavior
Default (conversation)	/error-guessing	All analysis and test cases printed inline in the conversation as Markdown
File output	/error-guessing --file="path/to/output.md"	All output (Error/Fault List, Test Case Suite) written to the specified file. AI confirms path before writing.

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

Priority	Criteria
High	Likely to occur AND high impact if missed in production
Medium	Moderately likely OR moderate impact
Low	Unlikely OR low 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