Decision Table Testing
Catch combination bugs that single-condition testing misses. Learn how to build, reduce, and convert decision tables into real test cases.
1 The Hook — Why This Matters
An Auckland insurance startup launched a new policy calculator with three conditions: age bracket (under 65 / 65+), claims history (clean / had claims), and membership status (member / non-member). The junior tester tested each condition individually — young driver, old driver, member, non-member, clean record, claims record. Every test passed.
But they never tested the combination: 65+ AND had claims AND non-member. The developer had written a nested if-statement that only handled seven of the eight possible combinations. When a real customer with exactly that profile applied online, the system returned a $0 premium with full coverage. The bug sat in production for 11 days, costing the company tens of thousands in invalid quotes before a customer called to ask why their policy was free.
Decision tables catch combinations. That's why this technique matters.
2 The Rule — The One-Sentence Version
Map every combination of conditions to expected outcomes.
If you have 3 binary conditions, you have 2 × 2 × 2 = 8 combinations. Each combination is a potential test case. You don't guess which ones matter — you list them all, then reduce intelligently using "don't care" entries where actions are truly identical.
3 The Analogy — Think Of It Like...
A recipe matrix.
If you have eggs AND flour AND sugar → make a cake. If you have eggs AND flour BUT no sugar → make flatbread. If you have eggs BUT no flour → make an omelette. Every combination produces a different outcome. A decision table is just a recipe matrix for software — every ingredient combination maps to exactly one dish.
4 Watch Me Do It — Step by Step
Follow these six steps every time you see multiple conditions interacting in a specification.
- Identify the conditions Read the spec and list every condition that affects the outcome. A condition is anything that can be true or false (or has discrete values). In a loan system, conditions might be "Credit Good?" and "Job Stable?".
- Identify the actions List every possible outcome or action: Approve, Review, Reject. Each column in your table will map one combination of conditions to exactly one action.
- Calculate the maximum number of rules For binary conditions, the formula is 2n where n is the number of conditions. Two conditions = 4 rules. Three conditions = 8 rules. Four conditions = 16 rules.
- Create the full decision table Fill in every combination systematically. Start with the first condition alternating Y/N in pairs, the next alternating every two, the next every four, and so on.
- Define the action for each rule Read the spec carefully and write the correct action in every column. If the spec is unclear, flag it as a requirement question — don't guess.
- Reduce with "don't care" and convert to test cases When multiple rules produce the identical action and a condition truly doesn't matter, collapse them using "—" (don't care). Only reduce when you're certain. Then write one test case per remaining rule.
Conditions: Credit Good? (Y/N), Job Stable? (Y/N). Max rules: 22 = 4.
| Conditions | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Credit Good? | Y | Y | N | N |
| Job Stable? | Y | N | Y | N |
| Action: Approve? | Yes | Review | Review | No |
Each column is one test case. No combination is hidden. R2 and R3 both go to "Review" but they are different test cases because the reason differs.
Conditions: Member? (Y/N), Cart ≥ $100? (Y/N), Promo Active? (Y/N). Max rules: 23 = 8.
| Conditions | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| Member? | Y | Y | Y | Y | N | N | N | N |
| Cart ≥ $100? | Y | Y | N | N | Y | Y | N | N |
| Promo Active? | Y | N | Y | N | Y | N | Y | N |
| Action: Discount % | 25% | 20% | 15% | 10% | 15% | 5% | 10% | 0% |
Without a decision table, would you have remembered to test a non-member with a small cart and an active promo? (Rule 7). Most testers forget the odd combinations. The table forces you to see them.
Sometimes multiple rules produce the same action. We can collapse them using "—" (don't care) when a condition truly does not affect the outcome.
Suppose in the loan example, any applicant with bad credit gets rejected regardless of job stability:
| Conditions | R1 | R2 |
|---|---|---|
| Credit Good? | Y | N |
| Stable Job? | Y / N | — |
| Action | Review job status | Reject |
R2 says "don't care" for Stable Job because bad credit always rejects. We reduced 4 rules to 2 without losing coverage. But be careful — only collapse when the action is truly identical and the condition is genuinely irrelevant. When in doubt, keep the rule separate.
5 When to Use It / When NOT to Use It
✅ Use decision tables when...
- Multiple conditions interact to produce an outcome
- Business rules are full of if/and/or logic
- Regulatory or compliance logic must be fully verified
- You need to prove you've tested every combination
❌ Don't use decision tables when...
- Only a single condition determines the outcome
- You're testing UI layout or visual design
- The logic is purely sequential (no branching combinations)
- Conditions have many values (leads to combinatorial explosion)
Before you build a decision table, ask:
- Does your condition logic truly combine multiple inputs?
- Is there complex if/and/or logic that would be hard to test ad-hoc?
- Are there business rules that depend on combinations of conditions?
When decision tables fail
Decision tables collapse when the table becomes too complex to manage. If you find yourself with 64+ rules, combinatorial explosion is winning—collapse non-essential conditions, use boundary value analysis on numeric conditions, or break the logic into smaller, independent tables. Overly complicated tables hide bugs instead of exposing them.
6 Common Mistakes — Don't Do This
🚫 Missing conditions
I used to think: The obvious conditions are enough.
Actually: Every Boolean flag, every threshold, every status field is a condition. Missing one means missing every rule that depends on it. If you're testing a checkout flow, "items in cart" and "payment method valid" and "shipping address confirmed" are all separate conditions.
🚫 Creating massive tables instead of focused ones
I used to think: One giant table covers the whole feature.
Actually: 6 binary conditions = 64 rules. That's unmanageable. Split into focused tables per feature area, or use equivalence partitioning to reduce condition values first. A decision table should fit on one screen.
🚫 Confusing decision coverage with decision table testing
I used to think: Decision table testing and decision coverage are the same thing.
Actually: Decision table testing is black-box. You build the table from requirements without looking at code. Decision coverage is white-box. You measure whether every branch (e.g., every outcome of an if-statement) was executed during testing. Different worlds.
When decision tables fail
Over-complicated tables with too many rules become unmaintainable and defeat the purpose. A table with 64 rules is harder to read than the code itself. Also, tables can hide rule combinations that the specification never meant to allow—combinatorial explosion without careful scoping defeats the technique's value.
7 Now You Try — Interview Warm-Up
Question: How many test cases are needed for 4 binary conditions before reduction?
Work it out using the 2n formula, then reveal the answer.
Answer: 16 test cases maximum before reduction.
With 4 binary conditions, the maximum number of rules is 24 = 16. After intelligent reduction with "don't care" entries, you may be able to collapse some rules — but never reduce unless the action is truly identical and the condition genuinely doesn't matter. When in doubt, test the extra rule. It's cheaper than a production bug.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. How many rules does a decision table need for N binary conditions?
2N rules. 2 conditions = 4 rules. 3 conditions = 8 rules. 4 conditions = 16 rules. If you have 5+ conditions, consider splitting into multiple focused tables or using pairwise testing.
Q2. What's the difference between decision table testing and decision coverage?
Decision table testing is black-box. You build the table from requirements without looking at code. Decision coverage is white-box. You measure whether every branch (e.g., every outcome of an if-statement) was executed during testing. Different worlds.
Q3. When should you reduce a decision table by collapsing rules?
Only when multiple rules produce the identical action and the differing conditions are genuinely irrelevant to that action. If there's any chance the action could differ, keep the rules separate. When in doubt, test the extra rule — it's cheaper than a production bug.
9 Interview Prep — Junior Q&A
Interviewers ask how you approach complex business logic. These are the questions you'll hear.
Q. "How is a decision table different from writing test cases ad-hoc?"
Ad-hoc testing is reactive—you write cases as they occur to you, and you often miss combinations. Decision tables are systematic. They force you to enumerate every condition, then create a rule for each combination. This guarantees coverage. You can prove that every logical path has been tested at least once.
Q. "When should you collapse rules in a decision table?"
Only when multiple rules produce the identical action and the differing conditions are provably irrelevant. For example, if "Discount applies when (member AND high-spend) OR (loyalty-member AND high-spend)", you might collapse those to a single rule "Discount applies when (high-spend AND (member OR loyalty-member))". If in doubt, keep the rule separate—it's safer.
Q. "How do you handle decision tables with too many conditions?"
If a table has 10+ conditions, combinatorial explosion makes it unmanageable. Split the logic: create one table for conditions A–E, another for F–J. Or identify which conditions truly interact and which are independent—test only the interactions. The goal is rigorous coverage, not exhaustion.