Black Box · Specification-Based

Decision Table Testing

Map every combination of conditions to their expected actions in a table. Each column is a test case. This technique is the gold standard for testing complex business rules.

Junior Senior ISTQB CTFL v4.0 — 4.2.3

What it is

A decision table is a matrix that systematically covers all combinations of input conditions and shows what action should result from each combination. It forces you to think about every scenario — including the ones you'd otherwise miss.

It's most useful when: multiple conditions interact, business rules are complex, or you need to prove exhaustive coverage to stakeholders.

Table structure

  • Conditions (rows, top half) — the inputs or rules that can be true or false.
  • Actions (rows, bottom half) — what the system does in response.
  • Rules (columns) — each column is one combination of conditions. Each column = one test case.

For N binary conditions, the full table has 2N columns. 3 conditions = 8 test cases. Many can be merged when the action is identical regardless of one condition's value.

Worked example

A discount system: users get a discount if they are a member AND their order total is > $100. Members always get free shipping; non-members only get free shipping on orders > $100.

Discount & shipping decision table
Condition / Action Rule 1Rule 2Rule 3Rule 4
Is member?YYNN
Order > $100?YNYN
Apply discount?YesNoNoNo
Free shipping?YesYesYesNo

Each column (Rule 1–4) maps directly to a test case with defined inputs and expected outcomes. No ambiguity, no missed scenarios.

Reducing the table

When an action is the same regardless of one condition's value, you can collapse columns using a "don't care" value (often written as or *). This reduces test count while maintaining coverage.

In the example above, free shipping for members applies regardless of order total — Rules 1 and 2 could be merged for the free-shipping action.

ISTQB mapping

ISTQB CTFL v4.0 reference
RefTopicLevel
4.2.3Decision Table TestingCTFL Foundation
FL-4.2.3 K3Apply decision table testing to derive test casesFoundation LO
CTAL-TA 3.2.3Advanced decision tables, minimisation, cause-effectAdvanced / Senior

When to use it

  • When there are 2–5 conditions with interactions that matter
  • When business logic is defined as "if A and B but not C, then..."
  • When you need to show a stakeholder you've covered all scenarios
  • As a precursor to test case writing — the table is your test design

Avoid for simple cases: If there's only one condition, use EP/BVA instead. Decision tables shine with 2+ interacting conditions.

NZ example — GST pricing rules

New Zealand GST (Goods and Services Tax) is 15%. An e-commerce checkout must apply GST correctly based on two conditions: whether the customer is GST-registered (they can claim it back) and whether the product is GST-exempt (some items like financial services are exempt).

NZ GST decision table — 4 rules, 4 test cases
Condition / Action Rule 1Rule 2Rule 3Rule 4
Customer is GST-registered?YYNN
Product is GST-exempt?NYNY
Show priceEx-GSTGST-exemptGST-inclusiveGST-exempt
Add GST line item?YesNoNoNo

Each rule = one test case. The decision table ensures all four combinations are covered. A common bug is that GST-registered customers get charged GST on exempt products (Rule 2 missing or wrong).

Try it yourself

NZ online store — free shipping decision table

A NZ online store gives free shipping based on two conditions: (A) customer has an active loyalty card, (B) order total is $75 or more. The condition rows are filled in for you — complete the action rows by selecting Yes or No for each rule.

Condition / Action Rule 1Rule 2Rule 3Rule 4
Loyalty card? YYNN
Order ≥ $75? YNYN
Free shipping?
Loyalty discount?
Completed decision table:
Condition / ActionRule 1Rule 2Rule 3Rule 4
Loyalty card?YYNN
Order ≥ $75?YNYN
Free shipping?YesYesYesNo
Loyalty discount?YesYesNoNo

Free shipping: loyalty card OR order ≥ $75 (either condition is sufficient).
Loyalty discount: loyalty card only (regardless of order total).