Decision Table Testing: Guide, Examples, and Template (2026)

Last updated: July 17, 2026 · 10 min read · By Avinash Kamble, reviewed by Priyanka G.

Decision Table Testing is the black-box technique that turns tangled if/else logic into a provably complete test suite. When output depends on combinations of conditions — a shipping calculator, a pricing engine, a permissions matrix — a decision table forces you to enumerate every rule and pick a representative test per rule. This guide gives you the definition, the 5-step construction method, a worked shipping-cost example, rule-collapse patterns, and the interview answers to nail decision-table questions.

Use alongside BVA, equivalence partitioning, and the black box testing complete guide.

Key takeaways

• Decision tables shine when output depends on 2+ conditions combined.
• Total rules = 2ⁿ for n binary conditions. Collapse redundant ones.
• One test per rule = 100% rule coverage.
• ISTQB Foundation topic — appears in nearly every mid-level QA interview.

Decision Table Testing (also called Cause-Effect Table Testing) is a black-box technique for systematically testing the behaviour of software that depends on combinations of input conditions. Each column of the table is a rule; each row is either a condition or an action. The table lists every combination, forcing you to derive one test per rule.

The technique originates in Larry Constantine's structured design work in the 1970s and is codified in the ISTQB Foundation syllabus.

• Output depends on 2 or more conditions combined (permissions, pricing, routing).
• Requirements contain phrases like “if X and Y but not Z”.
• You have caught combination bugs in production before.
• Regulators or auditors need documented rule coverage.

For single-condition rules, equivalence partitioning is usually enough. Do not over-engineer.

1. List all input conditions (rows near the top).
2. List all possible actions/outputs (rows near the bottom).
3. Enumerate every combination as columns (rules). For n binary conditions, 2ⁿ columns.
4. Fill in T/F for each condition per rule, and mark which actions fire.
5. Collapse impossible or redundant rules; derive one test case per remaining rule.

Rules: shipping is free if the order is over $50 or the customer is a Prime member. Otherwise, shipping is $5.99. Domestic vs international is a third condition (international always costs $15 extra).

+-----------------------------------------------------------------------+
| DECISION TABLE: SHIPPING COST                                         |
+-----------------------------------------------------------------------+
| Conditions              | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8      |
+-------------------------+----+----+----+----+----+----+----+---------+
| Order > $50             | T  | T  | T  | T  | F  | F  | F  | F       |
| Prime member            | T  | T  | F  | F  | T  | T  | F  | F       |
| International           | T  | F  | T  | F  | T  | F  | T  | F       |
+-------------------------+----+----+----+----+----+----+----+---------+
| Actions                                                               |
+-------------------------+----+----+----+----+----+----+----+---------+
| Base shipping = free    | X  | X  | X  | X  | X  | X  |    |         |
| Base shipping = $5.99   |    |    |    |    |    |    | X  | X       |
| + International $15     | X  |    | X  |    | X  |    | X  |         |
+-----------------------------------------------------------------------+

Eight rules → eight tests. Every combination is covered explicitly, and the developer's implementation can be reviewed row by row against the table. This is the level of rigour that makes decision tables audit-friendly.

Some rules produce the same actions regardless of one condition. Mark that condition with a dash (–) and collapse:

If “order > $50 AND Prime” both grant free shipping, then when “order > $50” is true, Prime doesn't matter. Rules R1+R3 collapse to one rule with Prime = –. Halves your test count without losing coverage.

const rules = [
  { over50: true,  prime: true,  intl: true,  cost: 15  },
  { over50: true,  prime: true,  intl: false, cost: 0   },
  { over50: false, prime: false, intl: true,  cost: 20.99 },
  { over50: false, prime: false, intl: false, cost: 5.99 },
  // ...remaining rules
];
for (const r of rules) {
  test(`shipping ${JSON.stringify(r)}`, async ({ request }) => {
    const res = await request.post('/api/quote', { data: r });
    const body = await res.json();
    expect(body.shipping).toBeCloseTo(r.cost);
  });
}

Data-driven test frameworks like Playwright and REST-Assured love decision tables — they collapse into a single loop. Level up on the REST-Assured tutorial and the API testing Q&A hub.

Almost guaranteed in mid-level (3+ years) QA interviews. Common prompt: “Draw a decision table for a discount rule that gives 10% off for members, 5% for orders over $100, and stacks both.”. Rehearse the whole flow — enumerate, fill T/F, collapse, one test per rule — on the AI Mock Interview. Deep prep on the 3-year experience Q&A hub.

Find one rule-heavy feature in your product (pricing, permissions, notifications). Build the decision table in 30 minutes. Compare it against the developer's implementation. You will find at least one uncovered combination — that is a bug caught before production. Benchmark comp on the QA Salary Guide and audit your resume with the ATS Resume Reviewer.