Decision Table Testing
When rules collide, testers win. Stop guessing what happens when multiple fields interact. Learn how to map every logic combination into a foolproof table of test cases.
1 The Hook — The Spaghetti If
A Senior Tester in Auckland once audited a legacy payroll system. The "overtime" rule was defined as: "If they worked > 40 hours AND it's a weekend AND they aren't on a fixed salary AND it's not a public holiday..."
The code was a mess of nested if statements. The tester found a bug where fixed-salary staff were getting double-time on Christmas Day — a $200k overpayment mistake. No amount of BVA or EP would have caught this. Only by mapping the interaction of four conditions into a table did the logic gap become obvious. Decision tables turn "spaghetti code" into a checklist.
2 The Rule — Conditions, Actions, Rules
Map every "Condition" (Input) to its "Action" (Output). Every column in your table is one complete test case.
For $N$ binary (Yes/No) conditions, you have $2^N$ possible rules. 3 conditions = 8 rules. 4 conditions = 16 rules. Your job is to test them all (or merge the ones that don't matter).
3 The Analogy — The Recipe Builder
The Subway Sandwich Order.
Think of a decision table like a sandwich order. Condition 1: Do you want bread? (Y/N). Condition 2: Do you want meat? (Y/N). Action: Total Price. If you have bread and meat, price is $8. If you have bread but no meat, price is $5. If you have no bread... the action is "Error: No sandwich possible." The table makes sure the "No Bread" scenario isn't forgotten.
4 Watch Me Do It — NZ Car Insurance
Scenario: An insurance app gives a "Safe Driver Discount" based on three conditions: Age >= 25, Full licence, and Zero Claims in 3 years.
| Condition / Action | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Age >= 25? | Y | Y | Y | N |
| Full licence? | Y | Y | N | Y |
| Zero Claims? | Y | N | Y | Y |
| Discount? | Yes | No | No | No |
| Policy Approved? | Yes | Yes | Yes | Refer to Lead |
Rule 1 is your "Happy Path." Rule 4 is an interesting edge case — young drivers on a full licence with no claims might need manual review rather than automatic rejection.
5 Decision Tool — When to Use Tables?
✅ Use Tables when...
- Multiple input fields depend on each other.
- The spec says "If A and B but not C..."
- You need to prove "Exhaustive Coverage" to a lead.
❌ Don't use them for...
- Single-field validation (use BVA/EP).
- Simple UI bugs (typos, layout).
- More than 5 conditions (table gets too huge).
6 Common Mistakes
🚫 Forgetting the "Don't Care" (Dash)
I used to think: I have to test all 16 columns for 4 conditions.
Actually: If the user isn't logged in (N), it doesn't matter if they are a "Premium Member" (Y/N). You can use a dash (—) to merge those two columns into one, saving you an entire test case.
🚫 Only testing the "True" combinations
I used to think: I'll just test the combinations that lead to a discount.
Actually: The most dangerous bugs are when someone gets a discount they shouldn't have. You must test the "False" columns too.
7 Now You Try — NZ GST Pricing
Scenario: A checkout system applies GST based on two conditions: GST-Registered Customer? and Product is GST-Exempt?
Complete the actions for Rule 2: Customer is GST-Registered (Y) and Product is GST-Exempt (Y).
8 Self-Check
Q1. How many rules (columns) are in a table with 3 Yes/No conditions?
8. (2 x 2 x 2 = 8). Each condition can be True or False, so the total combinations are 2 raised to the power of the number of conditions.
Q2. What is the difference between a Decision Table and Equivalence Partitioning?
EP tests one field in isolation. Decision Tables test how multiple fields interact. If Rule A depends on the value of Rule B, use a table.
9 Interview Prep
"How do you ensure you've covered all possible business rules?"
Answer: "I use Decision Table testing. By identifying the atomic input conditions and systematically listing every combination in a grid, I can ensure that 100% of the logic paths are covered. It's especially useful for identifying 'negative' scenarios that are often missed in traditional requirement docs."
10 Next Step
Now that you've mastered logic tables, let's look at how software moves through different States over time. Next: State Transition Testing.