VisaSpark
Sign in
intermediate26 min

Decision Tables for Combined Conditions (Lab)

A hands-on lab: when a result depends on several independent conditions combined together, a decision table finds the combinations one-input-at-a-time testing misses.

What you'll learn

  • Build a decision table for logic driven by multiple independent conditions
  • Derive one test case per row (rule) of a decision table
  • Explain why testing conditions one at a time can miss combination-specific defects

Prerequisites

Explanation

A discount rule: "loyalty members get 10% off; orders over $100 get 5% off; if both apply, take the larger discount, not both stacked." Testing "is the customer a loyalty member" and "is the order over $100" as two separate one-at-a-time checks will never exercise the specific rule about what happens when both are true at once — and that combined case is exactly where the interesting bug usually lives (a developer who forgot the "not both stacked" rule and simply added the two discounts together).

A decision table makes every combination of conditions explicit instead of leaving them implicit. You list every condition as a row, list every meaningful combination of true/false values as a column, and write the correct expected outcome for each column. Each column is one test case — deterministic, unambiguous, and traceable directly back to a specific business rule.

For two conditions (loyalty member: yes/no, order over $100: yes/no), there are four combinations, so a complete table has four columns:

Loyalty member?Order > $100?Expected discount
NoNo0%
NoYes5%
YesNo10%
YesYes10% (the larger of the two, not stacked)

That fourth column — both conditions true — is the one an ad hoc tester is most likely to skip, and it's the one that actually encodes the business rule that makes this feature non-trivial ("take the larger, don't stack"). With three independent yes/no conditions, a full table has eight combinations (2×2×2); with four conditions, sixteen. In practice, testers often simplify by collapsing combinations that provably produce the same rule (a technique called "don't-care" reduction), but the discipline of listing every combination first — and only then simplifying with a clear justification — is what prevents accidentally dropping a real case.

Example

The loyalty/order-size discount rule implemented, with each of the four decision-table combinations run as its own check.

function discountPercent(isLoyaltyMember, orderOverHundred) {
  if (isLoyaltyMember && orderOverHundred) return 10; // larger of the two, not stacked
  if (isLoyaltyMember) return 10;
  if (orderOverHundred) return 5;
  return 0;
}

console.log(discountPercent(false, false)); // 0
console.log(discountPercent(false, true));  // 5
console.log(discountPercent(true, false));  // 10
console.log(discountPercent(true, true));   // 10 -- the combination row that matters most

Try it yourself

Break the "not stacked" rule on purpose (change the first return to `return 15`) and re-run — notice only the combined-conditions test case would catch this.

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Guided exercise

Guided exercise

A shipping rule: free shipping if (isPremiumMember OR orderOver75). Build the decision table's four expected outcomes as booleans: caseNeitherTrue, caseOnlyPremium, caseOnlyOrderSize, caseBothTrue (true means free shipping).

Checks: correctly derives the neither-true case · correctly derives the only-premium case · correctly derives the only-order-size case · correctly derives the both-true case

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Independent exercise

Independent exercise

Implement approvalDecision(hasGoodCredit, hasCosigner) following this rule: approved only if hasGoodCredit is true, OR if hasCosigner is true (a cosigner alone is enough even with bad credit). Return the string 'approved' or 'denied'.

Checks: neither condition true is denied · good credit alone is approved · cosigner alone is approved · both conditions true is approved

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Common mistakes

  • Testing each condition independently ("what if hasGoodCredit is true" and separately "what if hasCosigner is true") without ever testing the combination where both are true or both are false.
  • Building an incomplete decision table that silently skips a combination, which then ships as an unhandled edge case.
  • Confusing an AND relationship between conditions with an OR relationship — they produce different tables and different bugs when mixed up.

Knowledge check

Knowledge check

1. Why is testing conditions one at a time insufficient for logic involving multiple combined conditions?
2. A decision table has 3 independent yes/no conditions. How many columns does a complete table have?
3. In a decision table, what does each column represent?

Takeaway

Decision tables make every combination of conditions explicit, so the specific rule for "what happens when multiple conditions are true together" gets its own deliberate test case instead of being silently skipped.

Summary

This lab practiced building a decision table for combined-condition logic and deriving one test case per row, specifically targeting the combinations that one-condition-at-a-time testing misses.

References

Your notes

Notes save automatically.

Finished this lesson?

Mark it complete to track your progress and schedule a future review.

Next: State Transition Testing →