Decision Table Testing with Examples

Business requirements often hide combinations inside sentences. A promotion may require an active account, a qualifying order total, and a valid region. A decision table lists each condition, identifies possible values, and maps feasible combinations to actions.

The table exposes omissions and contradictions before execution. If two rules describe the same conditions but different actions, the requirement needs clarification. If a realistic combination has no action, coverage is incomplete.

A complete table lists all combinations, which grows quickly as conditions increase. A limited-entry table commonly uses yes, no, and “does not matter” values to collapse rules when a condition cannot affect the outcome.

Simplification must preserve behavior. Combine columns only when they produce the same actions and the removed distinctions truly do not matter. Keep impossible combinations visible or document why they are excluded.

Each feasible rule becomes at least one test case. The case supplies concrete data that satisfies the condition combination, executes the decision, and verifies every expected action—including actions that should not occur.

Decision tables handle combinations, not sequence. If the order of events or current state changes behavior, add state transition testing or workflow coverage.