Decision Table Testing
Decision Table Testing is used when the system behavior depends on multiple conditions evaluated simultaneously. Instead of writing separate test cases for every combination, a decision table maps all possible condition combinations to their expected outcomes. This technique is essential for testing business logic, discount engines, eligibility rules, and access control systems.
Decision Table Structure
- Conditions: All the input conditions that affect the output (e.g., Is user registered? Has valid coupon? Is premium member?)
- Actions/Outcomes: The expected output or behavior for each combination
- Rules/Columns: Each column = one unique combination of conditions → one expected outcome
- T = True/Yes, F = False/No, - = Doesn't matter (any value)
- Total combinations = 2^N for N boolean conditions (3 conditions = 8 combinations)
- Optimization: Merge rules where one condition doesn't affect the outcome (marked '-')
Decision Table for a Discount Engine
// ══════════════════════════════════════════════════════════════
// SCENARIO: E-commerce discount logic
// Conditions:
// C1: Is user a premium member? (Y/N)
// C2: Has a valid coupon code? (Y/N)
// C3: Cart total > $100? (Y/N)
//
// Outcomes (discount applied):
// A1: 30% discount (premium + coupon + over $100)
// A2: 25% discount (premium + over $100, no coupon)
// A3: 20% discount (premium + coupon, under $100)
// A4: 15% discount (coupon only, over $100)
// A5: 10% discount (premium member only, no coupon, under $100)
// A6: 5% discount (coupon only, under $100)
// A7: 0% discount (none of the above conditions)
// ══════════════════════════════════════════════════════════════
// R1 R2 R3 R4 R5 R6 R7 R8
// C1 Premium? Y Y Y Y N N N N
// C2 Coupon? Y Y N N Y Y N N
// C3 >$100? Y N Y N Y N Y N
// ──────────────────────────────────────────────────────────
// Discount: 30% 20% 25% 10% 15% 5% 0% 0%
// Implementation:
function calculateDiscount(isPremium, hasCoupon, cartOver100) {
if (isPremium && hasCoupon && cartOver100) return 30;
if (isPremium && hasCoupon && !cartOver100) return 20;
if (isPremium && !hasCoupon && cartOver100) return 25;
if (isPremium && !hasCoupon && !cartOver100) return 10;
if (!isPremium && hasCoupon && cartOver100) return 15;
if (!isPremium && hasCoupon && !cartOver100) return 5;
return 0; // covers R7 and R8
}
// Test cases derived directly from decision table rules:
test("R1: Premium + Coupon + >$100 → 30%", () => {
expect(calculateDiscount(true, true, true)).toBe(30);
});
test("R2: Premium + Coupon + ≤$100 → 20%", () => {
expect(calculateDiscount(true, true, false)).toBe(20);
});
test("R3: Premium + No Coupon + >$100 → 25%", () => {
expect(calculateDiscount(true, false, true)).toBe(25);
});
test("R4: Premium + No Coupon + ≤$100 → 10%", () => {
expect(calculateDiscount(true, false, false)).toBe(10);
});
test("R5: Non-Premium + Coupon + >$100 → 15%", () => {
expect(calculateDiscount(false, true, true)).toBe(15);
});
test("R6: Non-Premium + Coupon + ≤$100 → 5%", () => {
expect(calculateDiscount(false, true, false)).toBe(5);
});
test("R7/R8: Non-Premium + No Coupon → 0%", () => {
expect(calculateDiscount(false, false, true)).toBe(0);
expect(calculateDiscount(false, false, false)).toBe(0);
});Common Mistakes
- Missing some condition combinations — 3 boolean conditions = 8 rules; always use 2^N to know the maximum combinations
- Not collapsing 'don't care' conditions — when one condition doesn't change the outcome, mark it '-' and merge rules to reduce test cases
- Using decision tables for simple conditions — one-condition logic doesn't need a decision table; EP/BVA is sufficient
- Forgetting that decision tables are living documents — when business rules change, the decision table must be updated immediately
Tip
Tip
Practice Decision Table Testing in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Technical diagram.
Practice Task
Note
Practice Task — (1) Write a working example of Decision Table Testing from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Decision Table Testing is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Decision Table Testing is used when the system behavior depends on multiple conditions evaluated simultaneously.
- Conditions: All the input conditions that affect the output (e.g., Is user registered? Has valid coupon? Is premium member?)
- Actions/Outcomes: The expected output or behavior for each combination
- Rules/Columns: Each column = one unique combination of conditions → one expected outcome