Updated June 30, 2023
Introduction To Decision Table Testing
Decision Table Testing is the process of testing the software application based on the decision table designed specifically for scenarios involving a range of inputs and related test scenarios. Here, the Decision table generates the test conditions for various inputs and the respective test scenarios, as opposed to the output expected for the input data assortment. These Test conditions are then used to break down the high-level Test scenarios into simpler test cases, thus making it easy to organize the testing process for testing multiple permutations and a combination of the input data.
Why are the Decision Tables so Important?
You may be familiar with boundary value testing and equivalent partition testing techniques; while both provide coverage, none will be useful where the system behavior is different for each set of inputs provided.
Creating a decision table helps a testing team in designing tests. Not only are decision tables useful in stating complex business rules, but these tables are also helpful for testers who want to understand how different combinations of inputs affect the output.
In many applications, the number of input combinations can be large; if that’s the case with the project in hand, testing these combinations will prove to be a problem. For cases like these, creating a decision table is one of the better ways to conduct a test with good coverage.
As you will see below, the number of the possible combination is given by 2x where X is the number of inputs; in cases where X is a large number (let’s say 10 for an example), the number of combinations will be too high to take all of these into account. However, we can still take a subset of these possible combinations to create a decision tree.
How to Create A Decision Table for Testing?
Now that you know what decision testing is, let’s create a decision table.
Step 1: Create the first column of the table by understanding the requirements.
We will create the first column of the table by looking at what we need to test. For this example, consider an example of an ATM Transaction. Following would be its conditions and actions:
| Condition |
| The withdrawal amount is less than or equal to the bank balance |
| Credit granted |
| Action |
| Withdrawal Request Accepted |
Step 2: Adding More Columns.
Now that the first column is done, we will calculate the remaining number of columns needed. It will depend on the number of conditions on hand and how many alternatives are available.
Mathematically, the number of columns is 2x, where X is the number of conditions.
For ease of testing, we should create smaller and huge decision tables. Once done with the number of columns, we can fill in True or False. You can fill the cells in the following pattern:
R1: T F
R2: T T F F
R3: T T T F F F
And so on.
Once done, our table now looks like the following:
| Condition | ||||
| The withdrawal amount is less than or equal to the bank balance | T | F | T | F |
| Credit granted | T | T | F | F |
| Action | ||||
| Withdrawal Request Accepted | ||||
Step 3: Make the table smaller.
We can reduce the table by removing any duplicate columns in the table. Another way to reduce the table is by checking for invalid combinations; for example, there is no way someone can be a Male and a Female in a decision table.
We will also have to mark cells with insignificant values with “-“For example, it won’t matter if the credit is granted if the amount is <= Account balance.
| Condition | ||||
| The withdrawal amount is less than or equal to the bank balance | T | F | T | F |
| Credit granted | – | T | – | F |
| Action | ||||
| Withdrawal Request Accepted | ||||
Step 4: Determining the actions for the table.
Now, with the help of our requirements, we will determine the table’s actions. These columns will then be named such as R1 / Rule 1, R2/ Rule 2, etc.
| Condition | |||
| The withdrawal amount is less than or equal to the bank balance | T | F | F |
| Credit granted | – | T | F |
| Action | |||
| Withdrawal Request Accepted | T | T | F |
Final Step: Writing the test cases
Now that the table is reduced and its actions are determined, we can write test cases for it. We should write at least one test case for each column for full coverage of business rules.
For example:
Test Case for R1 : Balance = 1000, Withdrawal Request = 1000. Result: Withdrawal Request Accepted
Test Case for R2 : Balance = 500, Withdrawal Request = 1000. Credit Granted: Yes, Result: Withdrawal Request Accepted
Test Case for R3 : Balance = 1000, Withdrawal Request = 1500. Credit Granted: No, Result: Withdrawal Request Denied
Advantages
Below are mentioned the advantages:
- Decision Table Testing is easy to interpret; hence, these are used for development and business.
- Decision Table Testing helps make effective combinations, and once made, it can provide better coverage for testing.
- It is fairly easy to turn business conditions into decision tables, even if the conditions are complex in nature.
- If the testing team is looking for 100% coverage and the number of input combinations is low, Decision Table Testing is one of the most efficient ways of getting the job done.
- Decision Testing works where boundary value analysis and equivalent partitioning do not, i.e., When the system behavior differs for different inputs.
Conclusion
Decision Table testing is one of the effective black-box testing techniques; while the tables get more complicated with an increasing number of inputs, it can provide decent coverage for situations where other techniques can’t be used.
Recommended Articles
This has been a guide to Decision Table Testing. Here we discuss some concepts, advantages, importance, and how to create a Decision Table for Testing. You can also go through our other suggested articles to learn more –
