Decision Tables
What happens when the behavior depends on a combination of conditions, not just a single input? That's where decision tables shine.
The Problem
Imagine an e-commerce site's free shipping rules:
- Orders over $50 get free shipping
- Premium members always get free shipping
- Sale items have free shipping regardless of order total
Now: does a non-premium member with a $30 order containing a sale item get free shipping? What about a premium member with a $60 order and no sale items?
When multiple conditions interact, it's easy to miss combinations. Decision tables force you to think through every one.
Building a Decision Table
List the conditions (inputs) and actions (expected results), then fill in every combination:
| Rule 1 | Rule 2 | Rule 3 | Rule 4 | Rule 5 | Rule 6 | Rule 7 | Rule 8 | |
|---|---|---|---|---|---|---|---|---|
| Order > $50? | Y | Y | Y | Y | N | N | N | N |
| Premium member? | Y | Y | N | N | Y | Y | N | N |
| Sale item? | Y | N | Y | N | Y | N | Y | N |
| Free shipping? | Y | Y | Y | Y | Y | Y | Y | N |
The table reveals that only Rule 8 (small order, non-premium, no sale items) doesn't get free shipping. Without the table, you might have missed testing Rule 7.
When to Use Decision Tables
Decision tables are most valuable when:
- Business rules involve combinations of conditions
- The behavior changes based on 2-4 conditions (more than 4 gets unwieldy — use pairwise testing instead)
- You need to communicate test coverage to non-technical stakeholders
They're less useful for simple single-condition logic where equivalence partitioning is enough.
Simplifying the Table
With 3 conditions, you get 2³ = 8 rules. With 4 conditions, 16 rules. With 5, 32 rules. This grows fast.
In practice, you can simplify by combining rules that produce the same result. In our example, any rule with "Premium member = Y" always gets free shipping regardless of other conditions. You could collapse Rules 1, 2, 5, and 6 into a single test: "Premium members get free shipping."
But be careful — simplification means you're testing fewer combinations. Only simplify when you're confident the collapsed conditions are truly independent.
Exercise
A login system has these rules:
- Valid username AND valid password → Login success
- Valid username AND invalid password → "Wrong password" error
- Invalid username (regardless of password) → "User not found" error
- Account locked (regardless of credentials) → "Account locked" message
Build the decision table. How many test cases do you need?
The key takeaway: When conditions combine, decision tables make the invisible visible. You can't test what you haven't thought of.
A system has 4 binary (yes/no) conditions that determine behavior. How many rules does the full decision table contain?
With N binary conditions, the decision table has 2^N rules. For 4 conditions: 2^4 = 16 possible combinations. This is why decision tables become unwieldy beyond 4-5 conditions.
When should you use a decision table instead of equivalence partitioning?
Click to reveal answer
Use decision tables when the system's behavior depends on a COMBINATION of multiple conditions interacting together (e.g., premium member + order total + sale item). Equivalence partitioning works for single-input scenarios, while decision tables handle multi-condition business rules.
Click to flip back
In the free shipping example (order >$50 OR premium member OR sale item), a non-premium customer places a $30 order containing a sale item. Do they get free shipping?
The business rules state that sale items have free shipping regardless of order total. The decision table shows that any rule where "Sale item = Y" results in free shipping, regardless of the other conditions.