Decision table

A decision table expresses a rule set as a matrix in which columns represent individual rules and rows represent conditions or actions. Each rule column specifies one combination of condition values and the resulting actions. In a basic table, a condition may be marked yes or no, while an action is marked as performed or not performed.¹

The method separates inputs from consequences. This helps analysts detect omitted cases, contradictory rules, and combinations that can never occur. A table can describe operational policy, software behavior, test cases, or requirements, and it is especially useful when several independent conditions jointly determine an outcome. The International Software Testing Qualifications Board treats decision tables as a black-box test-design technique because each meaningful rule can yield one or more test cases.¹

Decision tables are commonly built by identifying conditions first, enumerating their relevant values, and then assigning actions to each feasible combination. In a limited-entry table, conditions have a small fixed set of symbols such as yes, no, or irrelevant; in an extended-entry table, entries can contain ranges, categories, or more descriptive values.

A complete table begins with the domain of the decision rather than with implementation code. Analysts remove impossible combinations, merge rules that produce the same actions, and mark a condition as “don’t care” when its value cannot change the result. The resulting table may be reduced substantially, but reduction must preserve coverage of every distinct outcome. For software testing, each remaining rule is a candidate test condition, while boundary tests are added where values include ranges or thresholds.¹

Decision tables are used wherever policies combine multiple inputs, including insurance eligibility, credit assessment, access control, pricing, troubleshooting, and transaction processing. They are also a bridge between requirements and executable business-rule systems: subject-matter experts can inspect the visible rules while developers or rule engines implement them.

The Object Management Group’s Decision Model and Notation (DMN) standard gives decision tables a formal notation within a broader model of business decisions and decision requirements.² DMN tables can define input expressions, permitted hit policies, output values, and the relationship between a decision and the information it depends on. Hit policies determine what happens when several rows match: a table may require a unique match, return all matches, apply a priority, or aggregate results. These semantics distinguish a governed decision model from an informal spreadsheet.

Decision tables can expose defects that ordinary examples conceal, particularly when rules overlap or leave gaps. A table may be syntactically complete yet semantically flawed if two conditions are correlated, if a supposedly independent input is unavailable, or if the action for an impossible combination has been specified accidentally. Reviews therefore examine both logical coverage and the real-world meaning of each combination.

Large tables also suffer from combinatorial growth: two binary conditions create four theoretical combinations, while ten create 1,024 before infeasible cases are removed. Analysts use equivalence classes, risk-based selection, rule minimization, and pairwise or higher-strength combinatorial testing to control this growth. A further edge case occurs when rules change over time. Versioning, effective dates, approval records, and traceability to source policy are then as important as the table’s logic. DMN provides a standardized context for exchanging such decision models, but governance remains an organizational responsibility.²

Condition

An input or circumstance whose value helps determine which rule applies.

Action

An outcome, operation, or recommendation produced when a rule matches.

Rule

A single column or row entry that maps a combination of condition values to one or more actions.

Hit policy

A rule for resolving whether one, several, or prioritized matching rows determine the result.

Don’t-care value

An entry indicating that a condition does not affect the action for a particular rule.