Introduction To Decision Table Testing
Decision Table Testing is the process of testing the software application based on the decision table designed specifically for the scenarios involving a range of inputs and the related test scenarios. Here, the Decision table is used to generate the test conditions for a variety of inputs and the respective test scenarios, as opposed to the output expected for the assortment of the given input data. 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 of these are good at providing coverage, none of them 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 that has 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 are familiar with what decision testing is let’s create a decision table.
Step 1: Creating the first column of the table by understanding the requirements.
We will create the first column of the table by taking a look 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 the hand and also how many alternatives are available for these conditions.
Mathematically, the number of columns is 2x, where X is the number of conditions.
For ease of testing, we should create smaller decision tables then create a huge one. 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: Making the table smaller.
We can reduce the table by removing any duplicate columns in the table. Other ways to reduce the table are checking for invalid combinations in the table; for example, there is no way someone can be both 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 actions of the table. 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 made reduced and its actions are determined, we can write test cases for the table. For full coverage of business rules, we should write at least one test case for each column.
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, and hence these are used for development and business.
- A Decision Table Testing helps in making 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 is different for different inputs.
Conclusion
Decision Table testing is one of the effective black-box testing techniques; while the tables do 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 of the concepts, advantages, importance, how to create Decision Table for Testing. You can also go through our other suggested articles to learn more –
