Decision table testing, worked example (ISTQB Foundation 4.2.3 style)

A worked decision-table test design in the style of the ISTQB Foundation syllabus section on decision table testing: three conditions, a free-shipping rule, eight combinations, and the smaller set of test cases that covers every business rule.

The rule is (over_50 OR prime) AND NOT oversized: shipping is free for an order over fifty or from a Prime customer, unless the parcel is oversized. With three Boolean conditions the full decision table has eight columns, one per combination, and the engine's truth table below is exactly that table with the action row computed rather than filled in by hand. Three columns give free shipping: over fifty and not oversized, Prime and not oversized, and both and not oversized.

The syllabus method is to write the conditions as rows, enumerate the combinations as columns, fill in the actions, and then collapse columns whose outcome does not depend on a condition. Here, every oversized column has the same action regardless of the other two conditions, so the four oversized columns collapse to one rule: oversized means no free shipping. The remaining four columns stay distinct: no qualification, over fifty, Prime, both.

Each surviving column becomes at least one test case with its expected result taken from the rule's statement, not from running the code. That gives five test cases where exhaustive testing would use eight; for a rule with six conditions the difference is sixty-four against a handful. The exact checks on the page confirm the rule is contingent and show a witness row, and the pattern page on eligibility rules has the same shape with two more conditions.

Example

free_shipping := (over_50 OR prime) AND NOT oversized · output

Exact checks

Always true (tautology)? No Counterexample: over_50 = F, prime = F, oversized = F · Exhaustively checked and solver cross-checked · 1 rows

Always false (contradiction)? No Counterexample: over_50 = F, prime = T, oversized = F · Exhaustively checked and solver cross-checked · 3 rows

Can be true? Yes Example assignment: over_50 = F, prime = T, oversized = F · Exhaustively checked and solver cross-checked · 3 rows

Truth table (8 rows)

Decision table testing, worked example (ISTQB Foundation 4.2.3 style)
#	over_50	prime	oversized	free_shipping
0	FALSE	FALSE	FALSE	FALSE
1	FALSE	FALSE	TRUE	FALSE
2	FALSE	TRUE	FALSE	TRUE
3	FALSE	TRUE	TRUE	FALSE
4	TRUE	FALSE	FALSE	TRUE
5	TRUE	FALSE	TRUE	FALSE
6	TRUE	TRUE	FALSE	TRUE
7	TRUE	TRUE	TRUE	FALSE

Plain-language reading

Beginnerfree_shipping is true exactly when both of the following hold:
1. at least one of over_50 or prime is true (both may be true)
2. oversized is false
In every other case, free_shipping is false.
About the operators:
- AND is true only when all of its parts are true.
- OR is inclusive: it is true when at least one part is true, including when several are.
- NOT reverses a value: true becomes false and false becomes true.

Intermediatefree_shipping is true exactly when both of the following hold:
1. at least one of over_50 or prime is true (both may be true)
2. oversized is false
In every other case, free_shipping is false.

Advancedfree_shipping is true exactly when both of the following hold [conjunction ∧]:
1. at least one of over_50 or prime is true (both may be true) [inclusive disjunction ∨]
2. oversized is false [negation ¬]
In every other case, free_shipping is false.
Formal notation: (over_50 ∨ prime) ∧ ¬oversized

Logic diagram

The common slip

Collapsing a column by eye because the condition “looks irrelevant”. When Oversized is TRUE the other conditions are irrelevant to the outcome; when it is FALSE they matter. Collapse by comparing outcomes across the truth table, which is what the engine's table is for.

Questions

Why not just test all eight combinations?

For three conditions you can, and the engine's table gives the expected results. The method matters when conditions multiply: the collapsed table keeps the test count close to the number of distinct business rules rather than to 2 to the power n.

Where do expected results come from?

From the rule's statement. The truth table is the rule's statement made exhaustive; a test suite whose expectations were produced by running the implementation would pass on a buggy implementation.

Testing and rules

Generated from the Tangibool engine, semantics tangibool-semantics/1, engine 1.0.0, build 2026-11-07. Every table, map, simplification and verdict on these pages was computed by the Tangibool engine when the site was built, and every claim was re-checked by the same exact checker the app uses. Limits are stated where they apply. © 2026 Foreranger LTD.