How to properly test a decision table
There is no universally accepted method for testing decision tables, but there are some general steps that can be followed:
- Identify the purpose of the decision table.
- Draft test cases based on the different conditions and actions in the table.
- Execute the test cases and verify the expected results.
- Modify the decision table as needed based on the results of the tests.
- Repeat steps 2-4 until the decision table is satisfactory.
Choosing the way to test
When choosing the best approach to testing a decision table, the purpose of a decision table should provide guidance. The guidance will help to draft test cases based on the different conditions and actions in the table. Once the test cases are executed, the results should be verified to ensure that the decision table is functioning properly.
There are decision tables that do not have to have a result for every value and the business is okay with that. However, most decision tables are used in a decision flow with the goal of always providing a result.
Action-result not always required
A decision table that is not required to always provide a result is easier to test. In such a case valid ranges of values for each column and the expected result need to be prepared. Next, prepare a synthetic data sample with all the possible combinations and run it through the table.
Action-result required always
If the decision table must always provide a result, then it is advisable to use a different approach. The first step is to determine all the possible conditions and actions that could occur in the table. Then, for each condition and action, prepare test data that will exercise that specific condition or action.
The goal is to go over all possible combinations of conditions and actions. The possible combinations should also consider unexpected extreme values. Then the testing can be done manually or with the help of a tool. After the test data is prepared it is fed into the decision table. The results are then verified to see if they match the expected results.
Gaps in decision results
If there are decision gaps - values for which actions were provided, then it is important to investigate these cases. In case the values for conditions are not important, a catch-all row can be added. A catch-all row in a decision table is a row that has a wildcard character for all conditions. The wildcard character means that the row will be triggered no matter what the value of the conditions is.
Catch-all rows
Catch-all rows are often used for errors, but they can also be used for default values. For a catch-all row, the position in the table is important due to its potential precedence and potential for overriding previous results.
Decision tables can have multiple actions for a single condition. In such cases, the order in which the actions are executed is important. The order can be defined in the decision table or it can be left to the discretion of the decision maker. If the order is important, then it should be defined in the decision table. Otherwise, the order can be left to the discretion of the decision maker.
If the order is important, then it should be tested. The order in which the actions are executed can be tested by changing the order in which the test data is fed into the decision table. The results of the tests should be verified to ensure that the decision table is functioning properly.
Next steps in the testing
If the decision table is part of a decision flow, then all the steps of the decision flow need to be tested. That includes all the decision tables, decision points, and final actions.
