Learning Objectives
By the end of this lesson you will be able to:
- Follow a systematic process to build a decision table from a written specification
- Assign correct actions to each rule based on business logic
- Identify rules where the specification is ambiguous or missing
The Specification
You are testing a loan application system. The business rules say:
"An applicant is approved if their age is between 18 and 65 (inclusive), their income is declared as sufficient, and their credit history has no defaults. An applicant aged under 18 is rejected regardless of other conditions. An applicant over 65 is rejected regardless of other conditions. If the income is not declared sufficient, approval is denied even if all other conditions are met. An applicant with defaults in their credit history is always rejected."
Three binary conditions:
- Age valid (18–65): Yes / No
- Income sufficient: Yes / No
- No defaults: Yes / No
Step 1: List All Conditions
Write one condition per row:
| # | Condition |
|---|---|
| C1 | Age is 18–65 |
| C2 | Income sufficient |
| C3 | No credit defaults |
Step 2: Calculate Rules and Fill the Header
With 3 binary conditions: 2³ = 8 rules.
Fill in a pattern so every combination appears exactly once (binary counting works well):
| R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | |
|---|---|---|---|---|---|---|---|---|
| C1: Age valid | Y | Y | Y | Y | N | N | N | N |
| C2: Income OK | Y | Y | N | N | Y | Y | N | N |
| C3: No default | Y | N | Y | N | Y | N | Y | N |
Step 3: Assign Actions
Now analyze each rule against the specification:
| R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | |
|---|---|---|---|---|---|---|---|---|
| Approve | X | |||||||
| Reject | X | X | X | X | X | X | X |
Only R1 (all conditions met) results in approval. Every other combination rejects.
Step 4: Identify Ambiguities
Notice R5–R8: the age is invalid. Do you reject with the same error message regardless of income and credit status? The specification doesn't say. This is a gap — and finding it during test design (not during execution) is exactly the value of the technique.
Pro Tip: When you find an action that produces the same result regardless of a condition's value in several rules, that's a candidate for rule collapsing — covered in the next lesson.
Step 5: Write Test Cases
Each rule is a test case (or test case family if values are ranges):
- R1: Age = 30, Income = sufficient, Credit = clean → Expected: Approved
- R2: Age = 30, Income = sufficient, Credit = has defaults → Expected: Rejected
- R3: Age = 30, Income = insufficient, Credit = clean → Expected: Rejected
- R7: Age = 17, Income = sufficient, Credit = clean → Expected: Rejected (age under 18)
- R5: Age = 70, Income = sufficient, Credit = clean → Expected: Rejected (age over 65)
Summary
Building a decision table takes less than ten minutes for a three-condition system and produces a complete, reviewable test plan. The act of filling it in often exposes ambiguities in the specification before any code is run. That's the hidden superpower of this technique.