In test scripting techniques, for single data fields like textboxes, we often use methods such as equivalence partitioning or Boundary value analysis. For testing the behavior of the system with many data fields, the decision table will help us classify and shape the test scenario more accurately and clearly.
Table of Contents
Using decision tables
Basically, the decision table in testing uses a complex logical model so that it is easy for the user to see the possible combinations of the conditions under consideration and the actions that correspond to the set of values of the condition series.
The most basic example of a decision table is the ATM system: To be able to withdraw money from an ATM, the user needs one of two conditions: the money in the account is still available and it is larger than the amount. wants to withdraw (For Debit Card) or, the user is granted a pre-existing credit (For Credit Card). Verbal expressions like this, sometimes easily confuse us about the actual conditions, not to mention the words “and” and “or”. When we put these conditions in the decision table, we see things much more clearly:
Condition | Case1 | Case2 | Case3 |
| The amount in the account is larger than the amount to withdraw | Yes(T) | False(F) | False(F) |
| Get credit | – | Yes(T) | False(F) |
| System action | |||
| Withdraw | Yes(T) | Yes(T) | False(F) |
Usually, decision tables use logical values to express system conditions and actions. For “true/false” or “true/false”, it is easier to apply logical operations like “and”/”or”.
By listing the conditions and the possible values of each condition, we will be able to ensure that all combinations of conditions appear in the decision table, hence we will ensure that no ignore any test scenario. Moreover, with decision table, we can quickly detect unreasonable requirements, thereby saving us time and effort in executing meaningless test scenarios. On the other hand, we can see that the decision table is not only good for the test engineer, it also has great effects for all members of the software development team, from the product owner. ) when giving ideas, to the programmers for them to create and develop the system.
Decision table example
Step 1 : Analyze system conditions and actions
Going back to the ATM example above, we can see that there are two defining conditions:
- The amount in the account is larger than the withdrawal amount
- Get credit
And there is only one corresponding action of the system: To withdraw or not?
| Condition |
| The amount in the account is larger than the amount to withdraw |
| Get credit |
| System action |
| Withdraw |
Step 2: Add condition’s value case columns
For the above 2 conditions, we will have 4 true/false combinations (2²)
| Condition | Case1 | Case2 | Case3 | Case4 |
| The amount in the account is larger than the amount to withdraw | True(T) | True(T) | False(F) | False(F) |
Step 3: Try to reduce the number of condition columns
Here, we can see that, case 1 and case 2 are almost the same, when the amount in the account is greater than the amount to withdraw, we do not need to care whether the customer is granted credit or not. Therefore, we can reduce one case here, we mark it with “-”
Condition | Case1 | Case2 | Case3 |
| The amount in the account is larger than the amount to withdraw | Yes(T) | False(F) | False(F) |
| Get credit | – | Yes(T) | False(F) |
| System action | |||
| Withdraw |
Step 4: Determine the corresponding action of the system
Based on the condition, we will have the final result:
Condition | Case1 | Case2 | Case3 |
| The amount in the account is larger than the amount to withdraw | Yes(T) | False(F) | False(F) |
| Get credit | – | Yes(T) | False(F) |
| System action | |||
| Withdraw | Yes(T) | Yes(T) | False(F) |
Step 5: Write test scripts
In this step, we start to detail the steps and set up the test data for the test scenario.
Thank you for reading, if you want more article about Manual test, please check this link.
