4.4 Decision Table Testing
Key Takeaways
- Decision table testing models how combinations of conditions produce actions, exposing interacting business rules.
- Each column (rule) combines condition values and the resulting actions; each rule is a coverage item.
- N independent binary conditions yield 2^N possible rules before simplification.
- Impossible or irrelevant combinations are removed or marked 'do not care' (—) to collapse the table.
- Minimum decision coverage tests at least one case per remaining rule; coverage = rules tested ÷ total rules × 100%.
Core Idea
A decision table is a black-box technique for behaviour driven by combinations of conditions. Equivalence partitioning and boundary value analysis examine inputs largely in isolation; a decision table instead captures how several conditions interact to determine the outcome. It is the right technique whenever you see phrases like 'if the customer is a member and the order is over 100 and it is a weekday, then…'.
The table has four areas:
- Conditions — the input causes, listed as rows in the upper-left.
- Condition alternatives — the value each condition takes in each rule (T/F for a limited-entry table, or specific values for an extended-entry table).
- Actions — the possible outcomes, listed in the lower-left.
- Action entries — which actions fire for each rule, in the lower-right.
Each column is a rule: a unique combination of condition values with its associated actions. Building the table forces analysts and testers to confront every combination, which routinely surfaces missing rules, contradictory rules, and untestable assumptions in the requirements — so the technique prevents defects as well as detecting them.
A Worked Example
A loyalty checkout grants a discount based on three binary conditions: member?, order over 100?, and promo code valid?. With three binary conditions the full table has 2^3 = 8 rules:
| Condition | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| Member? | T | T | T | T | F | F | F | F |
| Order > 100? | T | T | F | F | T | T | F | F |
| Promo valid? | T | F | T | F | T | F | T | F |
| Action: 20% off | Y | Y | N | N | N | N | N | N |
| Action: 5% promo | Y | N | Y | N | Y | N | Y | N |
Reading rule R1: a member with an order over 100 and a valid promo gets both the 20% member discount and the 5% promo. R8: a non-member, small order, invalid promo gets nothing. Each of the eight columns becomes one test case, with concrete data chosen to satisfy that column's condition values. This is minimum (decision table) coverage: at least one test per rule.
Collapsing the Table and Measuring Coverage
Real tables are rarely the full 2^N. Two simplifications shrink them:
- Impossible combinations are deleted. If 'promo valid?' can only be true when a code was entered, combinations that assume a valid code with no code entered are removed.
- Do-not-care conditions, written as a dash (—), collapse several rules into one when a condition has no effect on the action. For example, if a non-member never gets the member discount regardless of order size or promo, the four non-member columns may collapse where their actions are identical.
Decision table coverage is:
Coverage % = (rules (columns) tested
÷ total rules in the final table) × 100
Exam pointers: with N independent binary conditions the maximum number of rules is 2^N (so 3 conditions → 8, 4 conditions → 16); the technique is strongest when conditions genuinely interact (eligibility, pricing, insurance underwriting, access control); and collapsing the table is encouraged but must preserve every distinct behaviour. A good decision table both tests the rules and validates the requirements, because building it exposes gaps before any code runs.
Limited- vs Extended-Entry Tables, and a Procedure
CTFL distinguishes two forms:
- A limited-entry decision table uses only True/False (or Yes/No) for each condition. The loyalty example above is limited-entry.
- An extended-entry decision table lets a condition take specific values or ranges rather than just T/F — for instance an 'order total' condition might read < 50, 50–200, > 200. Extended-entry tables are more compact when a condition naturally has several relevant values, and they pair neatly with equivalence partitioning, since each column value can be an EP partition.
A reliable procedure for the exam:
- List the conditions (causes) and the actions (effects) from the specification.
- Determine the value set for each condition (T/F for limited-entry; the relevant values for extended-entry).
- Compute the combinations — up to 2^N for N binary conditions — and lay them out as columns.
- Fill in the action entries for each rule from the business rules.
- Simplify: delete impossible combinations and collapse rules using 'do not care' (—) where a condition has no effect.
- Derive one test case per surviving rule and state coverage as rules tested ÷ rules in the final table.
Why it earns its place
Decision table testing is the technique of choice for rule-rich domains — insurance underwriting, tax and discount logic, loan eligibility, access control, and configuration matrices — where individual-condition testing would miss the interactions. Two conditions that each pass in isolation can still combine into a wrong action, and only a combination-based technique catches it. On the exam, recognise the trigger ('behaviour depends on a combination of conditions'), compute 2^N for the maximum rule count, and remember that a well-built table validates the requirements as a by-product of being built.
A decision table has three independent binary conditions and no impossible combinations. How many full rule columns are possible?
In a decision table, what does a 'do not care' (—) entry for a condition signify?
Which situations are good candidates for decision table testing?
Select all that apply