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.
Senior engineer insight
The first time I built a decision table on a real project — CoverNZ weekly compensation entitlement, three conditions, eight rules — I discovered the spec had defined only six actions. Two combinations were completely unspecified. Nobody had noticed because ad-hoc testing never landed on those combinations. The table didn't just help me test; it exposed a requirements gap before a single line of code was written. That's when I stopped thinking of decision tables as a test design tool and started treating them as a requirements audit tool.
Most common mistake: building the table after writing the test cases, then using it to confirm what you already wrote — instead of letting it drive what you write.
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.
From the field
On an Revenue NZ tax assessment project, the team assumed that income bracket and residency status were the only two conditions that determined withholding tax rate — a 2x2 table, four rules, done in an afternoon. What nobody noticed until UAT was that "tax treaty country" was a third condition buried three pages into the spec, doubling the table to eight rules. Two of those extra rules produced a different withholding rate for the same income bracket, and both had been coded wrong because the developer was working from the same incomplete mental model as the testers. We found it with a systematic table rebuild during UAT; the fix took two hours but the rework conversation with the business took two days. The lesson: spend ten minutes listing every condition before you start drawing columns — the ones hidden in subordinate clauses cost the most.
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.
Why teams fail here
- They start filling in actions before they have all the conditions — late-discovered conditions invalidate every rule already written and the table gets rebuilt under time pressure, usually incorrectly.
- They collapse rules too aggressively, marking conditions as "don't care" based on assumption rather than verified spec behaviour — one unchecked "don't care" can hide an entire class of production defects.
- They treat the table as a documentation artifact rather than a live test design tool — it gets filed, nobody reads it, and the actual test cases drift away from the combinations the table identified.
- They build one enormous table for a whole feature instead of scoping tight tables per decision point — a 32-rule table with ambiguous actions is worse than no table at all because it creates false confidence.
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.
Key takeaway
A decision table doesn't just tell you what to test — it tells you what the spec forgot to say.