Q4 of 38 · Test design
What is a decision table and when would you use one?
Short answer
Short answer: A decision table is a grid of input combinations and their expected outputs. Use one when a feature's behaviour depends on multiple inputs combining in non-trivial ways — discounts, eligibility, pricing, regulatory rules.
Detail
A decision table has conditions (inputs) along the top and actions (outputs) at the bottom. Each column represents one combination of condition values and its expected action. With n boolean conditions you get up to 2^n columns; categorical conditions multiply further.
The mechanics: identify conditions that influence the outcome, identify actions the system can take, enumerate combinations as columns, fill in the expected action for each, and collapse "don't care" rows where some conditions don't affect the outcome.
When decision tables fit:
- Multiple inputs that interact (discounts depending on member status, total, and coupon).
- Business stakeholders need to validate the rules — the table reads like a spec.
- The rule set is finite and structured — not free-text input.
When they don't:
- Many conditions (8+ booleans = 256+ rows) — pairwise testing scales better.
- Continuous inputs (numbers, dates) — combine with EP/BVA on the inputs first, then a smaller decision table on the resulting classes.
- State-dependent behaviour ("after the user has done X, then Y means Z") — use state transition.
Decision tables are most valuable in domains where business stakeholders care about exactness: tax calculation, billing, eligibility, regulatory compliance, pricing. The table doubles as documentation that the PM can sign off on, catching spec contradictions before code is written.