Decision Table Testing

Decision Table Testing Skill

Overview

Decision Table Testing is a black-box test design technique for specifying and testing complex business logic where multiple conditions interact to determine system behavior. It uses a tabular structure to systematically enumerate all meaningful combinations of conditions and map each to its expected set of actions (outcomes).

Core purpose: Guarantee that no meaningful combination of conditions is left untested, while eliminating redundant test cases through structured reduction.

Two complementary goals:

• Completeness: Every logical rule (combination of condition values) that the system must handle is identified and covered.
• Efficiency: Redundant rules are merged; logically impossible rules are eliminated before test execution

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

Invoke Syntax

/decision-table-testing [--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: /decision-table-testing --file="path/to/output.md" then paste the requirements.

When to Use

• Requirements contain 2 or more conditions that interact to determine different system behaviors.
• Business rules with "if-then-else", "and/or" logic, or multiple overlapping constraints.
• Requirements where different combinations of inputs produce different outputs (not just one input → one output).
• Complex eligibility, pricing, discount, access control, or routing logic.
• When requirements analysis reveals implicit or contradictory conditions that need to be surfaced.
• Any situation where ad-hoc or intuition-based test case design risks leaving combinations untested.

Key signal: If you find yourself writing "If condition A and condition B then..." repeatedly while reading requirements — Decision Table Testing is the right technique.

When NOT to Use

• Only one condition controls behavior → use Domain Testing (EP/BVA) instead.
• Requirements describe a sequence of states and transitions → use State Transition Testing instead.
• Requirements describe a user workflow or end-to-end flow → use Use Case Testing instead.
• The number of conditions is very large (7+) and no reduction is feasible → consider Pairwise/Combinatorial Testing instead.
• Pure UI/UX testing, basic CRUD operations, or API payload structure testing with no conditional logic.
• Do not use Decision Table Testing alone as a complete test strategy — it does not cover boundary values within conditions (combine with Domain Testing for that).

Inputs Required

Before applying this skill, you must have:

1. Functional requirements or business rules (BR) describing conditions and expected outcomes.
2. All conditions (independent variables) that affect system behavior — both explicit and implied.
3. All actions (dependent outcomes) — both explicit and implied, including error/rejection cases.
4. (Optional but valuable) Confirmation from business/product owner on impossible combinations, boundary inclusivity, and any undocumented constraints.

Core Principles

1. Every condition must be explicitly represented: No condition affecting behavior may be omitted from the table — including implied and negative conditions.
2. Every meaningful rule must be covered: Before reduction, the full table must account for all possible combinations.
3. Impossible rules must be classified before acting: Distinguish Type 1 (impossibility proven by the spec itself — no confirmation needed) from Type 2 (impossibility inferred by the tester — stakeholder confirmation mandatory).
4. Don't Care conditions require proof: A condition is only "Don't Care" when the action is provably identical for all its values — not when it seems unlikely to matter.
5. One rule = one test case (after reduction): Each column in the reduced table maps to exactly one test case.
6. Actions must be fully specified per rule: Every action for every rule must be explicitly marked — omission is not the same as "does not apply".
7. Traceability is mandatory: Every rule and resulting test case must trace back to a specific requirement or BR.

Design Process

Follow these steps sequentially. Do not skip any steps.

Step 1 — Analyze Requirements and Identify Conditions and Actions

Parse all requirements, BRs, and user stories. Extract:

• Conditions: The independent variables that affect system behavior. Look for: "if", "when", "given", "provided that", boolean flags, status fields, membership types, numeric thresholds (after EP grouping).
• Actions: The dependent outcomes triggered by combinations of conditions. Look for: "then", "resulting in", "the system will", "display", "calculate", "reject", "grant access". Include ALL possible outcomes — both positive and negative (error states, rejections, no-action cases).

Critical tasks at this step:

• Identify implied conditions not explicitly stated (e.g., "VIPs get free shipping" implies a non-VIP condition with different behavior).
• Identify implied actions (e.g., "coupon cannot be used with new customer discount" implies the coupon is silently ignored, not rejected).
• Identify mutual exclusion constraints between conditions (flags on impossible combinations early).
• Clarify ambiguities with stakeholders before proceeding — ambiguous requirements produce wrong tables.

→ See resources/conditions-actions-guide.md for extraction patterns and examples.

Step 2 — Build the Full Decision Table

Construct the complete table before any reduction:

1. Choose table entry type:
   • Limited Entry: Condition values are binary only (T/F, Y/N, 0/1). Simplest form; total rules = 2ⁿ for n binary conditions.
   • Extended Entry: Condition values can be multi-valued (e.g., status = ACTIVE / INACTIVE / SUSPENDED). Total rules = product of all value counts per condition.
2. Calculate total number of rules: For n binary conditions → 2ⁿ rules. Fill condition rows with all possible combinations systematically (use binary counting pattern for limited entry).
3. Fill in actions per rule: For each rule (column), evaluate the requirement and mark every applicable action. Use consistent notation: X for "action applies"; blank for "action does not apply"; specify exact values for extended entry tables.
4. Mark impossible rules (do not remove yet — removal happens in Step 3).

→ See resources/table-construction.md for notation standards, entry types, and construction patterns.

Step 3 — Reduce and Optimize the Decision Table

Apply reduction to eliminate redundancy while preserving 100% logical coverage:

3a. Remove Impossible Rules

• Identify rules containing combinations that cannot occur in the real system (mutually exclusive conditions, physically impossible states).
• Classify each candidate impossible rule before acting:
  • Type 1 (Structurally impossible): Impossibility is directly proven by a specific BR or spec statement. Document the source BR. Remove without stakeholder confirmation — the spec is the proof.
  • Type 2 (Assumed impossible): Impossibility is inferred by the tester, not explicitly stated in the spec. Stakeholder confirmation is mandatory before removal — what appears impossible may occur via API bypass, admin override, data migration, or race conditions.
• Mark removed rules as IMPOSSIBLE with documented rationale (do not silently delete).

3b. Merge Rules via Don't Care Conditions

• Two rules can be merged if and only if:
  • They produce exactly the same set of actions
  • They differ in the value of exactly one condition
• The differing condition becomes a Don't Care (—) in the merged rule.
• Apply iteratively — a merged rule may be eligible for further merging.

3c. Verify Reduction Completeness

• After reduction, verify that the merged rules still cover all original rules they replaced.
• No valid rule from the full table should be unrepresented in the reduced table.

→ See resources/reduction-guide.md for detailed reduction procedures, worked examples, and common mistakes.

Step 4 — Derive Test Cases from the Reduced Table

Translate each remaining column (rule) in the reduced table into one test case:

• One rule = one test case (no exceptions)
• Conditions → Test inputs / preconditions / test data
• Actions → Expected results / assertions
• For Don't Care conditions: Choose the most revealing concrete value (typically the one most likely to expose a defect if the condition were to matter unexpectedly)
• For extended entry tables: The specific value in the cell is the test data

Assign each test case: ID, description, all input values (including Don't Care choices), expected outputs, and traceability to rule number and requirement.

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

Step 5 — Review Against Quality Checklists

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

Design Rules

Anti-Patterns

→ Full detail: resources/anti-patterns.md

Critical anti-patterns:

• Starting with the reduced table — skipping the full table means missing combinations before you know they're impossible or mergeable
• Conflating conditions with test data — conditions are categories of behavior, not raw input values (e.g., "amount > $100" is a condition class, not a test value)
• Marking Don't Care without verification — assuming a condition doesn't matter without proving all action sets are identical
• Applying the same confirmation rule to all impossible rules — Type 1 (proven by spec) needs no confirmation; Type 2 (inferred by tester) always does
• Missing implied conditions or implied actions — only listing what's explicitly written in the spec
• Treating mutually exclusive conditions as separate test cases — should be impossible rules, not additional test cases
• Using Decision Table for single-condition logic — overkill and misleading; use EP/BVA instead
• Leaving actions blank instead of explicitly "no action" — ambiguous blanks produce ambiguous test results

Best Practices

→ Full detail: resources/best-practices.md

Key best practices:

• Use EP to convert continuous range conditions into discrete classes before building the table (prevents infinite-column tables).
• Combine with BVA after the table is built — use boundary values as the specific test data for range-based conditions.
• Classify impossible rules before acting: Type 1 (proven by spec) → cite BR and remove; Type 2 (inferred by tester) → confirm with stakeholder first.
• For large tables (5+ conditions), build the table in sections grouped by dominant conditions.
• Document rationale for every Don't Care and every impossible rule.
• Surface specification gaps during table construction — incomplete specs produce incomplete tables; raise gaps before executing.
• In Agile: use Decision Table construction as a "Three Amigos" spec review tool (Product Owner + Dev + QA).

Process Quality Checklist

Use this to verify the design process was followed correctly — before reviewing individual test cases.

• All conditions have been identified — including implied conditions not explicitly stated in the spec.
• All actions have been identified — including "no discount", "reject", "error" cases and implied outcomes.
• Ambiguities in requirements were raised and resolved before table construction.
• The full (unoptimized) table was built before any reduction was applied.
• Total rule count matches the formula: 2ⁿ for n binary conditions (or product of value counts for extended entry).
• All actions are explicitly marked per rule — no ambiguous blanks.
• Impossible rules are classified as Type 1 (proven by spec) or Type 2 (inferred by tester).
• Type 1 impossible rules have their source BR cited as proof.
• Type 2 impossible rules have stakeholder confirmation documented (who, when, scope).
• Don't Care merges are verified: merged rules produce exactly the same action set and differ in exactly one condition.
• Reduction is complete: no further merges are possible in the reduced table.
• Every rule in the reduced table traces to one or more rules in the full table.
• Every test case traces to a specific rule in the reduced table and to a specific requirement or BR.

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

Common Rationalizations to Reject

• "That combination is obviously impossible — I don't need to document it" → Document and confirm; assumptions about impossibility are a frequent source of missed defects
• "I need to ask the PO about every impossible rule — even the ones already proven by the spec" → Type 1 impossible rules (proven directly by a BR) need no confirmation; asking for it wastes time and signals poor analytical judgment
• "I'll skip building the full table since I know most of it will be reduced anyway" → The full table is the proof of completeness; skipping it means you cannot verify what you've eliminated
• "The condition doesn't matter for this rule — I'll mark it Don't Care" → Only valid if you can prove the action set is identical for all values; prove it, don't assume it
• "These two test cases look similar, I'll merge them" → Merging requires formal Don't Care proof — "looking similar" is not sufficient
• "The spec doesn't mention what happens when both flags are false — I'll skip that rule" → Unspecified behavior is a spec gap, not a reason to skip; raise it, then design the test case based on the resolved answer
• "This table is too big — I'll just test the important combinations" → "Important" is subjective; use formal reduction instead of gut-feel selection

Red Flags

Stop and re-evaluate if you observe:

• The reduced table has the same number of rules as the full table (reduction likely wasn't applied or impossible rules weren't identified).
• A condition row in the table is always T or always F across all rules (condition may be redundant, or the spec is incomplete).
• A test case has no expected action at all (action row is entirely blank — the rule is either impossible and should be removed, or a required action is missing).
• More than 30% of rules are marked "Impossible" without stakeholder confirmation (likely a misunderstanding of the requirements).
• A Don't Care was applied to a condition that has 3+ possible values but only one was used to verify the merge.
• Two test cases in the final suite have identical input combinations (duplicate rules survived reduction).

Output

The design process produces:

1. Conditions and Actions List — all extracted conditions (with value options) and all actions, traced to requirements
2. Full Decision Table — complete unoptimized table before reduction
3. Reduced Decision Table — optimized table with impossible rules removed and Don't Care merges applied, with rationale column
4. Test Case Suite — using the template in resources/output-template.md

Examples

→ examples/discount-rules.md — Multi-condition discount system (limited entry, 3 binary conditions, impossible rules + Don't Care reduction)
→ examples/loan-eligibility.md — Loan eligibility assessment (extended entry, multi-valued conditions, complex action combinations)