Overview
Decision table testing is a software testing technique used to test system behaviour for different input combinations. This is a systematic approach where the different input combinations and their corresponding system behaviour (Output) are captured in a tabular form. That is why it is also called as a Cause-Effect table where Cause and effects are captured for better test coverage.
Why Decision Table Testing is important?
- In Software Testing, boundary value analysis and equivalent partitioning are other similar techniques used to ensure better coverage.
- They are used if the system shows the same behaviour for a large set of inputs.
- However, in a system where for each set of input values the system behaviour is different, boundary value analysis and equivalent partitioning technique are not effective in ensuring good test coverage.
- In this case, decision table testing is a good option. This technique can make sure of good coverage, and the representation is simple so that it is easy to interpret and use.
- This table can be used as the reference for the requirement and for the functionality development since it is easy to understand and cover all the combinations.
- The significance of this technique becomes immediately clear as the number of inputs increases. Number of possible Combinations is given by 2 ^ n, where n is the number of inputs.
Use Case of Decision Table Testing:
How to make Decision Table for Login Screen
Let’s create a decision table for a login screen
Email- ************.com
Login- XYZ
Password-########
The condition is simple if the user provides correct username and password the user will be redirected to the homepage. If any of the input is wrong, an error message will be displayed.
| Conditions | Case 1 | Case 2 | Case 3 | Case 4 |
| Username | F | T | F | T |
| Password | F | F | T | T |
| Output | E | E | E | H |
Notations:
- T – Correct username/password
- F – Wrong username/password
- E – Error message is displayed
- H – Home screen is displayed
Interpretations:
- Case 1: Username and password both were wrong. The user is shown an error message.
- Case 2: Username was correct, but the password was wrong. The user is shown an error message.
- Case 3: Username was wrong, but the password was correct. The user is shown an error message.
- Case 4: Username and password both were correct, and the user navigated to homepage.
While converting this to test case, we can create 2 scenarios:
- Enter correct username and correct password and click on login, and the expected result will be the user should be navigated to homepage.
And one from the below scenarios:
- Enter wrong username and wrong password and click on login, and the expected result will be the user should get an error message.
- Enter correct username and wrong password and click on login, and the expected result will be the user should get an error message.
- Enter correct username and wrong password and click on login, and the expected result will be the user should get an error message.
Conclusion:
When the system behaviour is different for different input and not same for a range of inputs, both equivalent partitioning, and boundary value analysis won’t help, but decision table can be used.
This table will help to make effective combinations and can ensure a better coverage for testing. Any complex business conditions can be easily turned into decision tables.
In a case we are going for 100% coverage typically when the input combinations are low, this technique can ensure the coverage.
