decision-table-test-design

Overview

Per ISTQB CTFL Syllabus v4.0.1 §4.2.3, "decision tables are used for testing the implementation of requirements that specify how different combinations of conditions result in different outcomes" and are "an effective way of recording complex logic, such as business rules." This skill walks that derivation end to end: spec in, human-readable manual test cases out (step/expected tables, not code).

All syllabus claims below come from that v4.0.1 PDF (2024-09-15 revision); later references cite it as §4.2.3 without repeating the URL. One worked example (a shipping-fee rule) is carried through every step.

When to use (and when EP/BVA wins)

Use a decision table when the spec is business-rule logic with interacting conditions - the outcome depends on the combination of conditions, not on any single condition alone (pricing, discount stacking, eligibility, approval routing, feature gating). §4.2.3 names a second use: the technique "provides a systematic approach to identify all the combinations of conditions, some of which might otherwise be overlooked" and "helps to find any gaps or contradictions in the requirements", so a reviewer can also run it to check a spec for completeness.

Prefer equivalence partitioning / boundary value analysis instead when a single input's range drives the behavior (e.g. "age must be 18-120"): EP/BVA exercises the edges of one partition; a decision table exercises the cross-product of several conditions. The two compose - derive the rule columns here, then hand each numeric threshold (like the $50 below) to boundary-value-generator for edge values. For a broad first-pass matrix across many lenses rather than one technique in depth, use test-case-ideation-from-story.

Worked example spec (used in every step)

Shipping fee rules. Premium members always ship free (standard or express). Non-members: standard shipping is free for orders of $50 or more, otherwise $5.99; express shipping is a flat $14.99. Express is only offered at checkout for orders of $50 or more (courier minimum).

Step 1 - Identify conditions and actions

Per §4.2.3, "the conditions and the resulting actions of the system are defined. These form the rows of the table. Each column corresponds to a decision rule that defines a unique combination of conditions, along with the associated actions."

Extract from the spec:

Guidance: make each condition atomic (one yes/no question) and independently settable by a tester. "Member with a large order" is two conditions, not one. Every distinct outcome in the spec becomes an action row; if an outcome appears in the spec but in no action row, you mis-extracted.

Step 2 - Build the full table (2^n columns)

"A full decision table has enough columns to cover every combination of conditions" (§4.2.3). For n Boolean conditions that is 2^n columns; here 2^3 = 8.

Notation, per the same section: T means the condition is satisfied, F not satisfied, a dash (written - here) means the condition's value "is irrelevant for the action outcome", and N/A means the condition "is infeasible for a given rule". For actions, X means the action should occur and blank means it should not. The syllabus adds that "other notations may also be used."

Fill every column mechanically from the spec:

R3 and R7 already smell: the spec says express is only offered at $50 or more, so "express selected on a sub-$50 order" may not be reachable. Mark them ? for now; Step 4 resolves it. Do not skip building the full table: the mechanical cross-product is what surfaces the overlooked combinations §4.2.3 warns about.

Step 3 - Collapse with irrelevant (dash) entries

The table "can also be minimized by merging columns, in which some conditions do not affect the outcome, into a single column" (§4.2.3). (Formal minimization algorithms are explicitly "out of scope of this syllabus"; pairwise inspection is enough at this scale.)

A merge is legal only if every expansion of the dash is feasible and produces identical actions.

• R2 + R4 (member, standard): free either way; C2 does not affect the outcome. Merge into one column with C2 = -. Legal.
• R1 + R3 (member, express) and R5 + R7 (non-member, express) look mergeable on the same logic, but R3 and R7 are the columns flagged ? in Step 2. Hold both merges until the feasibility check.

Step 4 - Spot infeasible combinations

"The table can be simplified by deleting columns containing infeasible combinations of conditions" (§4.2.3).

Re-read the spec for constraints that make condition combinations unreachable. Here: express is never offered below $50, so C3 = T with C2 = F cannot occur. R3 and R7 are infeasible; delete them. That kills the held merges from Step 3: C2 is not irrelevant in the express columns, because only one of its values is reachable there. A naive R1 + R3 merge would have produced a test case for an impossible state.

Final collapsed table (5 feasible columns):

The infeasible columns are not test-less: add one constraint check outside the table that verifies the infeasibility itself holds (the express option is absent from checkout below $50). If that check fails, the table must be rebuilt with R3/R7 feasible.

Step 5 - One test case per remaining column

Per §4.2.3, "the coverage items are the columns containing feasible combinations of conditions", 100% coverage means test cases "exercise all these columns", and "coverage is measured as the number of exercised columns, divided by the total number of feasible columns". Here: 5 feasible columns = 5 coverage items; the 5 cases below = 100% decision table coverage (5/5).

For a dash entry, pick one concrete value (P2 below uses $20; pairing with BVA would add $49.99/$50.00 around the threshold).

Each row expands into a full runnable script (preconditions, per-step expected results, sign-off) via manual-test-script-author; this skill's output is the derivation plus the case table above.

Extended-entry tables and anti-patterns

The limited-entry vs extended-entry table forms (when to collapse correlated numeric conditions into one row) and the technique's anti-patterns table are in references/decision-table-details.md.

Limitations

• Stateless rules only. Decision tables model input-combination logic. If the outcome depends on history (what happened before this event), use state-transition-test-design.
• Combination coverage, not boundary coverage. A column says "total >= $50 is true"; it does not test $49.99 vs $50.00. Pair each threshold with boundary-value-generator.
• Minimization is informal here. Formal minimization algorithms are out of CTFL scope per §4.2.3; for large tables expect to lean on risk-based selection rather than perfect minimal form.

References

• ISTQB CTFL Syllabus v4.0.1, §4.2.3 Decision Table Testing - istqb.org PDF (official syllabus, fetched 2026-06-10; all quoted phrases above are from this section).
• ISTQB Glossary term "decision table testing" exists at glossary.istqb.org but the site blocks non-browser fetches; cite the syllabus section above as the stable source.
• Siblings: state-transition-test-design (stateful behavior), manual-test-script-author (expands derived cases into runnable scripts).
• Neighbors this skill is distinct from: test-case-ideation-from-story, boundary-value-generator, test-case-anatomy-reference.