Decision table testing, generated

Decision table testing is a black-box technique for business rules that combine several conditions. The table lists every combination of condition values as a rule, and for each rule, the actions the system should take. Each rule becomes a test case.

It is the right technique when the outcome depends on conditions together rather than separately: a discount that applies to members, but only on orders over a threshold, unless the item is already on sale. Testing each condition alone would never show what happens when they interact, and that is where business rule defects live.

Filling in the full table forces a decision for every combination, including the ones nobody thought about. What should happen when an account is locked and the password is wrong? Should the user see the lockout message, or the invalid password message? Either answer is defensible. Not having an answer is the defect.

Rules left with no action ticked are flagged for exactly this reason. Take them back to whoever owns the requirement. It is the cheapest point at which to find a missing rule, because no code depends on the answer yet.

A full table has one rule for every combination: two to the power of the number of yes-or-no conditions, so three conditions make eight rules and ten conditions make 1,024. Many of those rules turn out to share an outcome. If a locked account always shows the lockout message whatever the username and password, the four locked rules say the same thing.

Reducing the table merges rules that have the same actions and differ only in one condition, across every value that condition can take. The merged condition is shown as "-", meaning it does not matter. The reduced table has fewer tests and still covers every distinct outcome. The generator reduces greedily, so on large tables another valid reduction may be slightly smaller, but every reduction it produces is exact: each original combination maps to exactly one reduced rule with the same actions.

Every extra condition doubles a table of yes-or-no conditions. Beyond five or six conditions, check whether the rule really depends on all of them at once, or whether it splits into smaller independent rules that each deserve their own table. If the conditions are genuinely independent parameters rather than a single business rule, pairwise testing covers their interactions in far fewer tests.