Decision table generator

How it works

The table follows the ISTQB Foundation Level syllabus (version 4.0, section 4.2.3). Conditions and actions are the rows. The full table has one column for every combination of condition values, and each column says which actions should happen. The coverage items are the columns that can actually happen, so the test cases are one per column.

• “Can’t happen” marks a combination as infeasible, such as a locked account that doesn’t exist. It gets no test, and the merging below can treat it as anything it likes.
• “–” in a column means that condition doesn’t change the outcome there. Two columns merge only when they lead to exactly the same actions and differ in one condition, and only when every value of that condition is covered, so a merged column never stands for a combination with a different outcome.
• Undecided combinations are never merged. They are listed as questions instead, because a combination nobody has decided about is a gap in the requirements. Finding those gaps is half the point of the technique.

Why the table isn’t always the smallest possible

Merging is greedy: it combines columns one condition at a time. The result depends on which condition goes first, so the tool tries each one first and keeps the smallest table. That finds small tables, but not always the smallest one, and the page doesn’t claim it has. The syllabus leaves minimisation algorithms out of scope too. What every column here does guarantee is correctness: it never stands for a combination with a different outcome.

In the checkout example, free shipping applies to members or orders of 50 and over. That shape, an L across two conditions, can’t be one column with dashes, so each coupon outcome needs two columns for the orders that ship free plus one for those that don’t: 9 test cases from 12 combinations.

When to use something else

A decision table is exhaustive: its size doubles with every yes/no condition you add. Beyond four or five conditions, split the table by the condition that matters most, or use the pairwise test case generator, which covers every pair of values rather than every combination — the right trade when the conditions are independent settings rather than parts of one rule. For a single field with ranges, such as an age or an amount, use the boundary value generator, and bring its partitions back here as the values of a condition.

The examples are illustrative rules, not taken from a real product. The login conditions come from login page test cases, where the same kind of page is tested against a real site with the results we saw.