Decision Table Testing — Learn How to Test (Junior)

1 The Hook — Why This Matters

A bank's loan approval system had 3 conditions: credit score (good/bad), income (high/low), and deposit (large/small). A junior tester tested each condition individually — bad credit alone, high income alone, large deposit alone. Everything passed.

But they never tested the combination: bad credit + high income + large deposit. The developer had never handled that case. When a real customer with exactly that profile applied, the system crashed. The bug sat in production for 2 weeks, rejecting valid applicants silently.

Decision tables catch combinations. That's why this technique matters.

2 The Rule — The One-Sentence Version

List every condition. List every combination. Each column = one test case.

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.

3 The Analogy — Think Of It Like...

Analogy

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.

4 Watch Me Do It — Worked Examples

Example 1 — Simple Binary (2 Conditions)

Loan approval: Credit Good? (Y/N), Stable Job? (Y/N).

2 conditions × 2 values each = 4 rules.

Conditions	R1	R2	R3	R4
Credit Good?	Y	Y	N	N
Stable Job?	Y	N	Y	N
Action: Approve?	Yes	Maybe	Maybe	No

Each column is one test case. No combination is hidden.

Example 2 — E-commerce Discount (3 Conditions)

Discount rules: Member? (Y/N), Cart ≥ $100? (Y/N), Promo Active? (Y/N).

3 conditions × 2 values each = 8 rules.

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).

Example 3 — Reduction with "Don't Care"

Sometimes multiple rules produce the same action. We can collapse them using "—" (don't care).

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.

5 When to Use It — Decision Tool

✅ 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)

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.

🚫 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.

🚫 Ignoring impossible combinations

I used to think: Every cell in the table needs a test.
Actually: Mark impossible combinations (e.g., "submitted" AND "draft") and document why. Don't waste tests on them, but don't ignore them either — the dev might not know they're impossible.

🚫 Confusing decision table testing with decision coverage

I used to think: They're the same thing.
Actually: Decision table testing is black-box — you don't see the code. Decision coverage is white-box — you measure whether every branch in the code was executed. Different worlds.

🚫 Over-collapsing rules and losing test scenarios

I used to think: Fewer rules is always better.
Actually: Only collapse when the action is identical and the conditions truly don't matter. Over-collapse and you'll miss a scenario where the action secretly differs.

7 Now You Try — Shipping Calculator

🎯 Interactive Exercise

Spec: A shipping calculator charges:

Free shipping if Member AND Order > $50
Standard ($5) if Member AND Order ≤ $50
Standard ($5) if Not Member AND Order > $100
Express ($10) if Not Member AND Order ≤ $100

Your task: Build the decision table. List conditions, list all combinations, and state the action for each rule.

Conditions	R1	R2	R3	R4
Member?	?	?	?	?
Order > $50?	?	?	?	?
Action	?	?	?	?

Conditions	R1	R2	R3	R4
Member?	Y	Y	N	N
Order > $50?	Y	N	Y	N
Order > $100?	—	—	Y	N
Action	Free	Standard $5	Standard $5	Express $10

Note: Some testers add "Order > $100?" as a third condition for non-members. That's valid. Others keep it to 2 conditions and map actions directly. Both are correct if the coverage is complete. The key question: Did you catch every combination?

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?

2^N 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.

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.