Decision tables are one of the more powerful functional testing methods, partly due to their logical decision-making structure. Here is how they work:
- Conditions are identified as inputs; actions are identified as outputs.
- In certain cases, the conditions are equivalence classes.
- For every possible combination of inputs, the output is identified and marked.
The size of a decision table is greatly impacted by the choice of conditions. Thus, the conditions have to be identified wisely.
Pretty straight-forward thus far. Decision tables involving equivalence classes have a characteristic appearance.
But people often make mistakes when the conditions refer to equivalence classes. Particularly when the equivalence classes are mutually exclusive, and are disjoint sets. As such, it is not possible to have a rule where two entries are true. For a particular rule if one equivalence class is marked true, it doesn’t matter what the other classes are marked – don’t care entries. Thus, the number of rule count increases.
This creates a problem.
Let’s say we have a decision table as shown below, where c1, c2, c3 refer to conditions and a1, a2, a3 refer to the actions. And we have Rule 1-4 identical to that of rule 9. Let’s say we have two versions of this table. Although version 1 is redundant, it does not have a problem. In the second table there is a problem. Because, in addition to being redundant, the two redundant rules (1-4) and 9 are not identical – their action portion differs.
Frist Version. Second Version
This problem of redundancy and inconsistency creates tremendous strain on the part of a developer. In cases such as that of version two, two observations can be made:
- Rules 1-4 are inconsistent with that of rule 9.
- The decision table is nondeterministic.
Here is the bottom line: Care Should Be Taken When Do-Not-Care-Entries Are Used in A Decision Table.
This is the drawback of decision-table based testing, because of the dependencies in input domain. On the other hand, the benefits of decision-based testing are that indiscriminate selection of input values from equivalence classes as done in other testing methods such as boundary-value testing (this is done when the variables are assumed to be independent) are not made here. In a decision table, impossible rules are emphasized with the use of don’t-care-entries and the use of impossible-actions.
In summation, decision-table based testing should be used for applications that indicate these characteristics:
- Prominent if-then-else logic.
- Logical relationship among input variables.
- Calculations involving subsets of the input variables.
- Cause-and-effect relationships between inputs and outputs.
Jorgensen, Paul C. “Decision Table Based Testing.” Software Testing: A Craftsmen’s Approach, 4Th Edition. New York: Auerbach Publications, 2013. Safari Books Online. Web. 7 Mar. 2016.