Decision Table. How Can You Use It in Software Testing?

Decision Table Testing – also referred to as a Cause-Effect Table – is an efficient way to evaluate a system's behavior in response to a variety of input combinations. It is a well-known technique for developing black box test scenarios for complex business logic. But can you benefit from it in software testing as well?

Table of contents:

1. What is a Decision Table?
2. How to use a Decision Table?
3. How does the Decision Table improve software testing?

What is a Decision Table?

We frequently find ourselves in situations in which the “next” action is determined by multiple input combinations. For instance, if you are applying for a loan, your eligibility will be determined by several factors such as your age, your monthly salary, your debt, existing credit card history, and so on. As a result, these combinations are referred to as business logic, and they underpin the application's functionality. 

A Decision Table is a data structure that is used to model complex business logic. Through Decision Table Testing, they can be converted to test cases and test scenarios. The method illustrates the causes and effects, functioning as a perfect tool for verifying the relationship between two or more inputs. Decision Table ensures complete coverage of all test cases, which significantly reduces rework associated with the creation of test cases and test scenarios.

How to create a decision table and use it in software testing?

The Decision Table is also a software testing technique, widelly used to evaluate the behavior of the system under various input combinations. It is referred to as the cause-effect table due to an associated logical diagramming technique known as cause-effect graphing, which is used to generate the Decision Table. Thanks to that, it can be successfully used when the software's behavior is dependent on a large number of logical decisions. 

It’s worth mentioning that techniques of black box testing are applicable at all test levels (Component Testing, Component Integration Testing, System Testing, and Unit Testing).

There are a few essential rules to follow when it comes to Decision Table Testing:

1. Any gaps in understanding of the system requirements must be addressed, and the tester should ensure that specifications are sufficiently detailed to enable the successful creation of a black-box test case.
2. The most difficult part is writing test cases that are sufficiently effective at detecting defects (remember, we don't know the internal design!).
3. Happy Paths – These are critical business scenarios in which we provide positive feedback. Additionally, happy paths consist of the most frequently encountered steps. For instance, if I provide a valid user id and password, I will be able to login successfully.
4. Alternative Courses of Action – These are critical business scenarios involving positive inputs. However, these are not the most frequently used steps. For instance, I should be able to log in automatically if my session does not expire without having to enter my user id and password again!
5. Negative Paths – These are business scenarios in which we provide negative inputs and expect the system to generate an error message (of course, one that is user-friendly!).
6. We must adjust our execution to place a greater emphasis on the problematic areas. Additionally, we conduct a review of our test coverage and techniques for which we are unable to find bugs.
7. Defects Logging and Closure – The final step is to log the defects and retest them after they have been resolved.

Why is it necessary to have a Decision Table?

A Decision Table is an excellent technique for managing testing and requirements. Several reasons for the importance of the Decision Table include the following:

• It enables testers to investigate the effects of various input combinations and other software states that implement business rules.
• Using this technique, any complex business flow can be easily converted into test scenarios and test cases.
• Iterative Decision Tables are used. As a result, the first iteration's table is used as the input table for the subsequent tables. Iteration is performed only if the initial table is insufficient.
• It ensures complete coverage of test cases, thereby reducing rework associated with writing test scenarios and test cases.
• It aids the developer in performing a better job during the development process. Testing all possible combinations may be impractical. It is the best option for testing and requirement management.
• It is a structured exercise used to develop requirements for complex business rules. Additionally, it is used to model complicated logic.

Read: How To Write a QA Report? A Brief Instruction

How to use decision table in software engineering?

A Decision Table is a table that depicts the relationship between inputs and rules, cases, or test conditions. Let’s take a closer look at one of the most quoted examples of Decision Table usage.

EXAMPLE 1: Website Login

1. Test Scenario: A Decision Table for a login screen that requires a User Id and Password.

2. The Condition: The user is redirected to the homepage if he enters the correct user name and password, and an error message is displayed if the user enters the incorrect information.

3. As a result the following variables are possible: is the username correct (Y/N)? Is the password correct (Y/N)? Is the only element correct? All those combinations should be placed visually in the table to generate all possibilities of condition combinations. 

 T (true): Username/password is correct

F (false): Username/password is incorrect

E: A message indicating an error is displayed

H: Successful display of the Home Screen

4. We discovered four possible outputs (cases) of the tested scenario: 

• #1: Both username and password are wrong, resulting in displaying an error message (error_1)
• #2: Correct username and incorrect password also results in an error message (error_2)
• #3: Correct password and incorrect username results in an error message as well (error_3)
• #4 (Success): The user's username and password are both correct, and the user is directed to the website's homepage.

5. Now it's time to establish a successful path (#4), and distinguish it from the failed ones (#1-#3). All paths can be now used as the software logic, testing app behavior and predictability. Any new paths - wherever on the client’s or user’s side should be tested through the Decision Table. 

EXAMPLE 2: Taking a bank loan

1. Test Scenario: Decision Table for a banking application that prompts users to complete an online personal loan application.

2. The Condition: The application will display in real-time whether the loan will be approved, rejected, or requires a visit to the branch for additional documentation and discussion based on the inputs.

As a result, the application is governed by the following business rules:

• If you are salaried and earn more than or equal to $75,000 per month, your loan will be approved.
• If you are salaried and earn between $25,000 and $75,000 per month, you must visit the branch for further discussion.
• If you are salaried and earn less than $25,000 per month, your loan application will be denied.
• If you are not salaried and earn more than or equal to $75,000 per month, you must visit the branch for further discussion.
• If you are not employed and your monthly salary is less than $75,000, your loan application will be denied.

NA: Unnecessary Information 

3. As a result of the Decision Table Testing, we discovered six possible outputs (cases) of the tested scenario: 

• #1, #4, #5: Rejection of Loan
• #2, #6: additional documentation and a visit
• #3: Approval of Loan (Success)

4. Now it's time to establish a successful path (#3), and distinguish it from the failed ones (#1, #4, #5) and those leading to potential leads (#2, #6). All paths can be now used as the software logic, testing app behavior and predictability. Any new paths – wherever on the client’s or user’s side should be tested through the Decision Table. 

What comes next?

As a result, we must generate test cases for each of these combinations using this Decision Table. Our expected output will be our actions. Following that, we will compare this to the actual results to determine whether the test cases passed or failed. However, as with any other technique, the Decision Table has some drawbacks that we should be aware of.

• It’s difficult to ensure that we've captured all possible input combinations and actions. Large systems contain numerous combinations, and it's easy to overlook them.
• When data is complex and each possible combination must be tested, Decision Tables can grow enormous. You can intelligently reduce the variety in each option to only the most interesting and impactful ones. This technique eliminates superfluous conditions that are irrelevant to the outcome and generates distinct outputs. The test design is enhanced with an additional layer of analysis to enable the tester to perform more effective testing.

Read: Testing Front-end Apps with Testing Library

How does the Decision Table improve software testing?

A well-designed Decision Table can assist in sorting out the system's appropriate response based on the input data, as it should include all conditions. It empowers developers by allowing them to express and analyze complex business rules. It also simplifies the logic design process, which benefits our product's development and testing. 

Decision tables are simple to understand, and anyone with no prior experience can use and implement this design and testing method, scenarios, and test cases. Through illustrative examples and real-world scenarios, project team members can quickly gain detailed insights into the issue at hand. The information is presented in a clear, understandable manner in design tables, making it easier to locate than in the text describing the system's logic. Finally, creating with this technique enables the discovery of edge cases and the identification of missing elements in the system.