Decision table testing is a black-box test technique in which test cases are derived from a decision table: a table that lists the conditions of a business rule, the actions that follow from them, and the combinations of condition values that lead to each set of actions. Each combination is a rule of the table, and each rule that can occur in practice becomes at least one test case.
The technique is defined in the international standard ISO/IEC/IEEE 29119-4:2021, Software testing, Part 4: Test techniques (clause 5.2.6, coverage in clause 6.2.6), and in the ISTQB Certified Tester Foundation Level syllabus, version 4.0.1 (section 4.2.3). The same standard describes cause-effect graphing (clause 5.2.7), a related technique described in The Art of Software Testing by Glenford Myers, first published in 1979. Both techniques work with decision rules: ISO/IEC/IEEE 29119-4 defines a decision table as a tabular representation of decision rules that link causes, expressed as Boolean conditions, to effects.
The problem decision tables solve
Business rules are written as sentences: "Members get a discount. Orders from 100.00 are delivered free. Gold members always get free delivery." Each sentence is clear on its own. The questions arise between them: does a Gold member get both discounts, does free delivery apply to a guest, what happens when two sentences contradict each other.
Tests written directly from such text check the cases that the text mentions explicitly. Combinations that the text does not mention remain untested, and they are often the place where the implementation and the expectation differ. A decision table lists every combination of conditions, so each of them receives an explicit outcome or is marked as impossible. The ISTQB syllabus names two results of the technique: it identifies all combinations of conditions systematically, and it helps find gaps and contradictions in the requirements.
Structure of a decision table
Conditions and actions
A decision table has two kinds of rows. Conditions are the inputs of the rule: facts about the data or the situation that determine the outcome, such as "the customer is a registered member" or "the order total is 100.00 or more". Actions are the outputs: what the system does, such as "apply a 10 percent discount" or "deliver free of charge".
Rules
Each column of the table is a decision rule: one combination of condition values and the actions that result from it. ISO/IEC/IEEE 29119-4 describes a decision rule as a combination of conditions and actions that produces a specific outcome. A column is read from top to bottom: "if C1 is true, C2 is false and C3 is true, then perform A2 and A3".
Notation
The ISTQB syllabus v4.0.1 uses the following entries in the cells of a table.
| Entry | Meaning |
|---|---|
| T | The condition is satisfied |
| F | The condition is not satisfied |
| - | The value of the condition is irrelevant for the outcome |
| N/A | The condition is infeasible for the rule |
| X | The action occurs |
| Blank | The action does not occur |
Limited-entry and extended-entry tables
In a limited-entry decision table all condition and action values are Boolean: true or false, apart from irrelevant and infeasible entries. In an extended-entry decision table some conditions or actions take more values, for example ranges of numbers, equivalence partitions or discrete values such as "guest, member, gold member".
An extended-entry table is shorter, because one row replaces several Boolean conditions. Its values are often equivalence partitions, and how such partitions are chosen is described in the article Equivalence partitioning and boundary values.
From the business rule to the full table
The example rule of an online store is:
- registered members get a 5 percent discount, and members with Gold status get 10 percent;
- orders with a total of 100.00 or more are delivered free;
- members with Gold status always get free delivery;
- only registered members can have Gold status.
The rule has three Boolean conditions and three actions. A full decision table contains every combination of condition values. For n Boolean conditions this is 2 to the power of n columns, here 8. For an extended-entry table the number is the product of the numbers of values of all conditions.
The full table of the example is shown below.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| C1 Registered member | T | T | T | T | F | F | F | F |
| C2 Gold status | T | T | F | F | N/A | N/A | F | F |
| C3 Total 100.00 or more | T | F | T | F | T | F | T | F |
| A1 Discount 10 percent | X | X | ||||||
| A2 Discount 5 percent | X | X | ||||||
| A3 Free delivery | X | X | X | X |
Columns 1 to 4 describe members, columns 7 and 8 describe guests. Columns 5 and 6 combine "not a member" with "Gold status", which the rule excludes; the entry N/A in C2 marks this.
Impossible combinations
Columns 5 and 6 are infeasible combinations: combinations of condition values that cannot occur. They appear whenever conditions depend on each other. Typical sources are conditions that exclude each other ("age under 18" and "age 65 or over"), conditions that imply each other ("Gold status" requires "registered member") and conditions on the same value with different thresholds.
The syllabus describes removing infeasible columns as a simplification of the full table. In the example the simplified table has 6 columns. Whether a combination is infeasible is a statement about the system, not only about the rule. If an import or an API can create a guest record with Gold status, the combination can occur, and the table needs a rule for it.
An extended-entry table can remove such combinations by construction. A single condition "customer type: guest, member, gold member" replaces C1 and C2, and the table has 3 times 2, that is 6, columns, all of them feasible.
Decision table coverage
In decision table testing the coverage items are the columns that contain feasible combinations of conditions. Decision table coverage, as the ISTQB syllabus v4.0.1 defines it, is the number of exercised columns divided by the total number of feasible columns, expressed as a percentage. 100 percent coverage requires test cases that exercise all of these columns.
In the example the feasible columns are 1, 2, 3, 4, 7 and 8. Test cases for columns 1, 3, 4, 7 and 8 exercise 5 of 6 feasible columns, which gives 83 percent. Column 2, a Gold member with an order below 100.00, remains unexercised.
The measure depends on the table that is counted. The same five test cases give 100 percent against the collapsed table described below, because there columns 1 and 2 are one column. A coverage figure for a decision table is therefore reported together with the table it refers to.
Collapsing a table
Irrelevant entries
The number of columns of a full table grows exponentially with the number of conditions: 10 Boolean conditions give 1024 columns. The syllabus names two ways to reduce it: a minimized decision table and a risk-based approach.
A table is minimized by merging columns in which some conditions do not affect the outcome. In the example, columns 1 and 2 have the same actions and differ only in C3: for a Gold member the order total does not matter. They are merged into one column with the entry "-" for C3. The collapsed table has five columns.
| R1 | R2 | R3 | R4 | R5 | |
|---|---|---|---|---|---|
| C1 Registered member | T | T | T | F | F |
| C2 Gold status | T | F | F | F | F |
| C3 Total 100.00 or more | - | T | F | T | F |
| A1 Discount 10 percent | X | ||||
| A2 Discount 5 percent | X | X | |||
| A3 Free delivery | X | X | X |
The other columns cannot be merged: each pair differs in at least one action or in more than one condition. Algorithms for minimization are outside the scope of the Foundation Level syllabus.
Risks of collapsing
An irrelevant entry is a claim that the condition does not affect the outcome. A test case for a collapsed column uses one value of that condition, and the other value remains untested. If the implementation gives a Gold member free delivery only from 100.00, a test case for R1 with an order of 150.00 passes. Only an order below 100.00, that is column 2 of the full table, reveals the defect.
Collapsing therefore trades coverage of combinations for a smaller number of test cases. Three practices limit the risk:
- Full table as reference. The full or simplified table is kept, and coverage is reported against it as well as against the collapsed one.
- Both values for high-risk rules. A collapsed column of a rule with high risk is tested with each value of the irrelevant condition.
- Revision on change. When a requirement changes, collapsed columns are expanded again, because a condition that was irrelevant can become relevant.
Columns of a collapsed table must not overlap. If one combination of condition values matches two columns with different actions, the table, and usually the requirement behind it, contains a contradiction.
Rules named by their outcome
Column numbers say nothing about the content of a rule. A name that states the outcome makes the table readable and gives each test case a title that can be checked against the requirement. The names of the collapsed table in the example are:
| Rule | Name |
|---|---|
| R1 | Gold: 10 percent, free delivery |
| R2 | Member, 100.00 or more: 5 percent, free delivery |
| R3 | Member, below 100.00: 5 percent, paid delivery |
| R4 | Guest, 100.00 or more: no discount, free delivery |
| R5 | Guest, below 100.00: no discount, paid delivery |
The name of the rule becomes the title of the test case. A failed test case then points to a business rule rather than to a column number. Links between such test cases and the requirement are described in the article Requirements traceability and coverage.
Test cases from the table
Each column becomes at least one test case. The condition entries become the preconditions and inputs, the action entries become the expected results. Concrete values are taken from the partitions of each condition:
| Rule | Customer | Order total | Expected discount | Expected delivery |
|---|---|---|---|---|
| R1 | Gold member | 40.00 | 10 percent | Free |
| R2 | Member | 100.00 | 5 percent | Free |
| R3 | Member | 99.99 | 5 percent | Paid |
| R4 | Guest | 100.00 | None | Free |
| R5 | Guest | 99.99 | None | Paid |
C3 is a condition on an ordered value, so its values are taken at the boundary: 100.00 for "true" and 99.99 for "false". The table and boundary value analysis thus check both the combinations and the edge of the threshold. For R1 the order total of 40.00 is chosen below the threshold, the case that a defect in the irrelevant condition would affect.
Gherkin scenarios from a table
Gherkin, the language of Cucumber specifications, has a direct counterpart of a decision table. A Scenario Outline (synonym Scenario Template) is a template of steps with parameters in angle brackets. It contains one or more Examples sections (synonym Scenarios), and the outline is run once for each row of the examples table, excluding the header. The optional Rule keyword, part of Gherkin since version 6, represents one business rule.
The mapping is direct. The business rule becomes Rule. The conditions become Given steps, the actions become Then steps, and each column of the decision table becomes a row of Examples. A column with the rule name fills the title of each scenario: the Gherkin compiler substitutes parameters in the name of a scenario outline as well as in its steps.
Feature: Order discount and delivery
Rule: Members get 5 percent and Gold members 10 percent; orders from 100.00 and Gold members get free delivery
Scenario Outline: <rule>
Given a customer of type "<customer>"
And an order with the total <total>
When the customer opens the checkout
Then the discount is <discount> percent
And the delivery is <delivery>
Examples:
| rule | customer | total | discount | delivery |
| Gold: 10 percent, free delivery | gold | 40.00 | 10 | free |
| Member, 100.00 or more: 5 percent, free | member | 100.00 | 5 | free |
| Member, below 100.00: 5 percent, paid | member | 99.99 | 5 | paid |
| Guest, 100.00 or more: no discount, free | guest | 100.00 | 0 | free |
| Guest, below 100.00: no discount, paid | guest | 99.99 | 0 | paid |The file produces five scenarios with the rule names as titles. Infeasible columns produce no rows. A collapsed column produces one row, and the risk described above applies to it in the same way: a second row with the other value of the irrelevant condition restores the full combination.
Decision tables and cause-effect graphing
Cause-effect graphing is a black-box test technique in which test cases are derived from a cause-effect graph. ISO/IEC/IEEE 29119-4 defines the graph as a graphical representation of decision rules that link causes, expressed as Boolean conditions, to effects, expressed as Boolean expressions. Causes and effects are nodes; logical operators connect them, and constraints between causes record that some combinations are impossible.
The technique was described by Myers in The Art of Software Testing; the index of the third edition (2011) lists the graph symbols and constraint symbols, including an exclusive constraint. According to a 2012 survey by Badhera, Purohit and Taruna, cause-effect graphs go back to a 1973 IBM report by W. R. Elmendorf, and Myers gave a procedure that derives a decision table from the graph.
The graph and the table describe the same decision rules. The graph shows how causes combine through intermediate nodes and where the constraints are, which helps when the rule is large. The table lists the resulting combinations column by column, and test cases are taken from it. ISO/IEC/IEEE 29119-4 keeps both as separate techniques with separate coverage measures.
Limits of the technique
A decision table describes one decision at one moment. Several situations are outside its scope:
- Many conditions. The number of columns doubles with each Boolean condition. Beyond a few conditions, collapsing or a risk-based choice of columns is needed, and the coverage of combinations is reduced accordingly.
- Many independent parameters. When parameters do not form one rule, pairwise testing reduces the number of combinations instead.
- Order and history. A table has no notion of a sequence of events. Behavior that depends on the previous state is described by state transition testing.
- Values inside a condition. A table checks combinations, not the values inside each condition; their edges come from boundary value analysis.
Decision tables and related techniques
The table compares decision table testing with the techniques it is most often combined or confused with.
| Technique | Test model | Coverage items |
|---|---|---|
| Equivalence partitioning | Partitions of one data element | Partitions |
| Decision table testing | Conditions, actions, rules | Feasible columns |
| Cause-effect graphing | Graph of causes, effects and constraints | Decision rules of the graph |
| Pairwise testing | Independent parameters and values | Pairs of values |
| State transition testing | States, events, transitions | States or transitions |
Equivalence partitioning provides the values of the conditions, and the decision table combines them. Cause-effect graphing reaches the same decision rules from a graph instead of a list.
Pairwise testing and decision tables answer different questions. A decision table assumes that the outcome depends on a known combination of conditions and covers all such combinations. Pairwise testing assumes that the parameters are largely independent and covers only every pair of values.
Terms
| Term | Meaning |
|---|---|
| Decision table testing | Black-box test technique in which test cases are derived from the feasible rules of a decision table |
| Decision table | Table of conditions, actions and rules that shows which actions follow from each combination of conditions |
| Decision rule | Column of a decision table: one combination of condition values and the actions that result from it |
| Limited-entry decision table | Decision table in which all conditions and actions take Boolean values |
| Extended-entry decision table | Decision table in which some conditions or actions take more than two values, such as partitions |
| Full decision table | Decision table that contains every combination of condition values |
| Infeasible combination | Combination of condition values that cannot occur in the system |
| Decision table coverage | Number of exercised feasible columns divided by the total number of feasible columns, as a percentage |
| Minimized decision table | Decision table in which columns whose outcome does not depend on some conditions are merged using irrelevant entries |
| Cause-effect graphing | Black-box test technique in which test cases are derived from a graph of causes, effects and their constraints |
Sources
- ISTQB Certified Tester Foundation Level Syllabus v4.0.1, section 4.2.3, ISTQB, 2024(opens in a new tab)
- ISTQB Glossary(opens in a new tab)
- ISTQB Glossary mirror: decision table testing, imbus(opens in a new tab)
- ISTQB Glossary mirror: cause-effect graphing, imbus(opens in a new tab)
- ISO/IEC/IEEE 29119-4:2021, Software testing, Part 4: Test techniques, ISO(opens in a new tab)
- The Art of Software Testing, 3rd Edition, Glenford J. Myers, Tom Badgett, Corey Sandler, Wiley, 2011(opens in a new tab)
- Fault Based Techniques for Testing Boolean Expressions: A Survey, Badhera, Purohit, Taruna, arXiv, 2012(opens in a new tab)
- Gherkin reference, Cucumber(opens in a new tab)
- Gherkin parser and pickle compiler, cucumber/gherkin, GitHub(opens in a new tab)