Decision tables help when behavior depends on several conditions together. QA organizes combinations systematically and sees which rules are covered and which remain untested.
When the technique is especially useful
- →Several input conditions jointly determine the outcome.
- →Textual logic becomes difficult to follow in detail.
- →Conflicting or rare combinations matter alongside the happy path.
- →Team members may interpret the same rule differently.
Building a decision table
- →List conditions that affect behavior.
- →Identify their possible states: yes/no, valid/invalid, role A/role B, and so on.
- →Record the expected action for every meaningful combination.
- →Remove impossible or irrelevant combinations to keep the table tied to actual behavior.
Example
Consider checkout governed by three factors: stock availability, an authenticated user, and confirmed payment. A decision table clarifies when an order can be created, when login is required, and when the operation must be blocked more clearly than a tangled prose description.
Common mistakes
- →Including every conceivable state without considering relevance.
- →Failing to distinguish impossible combinations from real ones.
- →Describing system actions vaguely without concrete expectations.
- →Creating an attractive table without turning its rules into executable checks.
Decision tables turn vague business rules into a transparent decision map. They are particularly valuable in fintech, e-commerce, access control, discounts, pricing plans, and workflow systems.
Worked decision table: a membership discount
Fictional rule: apply a 10% discount only when the customer is a member AND the order subtotal is at least 100 whole currency units. Otherwise apply no discount. Subtotal is already validated, tax and delivery are excluded, and the examples use whole amounts to avoid an unspecified rounding policy.
Rule Member? Subtotal >= 100? Example subtotal Discount Amount after discount
R1 No No 80 0% 80
R2 No Yes 120 0% 120
R3 Yes No 80 0% 80
R4 Yes Yes 120 10% 108Two independent Boolean conditions produce four combinations; all four are feasible under this specification. The table makes the AND rule explicit: membership alone is insufficient, and a large subtotal alone is insufficient. If a condition is impossible in the real system, record why before removing its rule.
Turn a rule into a test case
Case DT-R4
Preconditions: authenticated member; subtotal 120; no other promotions.
Action: request the order total.
Expected: discount rate 10%; discount amount 12; amount after discount 108.
Control case DT-R2: same subtotal, non-member; discount 0; amount 120.All decision rules being covered does not mean numerical boundaries are covered. Add member subtotals 99, 100 and 101: expected rates are 0%, 10% and 10%. If exact payable amounts can be fractional, first define currency precision and rounding. Keep those checks distinct from whether the discount applies.
Exercise: change AND to OR
Suppose the rule changes to “member OR subtotal at least 100”. Which rows change? R2 and R3 now receive 10%; R1 still receives none and R4 still receives 10%. Expected amounts for the displayed examples become 80, 108, 72 and 108. Recalculate the table before updating tests so the old assumption does not survive unnoticed.