Q2 of 38 · Test design
Walk me through using a decision table for a real feature.
Short answer
Short answer: List the inputs (conditions), enumerate every combination, and write the expected outcome for each row. Decision tables shine for business rules with several inputs that combine non-trivially — discounts, eligibility, pricing tiers.
Detail
Decision tables are the right tool when a feature has several boolean or categorical inputs and the outcome depends on the combination, not on any single input. They make the rule space explicit, expose contradictions in the spec, and turn directly into test cases.
The recipe:
- List the conditions (inputs that influence the outcome) along the top.
- List the actions (outcomes the system can take) along the bottom.
- Enumerate every combination of condition values as columns. With n boolean conditions you get 2^n columns.
- Fill in the expected action for each column.
- Collapse rules where some conditions don't matter for the outcome (use "—" for "don't care") to reduce duplication.
A worked example: a discount engine with three inputs — isMember, orderTotal ≥ £50, hasCouponCode. Eight combinations, each producing a discount percentage. Once the table is filled in, every row becomes a test case, and you'll often discover that the spec contradicts itself ("members get 10%, orders ≥ £50 get 15%, but if both apply…?") before a single line of code is written.
Decision tables are most valuable in domains where business stakeholders care about the exact behaviour: tax, billing, eligibility, pricing, regulatory rules. They double as documentation that PMs can review and sign off on, which catches spec bugs upstream of any code.
The limit: decision tables don't scale to large numbers of conditions (8 conditions = 256 rows). When that happens, look at pairwise testing to cover all condition pairs at lower cost, or split the rule into independent sub-decisions.
// EXAMPLE
discount-decision-table.md
# Discount engine — decision table
| # | isMember | total ≥ £50 | hasCoupon | Discount |
|----|----------|-------------|-----------|----------|
| 1 | F | F | F | 0% |
| 2 | F | F | T | 5% |
| 3 | F | T | F | 10% |
| 4 | F | T | T | 15% |
| 5 | T | F | F | 5% |
| 6 | T | F | T | 10% |
| 7 | T | T | F | 15% |
| 8 | T | T | T | 20% |
Each row is one test case. The PM signs off the table before
implementation begins; rows 4 and 8 are the ones that surface
"do discounts stack?" as a question.