Decision table testing lays out combinations of conditions and the actions they produce, so gaps and contradictions become visible. It is most effective for business logic involving three or more interacting conditions.
There is one rule you must follow. With n conditions, start by mechanically writing out all 2ⁿ combinations. Skip that and the technique loses its purpose—you end up with a table that has gaps, when finding gaps was the whole point.
This article was published in 2024 and revised in September 2026. The table originally shown had only three rules for two conditions, so one combination was missing. It has been corrected, and the simplification procedure added.
Sponsored
The structure of a decision table
A decision table has four quadrants. Conditions run down the left; rules run across the top.
| Rule 1 | Rule 2 | Rule 3 | Rule 4 | |
|---|---|---|---|---|
| Condition 1 | N | N | Y | Y |
| Condition 2 | N | Y | N | Y |
| Action 1 | – | ✓ | ✓ | ✓ |
| Action 2 | – | – | – | ✓ |
- Condition stub (top left): the conditions being evaluated
- Condition entries (top right): Y or N for each rule
- Action stub (bottom left): the possible actions
- Action entries (bottom right): whether the action occurs
Each column is one test case. The table above gives four.
Building one
Step 1: list conditions and actions
Break the specification into conditions answerable with yes or no. Vague phrasing is not yet a condition.
✕ shipping varies with the order total
○ Condition: the order total is 5,000 yen or more (Y/N)
Step 2: enumerate every combination
This is the critical step. With n conditions, write out all 2ⁿ rules without exception.
| Conditions | Rules |
|---|---|
| 2 | 4 |
| 3 | 8 |
| 4 | 16 |
| 5 | 32 |
A reliable way to write them: alternate Y/N on the bottom condition, doubling the repeat length as you move up.
Step 3: fill in the actions
This is where cells the specification never covered become visible. That is the point of the exercise.
Step 4: simplify
Collapse conditions that do not affect the outcome into “-” (don’t care).
Sponsored
Worked example: shipping and discount
Specification: an online shop decides free shipping and a 10% discount from the order total and whether the customer is a platinum member.
- Condition 1: order total is 5,000 yen or more
- Condition 2: platinum member
- Action 1: free shipping
- Action 2: apply a 10% discount
All four rules
| R1 | R2 | R3 | R4 | |
|---|---|---|---|---|
| Total ≥ 5,000 | N | N | Y | Y |
| Platinum member | N | Y | N | Y |
| Free shipping | – | ✓ | ✓ | ✓ |
| 10% discount | – | ✓ | – | ✓ |
Do not drop R2—a platinum member spending under 5,000 yen. Tables with only three rules are common, and they simply mean nobody decided what happens in that case.
Building this table immediately gives you questions for the developer:
- Does a platinum member really get free shipping in R2, ignoring the total?
- Is there genuinely no discount in R3?
- Is the discount computed on the pre-tax or post-tax amount?
- Does shipping count toward the discount calculation?
Being able to report “the specification says nothing about R2” is the value here.
Simplifying with don’t care
As rules multiply the table gets hard to read, so collapse columns where a condition does not affect the result.
Consider three conditions:
- Condition 1: the item is in stock
- Condition 2: payment is by credit card
- Condition 3: the delivery address is a remote island
Before simplification (8 rules)
| R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | |
|---|---|---|---|---|---|---|---|---|
| In stock | N | N | N | N | Y | Y | Y | Y |
| Credit card | N | N | Y | Y | N | N | Y | Y |
| Remote island | N | Y | N | Y | N | Y | N | Y |
| Accept the order | – | – | – | – | ✓ | ✓ | ✓ | ✓ |
| Add island surcharge | – | – | – | – | – | ✓ | – | ✓ |
| Charge immediately | – | – | – | – | – | – | ✓ | ✓ |
After simplification (5 rules)
R1 to R4 all produce the same actions—nothing happens without stock—so they collapse into one column.
| R1′ | R2′ | R3′ | R4′ | R5′ | |
|---|---|---|---|---|---|
| In stock | N | Y | Y | Y | Y |
| Credit card | – | N | N | Y | Y |
| Remote island | – | N | Y | N | Y |
| Accept the order | – | ✓ | ✓ | ✓ | ✓ |
| Add island surcharge | – | – | ✓ | – | ✓ |
| Charge immediately | – | – | – | ✓ | ✓ |
Eight rules became five.
Rules for simplifying
- Enumerate first, then collapse. Starting with “-” means you never notice the gaps
- Only merge columns whose actions match exactly. One difference means a separate rule
- A merged column does not always mean one test. The “don’t care” condition may still branch in the implementation—expand it for high-risk areas
Sponsored
Handling impossible combinations
Enumerating everything produces rows that cannot occur in reality. That is useful information too.
Condition 1: on the free plan
Condition 2: currently using a paid add-on
→ "free plan with a paid add-on" should be impossible
Two things to confirm:
- Is it genuinely impossible? Transient states—just after cancellation, for instance—are common
- What does the system do if it happens anyway? Does it crash on unexpected state?
Do not delete the row as “impossible”—record that you confirmed it is impossible. When a data inconsistency produces it in production, that note is where the investigation starts.
When there are too many conditions
Past six conditions you have 64 rules and the table stops being workable. Three options:
1. Split the table
Separate groups of conditions that can be judged independently. If shipping and discount do not affect each other, they do not belong in one table.
2. Introduce intermediate conditions
Condition A: is a member
Condition B: registered over a year ago
Condition C: has made 10 or more purchases
↓
Intermediate condition: "is a preferred customer" (A and B and C)
But the intermediate condition itself needs its own decision table. This is layering, not hiding.
3. Switch to pairwise
If the conditions are all independent and there are simply many combinations, pairwise testing is the better fit.
The two have opposite goals—do not confuse them.
| Decision table | Pairwise | |
|---|---|---|
| Goal | Define behaviour without gaps | Reduce to an executable number |
| Combinations | Enumerate all, in principle | Cover pairs only |
| Applies to | Business logic, pricing | Environments and settings |
Where decision tables do not fit
They cannot express order-dependent behaviour, because a decision table only describes the current state.
Example: must go submit → approve → complete, in that order
cannot return to "submitted" from "completed"
→ not expressible as condition Y/N. That is state transition territory
Use state transition testing for that. For the range of a single input, use equivalence partitioning and boundary value analysis.
Summary
- A decision table has four quadrants: condition stub, condition entries, action stub, action entries
- With n conditions, enumerate all 2ⁿ rules before doing anything else
- Two conditions means four rules. A three-rule table is missing a combination
- The gaps that surface while filling it in are the point
- Simplify after enumerating, merging only columns whose actions match exactly
- Do not delete impossible rows—record that you confirmed they are impossible
- Too many conditions: split, layer, or switch to pairwise if they are merely numerous
- Order-dependent behaviour belongs to state transition testing
Verbal agreements in meetings are forgotten within the week; a table persists. It works as an alignment tool as much as a test design one. Upstream use is covered in QA in waterfall development.
