Some features behave the same way regardless of context, and you can cover them with a handful of equivalence classes. Other features behave differently depending on the combination of several inputs. For those, the cleanest tool in the QA toolkit is the decision table. It forces every meaningful combination into rows and columns, surfaces missing rules, and makes the test cases fall out of the table directly.
When to reach for a decision table
You probably need a decision table when:
- Multiple boolean conditions interact (is the user logged in? is the cart non-empty? is the country EU?).
- The spec uses the word "and" or "or" between conditions (free shipping if order is over $50 and the user is a member).
- The behaviour is a yes/no, allow/deny, charge/refund question.
- The team keeps arguing in standup about edge cases.
If the answer to "what does the system do here?" cannot be summarised in one short sentence, a decision table will help.
A worked example: shipping rules
Imagine a shipping policy with three input conditions:
- Member? Yes / No
- Order over $50? Yes / No
- Domestic? Yes / No
And one outcome: shipping price (Free, $5, $10, $15).
That is 2 × 2 × 2 = 8 possible combinations. A decision table lays them out explicitly:
| Member? | Over $50? | Domestic? | Shipping |
|---|---|---|---|
| Y | Y | Y | Free |
| Y | Y | N | $5 |
| Y | N | Y | $5 |
| Y | N | N | $10 |
| N | Y | Y | $5 |
| N | Y | N | $10 |
| N | N | Y | $10 |
| N | N | N | $15 |
Each row is a test case. The table is now the single source of truth for the test plan and a great review artefact for the product team. They can look at any row and say "actually no, that should be $10, not $5" — and the test plan updates accordingly.
What the table forces you to confront
Pick the shipping price for each rule
Members get $5 off. Orders over $50 get $5 off. Domestic ships for $5 less than international. Defaults: domestic $15, international $20.
| Member? | Over $50? | Domestic? | Outcome |
|---|---|---|---|
| Yes | Yes | Yes | |
| Yes | No | Yes | |
| No | Yes | Yes | |
| No | No | No |
The act of building the table reveals problems before any test runs:
- Missing rules. "What's the shipping when the user is in Argentina (not domestic), the order is below $50, and they are a member?" Until the table exists, that case might never have been considered.
- Contradictions. Two parts of the spec say different things about the same combination.
- Redundant rules. Three conditions but only two of them actually matter for the outcome.
- Ambiguity. A condition that means different things in different rows.
When you bring a decision table to a refinement meeting, the spec gets tighter. It is one of the most efficient tools for making fuzzy requirements concrete.
Reducing rules to combat explosion
Every new boolean condition doubles the table. Five conditions = 32 rules. Eight = 256. At some point you have to prune.
Two common reductions:
- Don't-care entries. If "Member" does not affect shipping when the order is below $50 and the destination is international, mark "Member" as "—" in those rows and collapse them. The cost is a small loss of test specificity; the gain is a manageable table.
- Pairwise testing. Instead of every combination, test every pair of conditions at least once. For 8 conditions, full coverage requires 256 cases; pairwise needs about 12. Tools like Microsoft's PICT generate these automatically.
For most real-world features with 3-5 conditions, you will not need either reduction — the full table fits on one page and is worth doing exhaustively.
Decision tables vs other techniques
Decision tables shine where multiple inputs combine. They are weaker for:
- Continuous inputs. A field that accepts any number from 0 to 1 million is better tackled with equivalence partitioning and boundary value analysis.
- Sequential behaviour. When the order of actions matters (login → add to cart → checkout), state transition diagrams are clearer.
- Single-input rules. If only one input drives the behaviour, a table is overkill — a list of (input, output) pairs is plenty.
The right technique depends on the shape of the problem. Mature testers reach for whichever fits.
What you should walk away with
When behaviour depends on combinations of inputs, build a decision table. The structure forces clarity, surfaces missing rules, and gives you ready-made test cases. Up next: a different kind of complexity — features whose behaviour depends on what came before, which is the territory of state transition testing.