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

Last updated: July 17, 2026 · 10 min read · By Avinash Kamble

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.

Decision tables in 2026 are rarely drawn on paper. They live as data-driven test fixtures in code, are cross-checked with property-based generators, and, in regulated industries, are exported as audit artefacts. Below is the 3-tier pattern elite QA teams use.

Property-based cross-check example (TypeScript + fast-check)

import fc from 'fast-check';
import { computeShipping } from './shipping';
import { shippingRules } from './shipping.rules.json';

test('every random input matches the decision table', () => {
  fc.assert(fc.property(fc.record({
    over50: fc.boolean(),
    prime: fc.boolean(),
    intl: fc.boolean(),
  }), (input) => {
    const rule = shippingRules.find(r =>
      r.over50 === input.over50 && r.prime === input.prime && r.intl === input.intl
    );
    expect(computeShipping(input)).toBeCloseTo(rule!.cost);
  }));
});

This gives you both rule coverage (from the table) and fuzz coverage (from the generator) — catches implementation drift the table alone would miss.

Audit-ready export pattern

In fintech/healthcare, regulators want proof that every rule was tested in the release. Add a CI job that:

1. Reads the decision-table JSON fixture.
2. Reads the test-run JSON output.
3. Emits a CSV with columns: rule id, expected action, actual action, pass/fail, run id, git sha.
4. Uploads the CSV as a build artifact and attaches it to the release notes.

Common interview follow-ups

• How do you keep the table and the code in sync? Store the table as a JSON fixture. Both the implementation and the tests read the same file — drift becomes impossible.
• How large can a decision table get before it is unmanageable? ~64 rules (6 binary conditions). Beyond that, split into sub-tables per business area or switch to a rules engine (Drools, JSON Logic).
• When would you skip a decision table? Single-condition rules — equivalence partitioning is sufficient. See equivalence partitioning worked examples.