TEST DESIGN
Decision Table Testing.
Black-Box A black-box technique for testing systems whose output depends on combinations of input conditions — making every rule explicit in a table so no combination is missed or contradicted.
What it is
Decision Table Testing (also called Cause-Effect Table Testing) models complex business logic as a table of conditions and actions. Each column in the table is a rule: a specific combination of condition values that produces a particular action or output. The technique is most valuable when the system behaviour depends on MULTIPLE conditions simultaneously — discount eligibility, loan approval, access control policies, shipping cost rules. A decision table makes ALL rule combinations explicit, forces you to identify what happens in every combination (including unspecified ones), and catches contradictory rules (two columns with the same conditions but different actions). The Decision Table Generator utility builds and manages these tables automatically.
When to use it
When to use
- Business rules where output depends on combinations of 2 or more conditions (pricing rules, discount eligibility, access control policies, approval workflows)
- Logic with complex AND/OR condition combinations that are hard to reason about as plain text
- Verification that a specification covers ALL condition combinations — missing cells in the table reveal requirement gaps
- When contradictory rules need to be detected (two rules with identical conditions but different actions)
- Audit contexts where traceability between rules and test cases is required — each column maps 1:1 to a test case
When NOT to use
- Simple single-condition logic (if/else with one variable) — a decision table adds overhead with no benefit; use BVA or EP instead
- More than ~5 conditions — the table has 2^n columns for n binary conditions, making it unmanageable by hand (use the generator or switch to pairwise reduction)
- Sequential or state-dependent logic where the order of events matters — decision tables are stateless; use state-transition testing instead
How it works
For n binary conditions, a full decision table has 2^n rules (columns). Each rule specifies a Y/N value for every condition and the action that results. The worked example uses a 3-condition discount eligibility rule: member tier, order value, and active coupon — 8 rules fully cover the logic.
Discount eligibility — conditions: Member? (Y/N) × Order ≥ £50? (Y/N) × Active coupon? (Y/N)
| Rule | Member? | Order ≥ £50? | Active coupon? | Discount | Result |
|---|---|---|---|---|---|
| R1 | Y | Y | Y | 20% | Accept |
| R2 | Y | Y | N | 10% | Accept |
| R3 | Y | N | Y | 5% | Accept |
| R4 | Y | N | N | 0% | Reject |
| R5 | N | Y | Y | 10% | Accept |
| R6 | N | Y | N | 5% | Accept |
| R7 | N | N | Y | 0% | Reject |
| R8 | N | N | N | 0% | Reject |
⚠ 8 rules for 3 binary conditions (2³). Each rule becomes one test case. Verify R4 vs R7 vs R8 all correctly return 0% — these are the most likely places for rule-merging defects.
Step by step
List all conditions
Identify every independent input condition that affects the output. Keep conditions binary (Y/N, true/false) initially — multi-value conditions can be added after the binary table is complete.
Calculate the full rule count
For n binary conditions, the full table has 2^n rules. For 3 conditions: 8 rules. For 4 conditions: 16 rules. If n > 5, the table is too large to manage by hand — use the Decision Table Generator or apply rule-folding to collapse identical-action rules.
Fill in every rule
Work through every Y/N combination systematically (treating them as binary 000→111). For each combination, specify the expected action. Use '—' (don't care) for conditions that don't affect the action in that combination.
Check for missing and contradictory rules
Scan for: (1) cells with no specified action — these are requirement gaps; (2) two columns with identical conditions but different actions — these are contradictions. Flag both back to the requirements owner before building tests.
Convert each rule to a test case
Each column is one test case. Set up the conditions exactly as the column specifies, execute the scenario, and assert the action (output, API response, or system state) matches the column's action row.
Verify don't-care rules with at least one representative
If two rules are collapsed using a don't-care ('—') condition, test at least one value of the don't-care condition to confirm the action is truly independent of it.
Pitfalls & what it misses
Missing the 'default' or 'else' rule
Business logic almost always has a default action for combinations not explicitly addressed. If the table doesn't include a rule for every combination, the system's actual default behaviour (which may be a silent failure) is never tested.
Collapsing rules too aggressively with don't-cares
Using '—' (don't care) for a condition when the condition actually matters in some sub-case silently removes test coverage. Only use don't-care after verifying that the action truly does not depend on the condition's value.
Applying decision tables to sequential/stateful logic
Decision tables assume conditions are evaluated simultaneously and the system is stateless. If condition B is only reachable after condition A was true in a previous step, a decision table won't model the sequence correctly — that's a state-transition testing problem.
Treating decision table testing as a substitute for BVA
A decision table specifies WHAT action follows from a combination of conditions. It does not test the BOUNDARIES of those conditions. 'Order ≥ £50' in the condition should still be tested at £49.99, £50.00, and £50.01 with BVA.
Paired utility
// Related resources