Test Design: Decision Tables (Part 1)

Decision tables turn business rules into a grid of conditions and actions. Each column is a rule; each row is a condition or an action. This post (Part 1) explains what decision tables are and how to build a basic one from business rules.

What is a decision table?

A decision table has:

• Condition rows: Inputs or situations (e.g. "User logged in?", "Balance > 0?").
• Action rows: Outcomes or behaviors (e.g. "Allow withdrawal", "Show error").
• Columns: Each column is one rule: a combination of condition values and the resulting actions.

You read it as: "If these conditions hold, then these actions occur."

When to use decision tables

Use them when:

• Logic depends on several conditions (e.g. discount rules, eligibility, permissions).
• You want to avoid missing combinations.
• You need a clear, reviewable representation of rules.

They are less useful when the logic is simple or when there are too many combinations (then you may simplify or sample).

Building a basic table

1. List all conditions (inputs, flags, states).
2. List all actions (outcomes, messages, behaviors).
3. For each meaningful combination of condition values, define the expected actions.
4. One column = one rule = one (or more) test cases.

Part 2 covers simplification, coverage, and turning the table into test cases.

Summary

• Decision tables = conditions + actions in a grid; each column is a rule.
• Use them for multi-condition logic (discounts, permissions, eligibility).
• Build by listing conditions and actions, then filling in each rule; one column can map to one or more test cases.