Learner can build a small decision table from rules and explain why pairwise testing tames combinatorial explosion.
Decision tables and pairwise testing
Handling combinations systematically
When a feature's behavior depends on multiple conditions at once, equivalence partitioning alone isn't enough — you also need to think about combinations. Decision tables are a systematic tool for this. A decision table lists all relevant conditions as rows, enumerates each combination of condition values as a column (called a rule), and for each rule states the expected action or outcome. This makes it impossible to overlook a scenario and keeps requirements unambiguous.
Consider an e-commerce discount rule: a 10% discount applies only if the customer is a registered member AND the order total exceeds $50. Four combinations exist: (member, >$50) → discount; (member, ≤$50) → no discount; (non-member, >$50) → no discount; (non-member, ≤$50) → no discount. A decision table captures all four in one place, making it easy to spot that only one rule grants the discount.
Pairwise (all-pairs) testing addresses a harder version of the same problem. With many independent parameters, the number of combinations explodes. For example, 5 parameters each with 3 values gives 3^5 = 243 combinations. Research shows most defects are triggered by the interaction of just two parameters at a time. Pairwise testing guarantees that every pair of parameter values appears in at least one test — typically cutting the test count to 9–27 for the same 5-parameter example. The saving is dramatic: full coverage 243 tests vs pairwise roughly 9–15 tests, with comparable fault-detection effectiveness for interaction bugs.
When to use each: use decision tables when you have a small, well-defined set of business rules with clear true/false conditions. Use pairwise when you have many independent configuration parameters (browsers, OS versions, payment methods, languages) and exhaustive combinations are impractical.
Lesson notes
Handling combinations systematically
When a feature's behavior depends on multiple conditions at once, equivalence partitioning alone isn't enough — you also need to think about combinations. Decision tables are a systematic tool for this. A decision table lists all relevant conditions as rows, enumerates each combination of condition values as a column (called a rule), and for each rule states the expected action or outcome. This makes it impossible to overlook a scenario and keeps requirements unambiguous.
Consider an e-commerce discount rule: a 10% discount applies only if the customer is a registered member AND the order total exceeds $50. Four combinations exist: (member, >$50) → discount; (member, ≤$50) → no discount; (non-member, >$50) → no discount; (non-member, ≤$50) → no discount. A decision table captures all four in one place, making it easy to spot that only one rule grants the discount.
Pairwise (all-pairs) testing addresses a harder version of the same problem. With many independent parameters, the number of combinations explodes. For example, 5 parameters each with 3 values gives 3^5 = 243 combinations. Research shows most defects are triggered by the interaction of just two parameters at a time. Pairwise testing guarantees that every pair of parameter values appears in at least one test — typically cutting the test count to 9–27 for the same 5-parameter example. The saving is dramatic: full coverage 243 tests vs pairwise roughly 9–15 tests, with comparable fault-detection effectiveness for interaction bugs.
When to use each: use decision tables when you have a small, well-defined set of business rules with clear true/false conditions. Use pairwise when you have many independent configuration parameters (browsers, OS versions, payment methods, languages) and exhaustive combinations are impractical.