Decision Table Testing
Map every combination of conditions to their expected actions in a table. Each column is a test case. This technique is the gold standard for testing complex business rules.
1 The Hook
An MSD-style benefits portal has a rule for a hardship top-up payment: an applicant qualifies if they are currently receiving a main benefit, AND they have a dependent child, AND their cash assets are below a threshold. Three conditions. The team tests the happy path — all three true, payment granted — and a couple of obvious fails. It passes. It ships.
Weeks later, complaints arrive from two opposite directions. Some applicants with a dependent child but assets just over the threshold are being granted the top-up anyway. Others, who qualify cleanly, are being declined because they have no dependent child recorded — even though the rule should still consider them under a separate clause. The combinations that broke were never tested, because nobody wrote down the full set of combinations in the first place. They tested the cases they happened to think of.
Three yes/no conditions produce eight distinct combinations. The team tested maybe three of them. The five they skipped were not exotic edge cases — they were ordinary applicants whose particular mix of circumstances simply never came up in ad-hoc testing. When rules interact, the only way to be sure you have covered every combination is to lay them all out in a grid.
2 The Rule
When several conditions combine to drive an outcome, list every combination of those conditions as columns in a table and define the expected action for each — every column is one test case, and the table proves no combination was missed.
3 The Analogy
A KiwiSaver eligibility checklist at the bank.
When a bank works out whether a first-home buyer can withdraw their KiwiSaver, they do not rely on the teller remembering the rules. They run down a grid: Are you a member? For at least three years? Is this your first home? Will you live in it? Each combination of answers leads to a defined outcome — eligible, not eligible, or refer to a specialist. The grid exists precisely so that no combination of answers gets a made-up response on the day.
A decision table is that grid for your test cases. Every row of conditions, every combination of yes and no, has an agreed result written down in advance. You are not testing whatever scenarios spring to mind — you are working through a complete, exhaustive checklist where every line is a test.
What it is
A decision table is a matrix that systematically covers all combinations of input conditions and shows what action should result from each combination. It forces you to think about every scenario — including the ones you'd otherwise miss.
It's most useful when: multiple conditions interact, business rules are complex, or you need to prove exhaustive coverage to stakeholders.
Table structure
- Conditions (rows, top half) — the inputs or rules that can be true or false.
- Actions (rows, bottom half) — what the system does in response.
- Rules (columns) — each column is one combination of conditions. Each column = one test case.
For N binary conditions, the full table has 2N columns. 3 conditions = 8 test cases. Many can be merged when the action is identical regardless of one condition's value.
Worked example
A discount system: users get a discount if they are a member AND their order total is > $100. Members always get free shipping; non-members only get free shipping on orders > $100.
| Condition / Action | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Is member? | Y | Y | N | N |
| Order > $100? | Y | N | Y | N |
| Apply discount? | Yes | No | No | No |
| Free shipping? | Yes | Yes | Yes | No |
Each column (Rule 1–4) maps directly to a test case with defined inputs and expected outcomes. No ambiguity, no missed scenarios.
Reducing the table
When an action is the same regardless of one condition's value, you can collapse columns using a "don't care" value (often written as — or *). This reduces test count while maintaining coverage.
In the example above, free shipping for members applies regardless of order total — Rules 1 and 2 could be merged for the free-shipping action.
ISTQB mapping
| Ref | Topic | Level |
|---|---|---|
| 4.2.3 | Decision Table Testing | CTFL Foundation |
| FL-4.2.3 K3 | Apply decision table testing to derive test cases | Foundation LO |
| CTAL-TA 3.2.3 | Advanced decision tables, minimisation, cause-effect | Advanced / Senior |
When to use it
- When there are 2–5 conditions with interactions that matter
- When business logic is defined as "if A and B but not C, then..."
- When you need to show a stakeholder you've covered all scenarios
- As a precursor to test case writing — the table is your test design
Avoid for simple cases: If there's only one condition, use EP/BVA instead. Decision tables shine with 2+ interacting conditions.
Practice this technique: Try Junior Practice 09 — Checkbox & radio logic, Junior Practice 04 — NZ checkout form.
NZ example — GST pricing rules
New Zealand GST (Goods and Services Tax) is 15%. An e-commerce checkout must apply GST correctly based on two conditions: whether the customer is GST-registered (they can claim it back) and whether the product is GST-exempt (some items like financial services are exempt).
| Condition / Action | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Customer is GST-registered? | Y | Y | N | N |
| Product is GST-exempt? | N | Y | N | Y |
| Show price | Ex-GST | GST-exempt | GST-inclusive | GST-exempt |
| Add GST line item? | Yes | No | No | No |
Each rule = one test case. The decision table ensures all four combinations are covered. A common bug is that GST-registered customers get charged GST on exempt products (Rule 2 missing or wrong).
NZ online store — free shipping decision table
A NZ online store gives free shipping based on two conditions: (A) customer has an active loyalty card, (B) order total is $75 or more. The condition rows are filled in for you — complete the action rows by selecting Yes or No for each rule.
| Condition / Action | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Loyalty card? | Y | Y | N | N |
| Order ≥ $75? | Y | N | Y | N |
| Free shipping? | ||||
| Loyalty discount? |
| Condition / Action | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Loyalty card? | Y | Y | N | N |
| Order ≥ $75? | Y | N | Y | N |
| Free shipping? | Yes | Yes | Yes | No |
| Loyalty discount? | Yes | Yes | No | No |
Free shipping: loyalty card OR order ≥ $75 (either condition is sufficient).
Loyalty discount: loyalty card only (regardless of order total).
4 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
A fictional NZ broadband provider waives the connection fee when the customer is on a 12-month contract AND signs up online. There are two yes/no conditions, so there are four rules. Write out all four columns — the condition values and the resulting "Waive fee?" action for each.
Show model answer
Two conditions = 4 rules = 4 test cases. The action is "waive fee" only when BOTH conditions are Yes.
Rule1 Rule2 Rule3 Rule4
12-month contract? Y Y N N
Signed up online? Y N Y N
Waive connection fee? Yes No No No
The pattern Y/Y, Y/N, N/Y, N/N is the standard way to enumerate two binary conditions so none is missed. Only Rule 1 (both Yes) waives the fee. A common mistake is to forget Rule 2 or Rule 3 — the "one condition met, the other not" cases — which are exactly where partial-eligibility bugs live.
A tester built the decision table below for an ANZ overdraft approval rule with three yes/no conditions. It is broken: it has too few columns for three conditions, and one action value is wrong. The rule: approve an overdraft if the customer is over 18 AND has a regular income AND has no current default. Rewrite the full table.
Over 18? Y Y N
Regular income? Y N Y
No default? Y Y Y
Approve? Yes Yes No
Rewrite the complete decision table:
Show model answer
Three binary conditions = 2^3 = 8 columns. Approve only when all three are Yes.
R1 R2 R3 R4 R5 R6 R7 R8
Over 18? Y Y Y Y N N N N
Regular income? Y Y N N Y Y N N
No default? Y N Y N Y N Y N
Approve? Yes No No No No No No No
What was wrong with the original:
- Too few columns: three conditions need 8 rules, not 3. Five combinations were missing, so most ways an applicant could fail were never tested.
- Wrong action: in the original, "Over 18 Y, Regular income N, No default Y" was marked Approve = Yes. That is wrong — approval requires ALL three conditions, and regular income was No, so it must be No.
You can later collapse the seven "No" columns with don't-care values, but you must start from the full 8 to know they all resolve to No.
Build a complete decision table for a NZ online checkout with two conditions: (A) the product is GST-exempt, and (B) the order qualifies for free freight (subtotal $100 or more). Two actions: "Add 15% GST line?" and "Charge freight?". Lay out all rules with both action rows.
Show model answer
Two conditions = 4 rules. Standard Y/Y, Y/N, N/Y, N/N enumeration:
R1 R2 R3 R4
GST-exempt product? Y Y N N
Subtotal >= $100? Y N Y N
Add 15% GST line? No No Yes Yes
Charge freight? No Yes No Yes
Reasoning: GST line is added only when the product is NOT exempt (R3, R4). Freight is charged only when the subtotal is under $100 (R2, R4). The two actions are driven by different conditions, which is the whole value of laying it out — it stops you assuming "free freight" and "no GST" go together. A strong answer keeps the two actions independent and covers all four combinations.
Self-Check
Click each question to reveal the answer.
Q1: For N binary conditions, how many columns does a full decision table have?
2N. Two conditions give 4 columns, three give 8, four give 16. Each column is one unique combination of the conditions, and each column becomes one test case.
Q2: Why does ad-hoc "test the cases I can think of" tend to miss bugs that a decision table catches?
When conditions interact, the failures live in particular combinations — one condition met and another not. Those rarely spring to mind unprompted. The table forces every combination onto the page, so no combination silently goes untested.
Q3: What is a "don't care" value and what is it for?
A "don't care" (written — or *) marks a condition whose value does not change the action. It lets you collapse multiple columns into one, reducing the test count while keeping full coverage — for example, when a member always gets free shipping regardless of order total.
Q4: When is a decision table the wrong tool?
When there is only a single condition driving the outcome. With one condition, equivalence partitioning and boundary value analysis are simpler and sufficient. Decision tables earn their keep with two or more interacting conditions.
Q5: A column in a decision table corresponds to what testing artefact?
One test case — a defined set of input conditions with an expected action. The completed table is effectively your test design: each column has its inputs and its expected outcome ready to execute.