In the previous blog post, we learned about two important test case design techniques such as Equivalence partitioning, and Boundary value analysis. These techniques are mainly used to test individual input conditions. However decision table testing allow us to examine combinations of conditions.
Decision table testing is a black box design technique in which test cases are designed to execute the combinations of inputs defined in the decision table.
So what is a decision table?
It is a table showing combinations of inputs and/or causes with their associated outputs and/or actions (effects), which can be used to design test cases.
These definition seems quite confusing.
Lets examine some of the examples for decision table testing.
Consider the following sample business requirement:
A company’s employees are paid bonuses if they work more than a year in the company and achieve individually agreed targets.
Try to list out all the conditions and actions mentioned in the requirements. Hopefully you would have listed out the conditions as listed below.Achieved target?
- Employment for more than 1 year?
- Agreed target?
- Achieved target?
Actions / Outcome :
- Bonus payment?
With all these details, lets draw the decision table.
In the given requirement, there are 3 different conditions. Each of these conditions have two options (YES/NO). Hence the total number of possible combinations are 8 (i.e. 23).
If there are 6 conditions and each with 5 different options , then the total number of combinations will be 15,625 (i.e. 56).
How to identify test cases from decision table?
In a decision table, conditions consider as inputs and actions as outputs. Each rule can be interpreted as a test case. In this way decision table testing ensures complete coverage.
However in the above decision table, few rules wouldn’t occur in real situation. Hmm.
Are you able to identify those rules in the table?
Can we collapse the decision table to remove unlikely combinations?
Look at Rules R5 and R6 in the table above. These rules are not making sense in the real world scenario (i.e. Achieving without agreeing target). Hence this can be eliminated from testing.
Collapsed decision tables are a risk-based technique in which we reduce the full decision table and concentrate on the most likely and highest risk conditions and outcomes and remove combinations that are simply not possible.
This requires very good understanding on business requirements in order to minimize the risk of eliminating something we actually need to test.
Decision table technique is predominantly use to test the if–then–else logic in programs. This technique is commonly applied for the integration, system and acceptance test levels.
Finding all the interacting conditions can be challenging, particularly when requirements are not well defined.
Typical defects found in decision table testing include incorrect processing based on particular combinations of conditions which results in unexpected results.
During the creation of the decision tables, defects may also be found in specification documents. The most common types of defects are
- omissions (there is no information regarding what should actually happen in a certain situation)