Learning Objectives
By the end of this lesson you will be able to:
- Define the components of a decision table: conditions, actions, and rules
- Explain when decision table testing is the right technique to apply
- Identify the number of rules required for a given set of binary conditions
The Problem With Ad-Hoc Test Cases
Imagine a discount system with three conditions: the customer is a member (yes/no), the order total exceeds €100 (yes/no), and today is a weekend (yes/no). That's three binary conditions — eight possible combinations.
An experienced tester writing cases ad-hoc might cover six or seven. They'll probably get the obvious ones: member + big order + weekend, or non-member + small order + weekday. What they'll miss is the interaction they didn't think to imagine — the combination that only a developer (or a customer at 11pm on a Sunday) would encounter.
Decision tables eliminate this problem by making the combinatorial space explicit.
Anatomy of a Decision Table
A decision table has four sections:
Conditions (top left) — The input variables that drive the logic. Each row is one condition.
Condition values (top right) — For each column (rule), the value of each condition: Y/N, T/F, or specific values.
Actions (bottom left) — The expected system behaviors. Each row is one action.
Action values (bottom right) — For each column, whether each action fires: X (yes) or blank (no).
Each column is one rule — one complete combination of condition values and the actions they trigger.
How Many Rules?
For binary conditions, the formula is simple: 2ⁿ rules, where n is the number of conditions.
- 2 conditions → 4 rules
- 3 conditions → 8 rules
- 4 conditions → 16 rules
The number doubles with each condition. This is why decision tables become unwieldy above 5–6 conditions — at that point, you need reduction techniques (covered in Lesson 1.3) or pairwise testing (Module 5).
When to Use Decision Tables
Decision tables shine when:
- Multiple conditions interact to determine the outcome
- The specification describes behavior using "if A and B, then X; if A and not B, then Y" language
- You suspect the developer may have missed some combinations
- Requirements review shows different stakeholders making different assumptions about edge cases
Pro Tip: Any requirement that uses the words "and," "or," "unless," or "except" is a candidate for a decision table. These words signal interacting conditions.
When Not to Use Them
Decision tables are overkill for:
- Single-condition logic (just use equivalence partitioning)
- Continuous numeric ranges where BVA is more appropriate
- Sequential processes where state transitions are more descriptive
Summary
A decision table is a structured way to enumerate every combination of input conditions and map each to its expected outcome. It guarantees that your test design does not accidentally skip a combination — which is the most common failure mode of ad-hoc test case design. In the next lesson, you'll build one from scratch.