Decision table testing
Decision table testing is a test design technique for logic that depends on several conditions at once. The conditions are listed as rows, every combination of their values becomes a column, and each column is given the action the program should take, so that each column is one test case and no combination of the conditions is left unconsidered.
The longer version
A rule like 'free shipping applies to members, or to orders over the threshold, unless the address is abroad' has three conditions and eight combinations, and a tester who tests three of them has tested the rule as they understood it. The decision table forces the rest. The conditions go down the side, the combinations go across, each cell is true or false, and the bottom rows say what happens: shipping is free, shipping is charged, an error is shown. Filling the action row for a column nobody had thought about is where the requirement gets clarified, usually before any test runs.
Where boundary value analysis works on one input's range, decision table testing works on the interaction between several inputs, and they answer different questions: whether the threshold is applied at the right amount is a boundary question, whether the threshold and the membership flag combine correctly is a table question. Each column also reads as one acceptance criterion in given, when, then form, so a criteria list that covers fewer situations than the table has gaps a customer will find.
The table grows by doubling, and a rule with six conditions has sixty-four columns before any are removed. Columns are collapsed where a condition does not matter given the others (a non-member's membership discount is irrelevant), and impossible combinations are struck out with a note saying why. A tester who collapses columns on the assumption that two conditions are independent when they are not has removed the case that fails. A table nobody maintains loses cases more slowly: a new condition is added to the code and the table keeps the old columns.
Common questions
When should decision table testing be used?
Whenever an outcome depends on more than one condition at the same time: pricing rules, eligibility checks, permission logic, validation with several flags. If the requirement contains the words 'and', 'or' and 'unless' in one sentence, a table will find combinations the sentence did not mention and force somebody to say what should happen in them.
What is the difference between decision table testing and boundary value analysis?
Boundary value analysis picks the values to test for one input with a range, around the edges of that range. Decision table testing enumerates the combinations of several conditions and the action each combination should produce. The first asks whether a threshold is applied at the right value; the second asks whether the threshold combines correctly with everything else.
How do you reduce a large decision table?
Collapse columns where one condition makes the others irrelevant, mark combinations that cannot occur as impossible with a note explaining why, and check that each remaining column still maps to a distinct action. The collapsing is where mistakes happen, so a column is only removed when the independence it assumes has been confirmed against the requirement.
How do you create a decision table for testing?
List every condition the rule depends on as a row, write out each combination of true and false as a column, and fill the bottom rows with the action the program should take in that column. Then walk the columns with the product owner, because the columns nobody had considered are where the requirement is silent, and the answer written there is a clarification the tests will hold the code to.
Can a decision table be turned into acceptance criteria?
Each column of the table reads as one acceptance criterion in given, when, then form: given a member with a domestic address, when the order is under the threshold, then shipping is free. A criteria list written first tends to cover the combinations somebody thought of; the table written first covers all of them, so building the table and then extracting the criteria leaves fewer gaps.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.