What Is Decision Table Testing?
Decision table testing is a rule-based black-box test technique for logic whose behaviour depends on a combination of several conditions: the business rule is written down as a decision table, and every column of that table becomes a test case.
The decision table itself is a matrix. Conditions at the top, actions at the bottom, and every column is a rule: one concrete combination of conditions with the actions that should follow from it. The appeal of this form lies in its relentlessness: once the rule exists as a table, every conceivable combination has a column, and every column forces an answer. There is no special case left that simply nobody thought about.
The technique thereby checks more than the reaction to individual conditions: it checks whether every combination triggers the action that is right for it. That is exactly where the defects hide that spot-check testing misses: the case where two rules should fire at the same time and only one does. Decision table testing counts among the rule-based test design techniques.
When Is the Technique a Good Fit?
Wherever business rules link several conditions: pricing and discount logic, insurance checks, approval rules, authorisation checks, validations across several fields. In all these cases the desired behaviour can be expressed as a table, which eases test design and often sharpens the requirement itself.
With one or two conditions, the technique is usually overkill; direct test cases or a boundary value analysis will do. From three conditions on it gets interesting, from four or five practically indispensable, because by then nobody keeps all combinations in their head any more.
A side effect shows up before the first test: while the table is being drawn up, contradictions and gaps in the requirements come to light, contradictory rules, missing combinations, conditions that exclude each other. The table acts as a static checking instrument for the specification itself. Well maintained, it outlives several releases as the most dependable description of the rule, ideally curated together with the product owner and the developers, directly in the requirement or as an attachment to the user story.
The Procedure in Five Steps
Swipe right or use the arrow keys to see the full graphic.
- Identify the conditions. Which conditions influence the decision? Each one is phrased as binary or as a small value set.
- Identify the actions. Which reactions can the system show?
- Draw up the full table. With n binary conditions, 2 to the power of n columns emerge.
- Reduce the table. Two rules can only be merged if they trigger the same actions, differ in exactly one condition and between them cover all values of that condition. That condition is then marked “don’t care”. Remove infeasible rules beforehand.
- Derive the test cases. One test case per rule, with concrete values and the expected action; at a high risk level, several per reduced rule.
A Compact Example
Swipe right or use the arrow keys to see the full graphic.
A home contents insurance decides on claims according to three conditions: Was the policy active at the time of the loss? Was the claim reported within the deadline? Is the claim amount above the deductible? Three binary conditions, so 2 × 2 × 2 = 8 combinations. Reduction brings them down to four rules, because an inactive policy always leads to rejection, and with an active policy a missed deadline decides regardless of the claim amount:
| Condition / rule | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Policy active at the time of the loss | no | yes | yes | yes |
| Claim reported within the deadline | don’t care | no | yes | yes |
| Claim amount above the deductible | don’t care | don’t care | yes | no |
| Action: authorise payout (minus deductible) | no | no | yes | no |
| Action: rejection letter with reasons | yes | yes | no | yes |
The check via checksum: R1 carries two “don’t care” values and therefore covers 2 to the power of 2 = 4 combinations, R2 with one “don’t care” covers 2, R3 and R4 one each. The sum 4 + 2 + 1 + 1 = 8 matches the possible combinations exactly. That means one warning signal has stayed silent, nothing more. If the sum comes out too high, rules overlap; too low, and combinations are missing. If it matches, a gap can still cancel out against an equally sized overlap. The checksum is a smoke detector, not a proof. The rest is done by a substantive review of the table. Four test cases reach 100 percent coverage here.
Suppose R2 fails in the test run: a claim reported too late and above the deductible is paid out instead of rejected. The cause: the deadline check was implemented only in the customer portal, not in the interface through which brokers submit claims. A classic combination defect that a test with two or three “typical” claims would hardly ever have found, because typical claims happen to arrive on time.
Coverage and Success Criteria
Swipe right or use the arrow keys to see the full graphic.
The central metric is decision table coverage, also called column coverage: the share of exercised columns out of the feasible ones. Infeasible combinations, which can logically never occur, drop out of the denominator.
For the review of the table, best done together with the business side, four checking questions have proven their worth: Do overlapping rules lead to the same action (consistency)? Are there rules whose combination of conditions can never occur (feasibility)? Is a feasible combination missing (completeness)? And do the rules capture the behaviour the business actually wants (correctness)? The checksum method complements the review arithmetically but does not replace it: if the checksum deviates from the number of possible combinations, there is definitely a problem. If it matches, only one of several sources of error has been ruled out.
Strengths and Limits
The strength of the technique is its inevitability. Every combination gets a column, every special case an answer; ambiguities that survive in the running text of a requirement dissolve in the table whether anyone likes it or not. Add to that its accessibility: a decision table is explained in a few minutes, to the business side too.
The most important limit is exponential growth. Every additional binary condition doubles the table; with seven conditions, 128 columns are already on paper. Then reduction helps, splitting into partial tables per topic area, or combining with pairwise testing for the condition permutations; from about five conditions, tool support pays off. A second trap is non-binary conditions: if a condition has three or more values, the table grows correspondingly faster. Such conditions are either modelled explicitly with all their values or decomposed into several binary ones.
Related Techniques
Equivalence partitioning and boundary value analysis check the individual thresholds the conditions are made of; the decision table checks their interplay. With very many parameters and reduced value lists, pairwise testing takes over. When flows rather than rules are the issue, state transition testing is the fitting technique. The page test design techniques gives an overview of all eleven techniques.