What is Decision Table: Learn How to Test Complex Business Logic

OVERVIEW

A decision table is a systematic approach or representation for detailing different combinations of conditions or aspects and their diverse outcomes and actions. In simple terms, in software testing, a decision table analyzes the functionality and behavior of a software application or system by systematically documenting various combinations of inputs in a tabular format.

The testers use these to seek clarity on the decision-making process during the Software Development Life Cycle (SDLC) as they provide a structured way to handle decision logic and have expected outcomes. In the Software Development Life Cycle, decisions on making choices and taking actions for the software application enhancement are based on particular conditions and inputs like environmental variables, user inputs, and other parameters.

Such factors directly impact the functionality of the software applications because different combinations of conditions or inputs will lead to diverse test outcomes or actions. It is very important that testers and developers understand and manage such conditions and inputs to ensure that developed software applications function accurately.

This can be better done by creating a decision table. It gives a way to figure out all the possible scenarios for testing and their expected outcome. This not only saves testers and developers from missing any test case but also allows them to understand the decision logic and make correct decisions for the test process of software applications based on different conditions.

What is a Decision Table?

A decision table in software testing is a reliable approach for managing diverse combinations of inputs and their corresponding outputs. To put it differently, a decision table serves as a tabular representation that captures inputs in relation to rules, cases, or test conditions. Here, input denotes the factors or conditions needed to evaluate the behavior of the software application.

Likewise, output is the expected result of what the software application should do or produce in response to different input conditions. It encompasses information about various rules, test conditions, and inputs as perceived by the tester, represented as 'Yes' or 'No,' 'True' or 'False,' 'Y' or 'N,' and similar variations. This proves instrumental in facilitating both straightforward and complex software testing.

Here are some key points about decision tables:

• In the context of software testing, decision tables offer a methodological approach to represent the expected software application’s behavior based on variations in different inputs.
• Decision tables are a black box testing technique used to define test scenarios.
• They are a highly effective tool for both complex software testing and management of software specification requirements and test data.
• Decision tables are valuable for handling different input combinations and their associated outcomes.
• They are sometimes referred to as cause-effect tables due to their association with a logical diagramming technique called cause-effect graphing, which is used in creating the decision table.
• With the assistance of this table, one can systematically identify all potential combinations for software testing.
• Decision tables play a crucial role in reducing risk and enhancing system security by eliminating potential vulnerabilities.

Here is a sample of the decision table:

Why Need a Decision Table?

While other testing methodologies like boundary value testing and equivalence class partitioning testing address distinct scenarios, conflict arises when the system exhibits varying input behaviors. A decision table proves invaluable in such situations.

The decision table gives a visual representation of different input conditions and their related action that allows easy evaluation of all possible combinations. This enables comprehensive coverage of various input conditions to assess the software application’s responses comprehensively. Thus, it helps the testing of extensive datasets, which allows the streamlining of the testing activities and evaluation of the complete Software Testing Life Cycle (STLC).

Decision tables can also be used to reduce the number of test cases that need to be created. By eliminating redundant or irrelevant scenarios, it can help testers to save time and effort and create more comprehensive and well-thought-out test cases. By clearly defining the inputs, conditions, actions, and expected results for each test case, decision tables can help to reduce the risk of human error.

Components of a Decision Table

A decision table consists of several key components that work together to define and represent decision logic in a structured format. These components include

• Conditions: In a decision table, "conditions" are the factors or situations that influence what decision or action should be taken. The course of action to be taken depends on the existing circumstances. In the decision table, testers classify the circumstances on each column, which represents either a "yes" or "no" response or true (T) or false (F).
• Actions: Specific outcomes result from distinct sets of circumstances. They are generally the changes noted on the software application based on specified conditions. These outcomes are also presented as columns within the decision table.
• Rules: Rules consist of sets of conditions that, when satisfied, determine the appropriate course of action. They are derived from evaluating various permutations of circumstances and are portrayed as rows in the decision table.
• Rows and Columns: A decision table comprises both columns and rows. The columns display the conditions and corresponding actions, while the different possible outcomes are displayed in rows.

You have got an idea about the decision table and its components; now let us understand its various uses and implementation.

Where to Use the Decision Table?

Decision tables are used for various purposes and are not just limited to software testing. Let us explore some examples of decision tables in action.

• Software design: While designing the software application, there are situations where software developers need to make complex judgments accurately. Here, decision tables are used to make decisions on what action should be taken based on the input of users.
• Business rule: Another popular application of a decision table is in business rule management. It allows the organization to better manage their process, like customer complaints and user experience for the product.
• Quality assurance: In the software testing process, decision tables are often applied to detect and fix bugs before the release of the software application in the market. For example, it helps make accurate choices or judgments for the needed action when a specific failure is encountered in the code.
• Risk management: In business, several risks can impact the organization's reputation. One such risk is a breach of security. A decision table is one of the best approaches to find the severity of the breach and its impact on the business. This further helps make the right decision and action to solve the risk.

Different types of decision tables are used in developing and testing software applications. Let us have a look at those in the below sections.

Types of Decision Tables

Basically, when it comes to decision tables, they are divided into four main types based on different purposes and situations involved in software testing. These are:

• Limited Entry Decision Table
• Unlimited Entry Decision Table
• Simple Decision Table
• Complete Decision Table
• Orthogonal Array Decision Table
• Extended Decision Table

Limited Entry Decision Table

The name itself signifies a limited number of included inputs and actions in this table. Since there is less data in this decision table, it becomes easy for testers to manage and handle them effectively. It's often used for testing scenarios with few input conditions and corresponding outcomes.

Unlimited Entry Decision Table

This decision table is leveraged to handle a large number of conditions and actions. It is being used mainly for complex software testing, which incorporates different input variables and possible outcomes.

You can have as many conditions in an unlimited entry decision table (Condition 1, Condition 2, ..., Condition N) as needed.

Simple Decision Table

Simple decision tables have a single set of conditions, and each condition directly maps to an action or outcome. They are suitable for scenarios where the relationship between inputs and outputs is straightforward and linear.

Each condition (A, B, C, D) directly maps to a specific action or outcome (X, Y, Z).

Complete Decision Table

In this decision table, all the included and possible combinations of conditions and their actions are considered. It is valuable as it ensures exhaustive test coverage by verifying and validating every possible test scenario of software applications.

There are multiple conditions (Condition 1, Condition 2, Condition 3), and each row represents a specific combination of conditions and outcomes.

Orthogonal Array Decision Table

This decision table is mainly specialized in the optimization of test cases as it allows a reduction in the number of test cases for better test coverage. This can be done while still testing crucial combinations of conditions.

Extended Decision Table

Extended decision tables incorporate additional information such as priority levels, test data, or expected results into the table.

Example of a Decision Table

Let us now learn about decision tables with an example.

Example 1: Managing User Access Rights

Let us create a decision table for managing the user access rights based on different conditions. For example, you have web applications where you are supposed to test the different login conditions to the web page. Here are some conditions:

• The users can have either two roles: admin or user.
• The length of passwords entered by the users should be a minimum of 8 characters.
• The users who are “admins” have access to all the features of the system, and users who are in the “user” role have limited access.

Now let us make a decision table based on the above cases:

For the different conditions, four different test cases need to be tested in the testing process:

• Case 1: With admin role and length of passwords more than 8 characters.

  Expected outcome: The admin is shown with full access to the features of the applications.

• Case 2: With admin role and length of passwords less than 8 characters.

  Expected outcome: The admin is shown an error message.

• Case 3: User with user role and length of passwords more than 8 characters.

Expected outcome: The user is given limited access to the features of the applications.

• Case 4: User with user role and length of passwords less than 8 characters.

Expected outcome: The user is shown an error message.

When you define the above four test cases based on the developed decision table, you can analyze the work and functionality of the software applications, like how they handle the user access rights under different role and password length conditions.

Example 2: Web Application Compatibility Testing

Imagine you have been assigned the responsibility of verifying the compatibility of a web application across various web browsers and operating systems. To accomplish this task, we will construct a decision matrix delineating multiple test scenarios and their anticipated outcomes.

Testing Conditions: These conditions pertain to the specific web browsers and operating systems on which the web application must undergo testing. For the sake of simplicity, we will consider three web browsers (Chrome, Firefox, and Safari) and three operating systems (Windows, macOS, and Linux).

Test Cases:

• Scenario: Test the web application on the Chrome browser, executed on a Windows operating system.

Expected Result: The web application should operate without any issues.

• Scenario: Test the web application on the Chrome browser, executed on a macOS.

Expected Result: The web application should operate without issues.

• Scenario: Test the web application on the Chrome browser, executed on a Linux operating system.

Expected Result: The web application should operate without issues.

• Scenario: Test the web application on the Firefox browser, executed on a Windows operating system.

Expected Result: The web application should operate without issues.

• Scenario: Test the web application on the Firefox browser, executed on macOS.

Expected Result: The web application should operate without issues.

• Scenario: Test the web application on the Firefox browser, executed on a Linux operating system.

Expected Result: The web application should operate without issues.

• Scenario: Test the web application on the Safari browser, executed on macOS.

Expected Result: The web application should operate without issues.

Here is the decision table:

• Scenario: Test the web application on the Safari browser, executed on a Windows operating system.

Expected Result: The web application should operate without issues.

• Scenario: Test the web application on the Safari browser, executed on a Linux operating system.

Expected Result: The web application should operate without issues.

• Scenario: Test the web application on Internet Explorer (an older browser), executed on a Windows operating system.

Expected Result: The web application should display a message indicating that it is not supported on Internet Explorer.

• Scenario: Test the web application on the Edge browser, executed on a Windows operating system.

Expected Result: The web application should operate without issues.

Conditions	Case 1	Case 2	Case 3	Case 4	Case 5	Case 6	Case 7	Case 8	Case 9	Case 10	Case 11	Case 12
Browser	Chrome	Chrome	Chrome	Firefox	Firefox	Firefox	Safari	Safari	Safari	Internet Explorer	Edge	Edge
Operating System	Windows	macOS	Linux	Windows	macOS	Linux	macOS	Windows	Linux	Windows	Windows	macOS
Expected Result	Functions correctly	Functions correctly	Functions correctly	Functions correctly	Functions correctly	Functions correctly	Functions correctly	Functions correctly	Functions correctly	Not supported on Internet Explorer	Functions correctly	Functions correctly

• Scenario: Test the web application on the Edge browser, executed on macOS.

Expected Result: The web application should operate without issues.

From the above two examples on the decision table, you must be aware that it is the best approach to identify and resolve any potential issues in the software application. Now read the below section to get an idea of its advantages.

Benefits of Decision Tables in Software Testing

The use of decision tables in software testing offers several advantages, including.

• Simplified handling of complex business flows: This technique converts intricate business processes into well-structured test scenarios and test cases.
• Iterative workflow: Decision tables use an iterative approach, wherein the initial table serves as the input for subsequent iterations. Iteration occurs only if the initial table does not meet the required criteria.
• User-friendly: The method is straightforward and can be easily adopted by individuals of varying expertise levels to create test scenarios and cases.
• Comprehensive test coverage: Decision tables ensure that all possible test cases are considered, reducing the need for revisiting and revising test scenarios and test cases.
• Guaranteed completeness: These tables assure the inclusion of every possible combination of condition values, known as their completeness property.

However, knowing about the advantages of the decision table is not sufficient when you have to start with it. Having a good idea of its disadvantages can guide you to ways to optimize the decision table.

Continue reading the section below to know more.

Disadvantages of Decision Table

Despite the need and importance of a decision table in software testing, it has certain disadvantages that may interfere with the test process. Here are some of those disadvantages:

• Time-consuming: This method, although effective, can also be somewhat time-consuming. The longer the testing process, the higher the associated testing costs, making it a significant drawback.
• Limited output information: The decision table typically provides binary output, indicating 'true' or 'false.' Consequently, it falls short of offering other necessary data related to software security and overall performance.
• Requirement for skilled testers: Handling complex decision tables demands skilled and expert testers due to the multitude of inputs in intricate tables. Novices may find it challenging to manage such tables.
• Frequent updates required: Whenever there are changes in the software, it becomes mandatory to incorporate these changes into the decision tables. Consequently, the need for regular maintenance and updates arises, incurring additional costs and efforts for the team.
• Absence of user experience insight: Decision tables do not provide insights into user experience or the overall quality of the software system, which is another limitation to consider.

Now, let us learn how to construct a decision table.

Method of Creating a Decision Table

Before digging into the exact way to create a decision table, we will understand its features.

• A decision table is typically structured into four quadrants, as illustrated in the provided table. However, the number of rows and columns can vary as per the testing requirement and complexity of the software applications.

Condition being tested	Condition statements	Conditions entries
Possible actions to take	Action statements	Actions entries



• In the top section of the table, you'll find a listing of the conditions that are under examination, while the bottom section outlines the available actions to be executed.
• Each column within the table corresponds to a specific category of condition or rule.

Here are the general steps you should follow to construct a decision table:

Step 1: Problem Identification

The initial step in constructing a table is pinpointing and defining the problem. This involves recognizing the relevant factors and determining the necessary next steps.

Step 2: Condition and Action Definition

Once the problem is acknowledged, it becomes crucial to delineate the specific conditions and actions involved. Deconstructing the problem and identifying its constituent elements is an essential part of this process.

Step 3: Table Making

• Begin by creating boxes in the top and bottom left quadrants of the table, as illustrated in the above example. In the top left quadrant, list the conditions.
• Whenever possible, phrase these conditions as questions that can be answered with a "Y" for yes or an "N" for no.
• This type of table is referred to as a limited entry table. When a condition requires more than two values, it becomes an extended entry table.
• In the bottom left quadrant, list all the possible actions that can be taken.

Step 4: Rule Formulation

• Calculate the total number of potential values for each condition and then multiply these values together to determine the total number of unique combinations of conditions.
• Create one column in the top and bottom right quadrants for each combination. For instance, if you have two conditions, the first condition has two possible values, while the second has three, you should draw six (2 * 3) columns.

Step 5: Decision Table Organization

• Lastly, the table must be structured and user-friendly for easy comprehension and utilization.
• Achieving this involves arranging the rules logically and grouping similar conditions and actions together.
• In the top right quadrant of the table, input all the conceivable combinations of values.
• For every column representing each unique combination of conditions, mark an "X" in the appropriate action row in the bottom right quadrant.
• This "X" signifies the intersection between the required action and each distinct combination of condition values.

Now let us elaborate on this in more detail with the example below:

• Analyze the requirement and create the first column.

Suppose you are to create a table with the requirement: A user can delete a file if they are the file owner or have been granted delete permissions by the file owner.

Now, you have to express the conditional and its underlying actions in a list so that you define them as either TRUE or FALSE. Here, there are two conditions: “User is the file owner” and “User has been granted delete permissions by the file owner”. There is one result: the user can delete the file.

Conditions
User is the file owner
User has been granted delete permissions by the file owner
Actions
User can delete the file



• Add Columns

The next step is to calculate the exact number of columns needed to be constructed in the decision table. Here, the number of conditions and alternatives for each condition defines the number of columns. As in this example, there are two conditions, each of which can be TRUE or FALSE, so you will need a total of 4 columns.

However, if you have more columns, you can use the formula 2conditions.

Tip: You should create several smaller tables instead of a few larger ones. This precautionary measure helps prevent tables from growing so large that they become difficult to manage. You can validate this approach by beginning with areas with fewer business rules for testing purposes.

Now, you have to add T (TRUE) and F (FALSE) for the conditions. But you may think, what is the best way to do this? Remember, for each defined row, the number of "T" and "F" values is doubled compared to the previous row. This pattern continues horizontally across the entire row. For instance, in a table with 8 columns, the first row will display "TFTFTFTF," the second row will display "TTFFTTFF," and the third row will display "TTTTFFFF."

Now, you have to add T (TRUE) and F (FALSE) for the conditions. But you may think, what is the best way to do this? Remember, for each defined row, the number of "T" and "F" values is doubled compared to the previous row. This pattern continues horizontally across the entire row. For instance, in a table with 8 columns, the first row will display "TFTFTFTF," the second row will display "TTFFTTFF," and the third row will display "TTTTFFFF."

Conditions
User is the file owner	T	F	T	F
User has been granted delete permissions by the file owner	T	T	F	F
Actions
User can delete the file

You may use an Excel template to construct and fill in the decision tables.

• Lower the table

You should now mark the unimportant value with “-”. If the user is the file owner, it does not matter if the user is granted to delete the file. Hence, you should check for invalid combinations and complete this step by removing duplicate columns. In the example provided, the first and third columns are equal; hence, one is eliminated.

• Determine actions

Now that you have lowered the table, you have to enter the actions for each column in the table. You can find this information in the requirement and, based on that, name the columns. You can define them as R1/Rule 1, R2/Rule 2, etc.

Conditions
User is the file owner	T	F	F
User has been granted delete permissions by the file owner	-	T	F
Actions
User can delete the file	T	T	F



• Write Test Cases

Now, you can write the test cases based on the table.

• Test case for R1: The user is the file owner and has delete permissions.
• Test case for R2: The user is not the file owner but has delete permissions.
• Test case for R3: The user is not the file owner and does not have delete permissions.

Implementing Decision Tables in Software Testing

Here is the series of steps that you should follow to apply a decision table to the software applications being tested to determine its behavior under various input conditions:

• Selection of test case: In software testing, creating a test case is the initial step. You must select the test cases pertaining to the feature of software applications that have values and states of different variables for any specific test scenario.
• Set up test environment: In the next step, you are supposed to set up the test environment and data to mimic the real-world scenario and condition where the decision is made. Here, you have to configure the unit or component of the software application and give the required inputs that relate to the values and state of the independent variable in the decision table.
• Perform test actions: When you have test cases and test environment in one place, next, you have to move to the perform action and operations related to the decision table. Such actions are mainly the conditions and combination of variable values defined in the decision table.
• Observe the results: After performing the action, you should observe the result on the behavior and functionality of the software applications. This mainly includes any outputs, changes in state, and actions taken by the applications.
• Comparison of results: When you end up performing the actions, you should now compare the actual and expected results to verify the system's consistency.
• Record the Test Outcome: Then, record the test outcome and report any defects found in the system.

We can say that the decision table represents complex conditional logic that eventually directs and guides the testing strategies. When we make a table, we have different combination and action that signifies specific test scenario, and it becomes important to test the accuracy and reliability of your software applications across different environments and browsers. Such test scenarios can be tested and leveraged across various real-world environments by executing them in a cloud-based platform like LambdaTest.

LambdaTest is an AI-powered test orchestration execution platform that allows the execution of both manual and automation tests across an online browser farm of 3000+ browsers, devices, and OS combinations. This will help you to test your application’s behavior consistency across different environments. We know that the decision table may have numerous test cases.

With LambdaTest, you can leverage parallel test capabilities using different automation testing frameworks and languages and execute multiple test cases simultaneously. You can also detect errors and bugs in the software application by LambdaTest’s in-built debugging tools, thus making it easier to report and fix them efficiently.

Following is the tutorial below on running parallel testing using TestNG on the LambdaTest platform.

Subscribe to the LambdaTest YouTube Channel for more videos on automation testing and Cypress testing and to elevate your testing game!

Optimization of Decision Tables

To improve the accuracy and efficiency of the decision table, you should optimize it by applying specific rules and steps. Here are explanations of those steps:

• Eliminating duplicate rows: When making a decision table, you may enter similar values and inputs for all variables in different rows. Such duplicated rows may lead to inaccuracy in the expected outcome. Hence, you should identify those duplicated rows before finalizing the decision table. There has to be only one representation of the particular combination of variable values.
• Eliminating contradictory rows: In a decision table, there are contradictory rows where there are conflicting values or inputs. Having this in your table will make you make incorrect decisions for your software applications. You need first to identify and remove any of the contradictory rows with conflicting values and ensure consistency in different combinations of variable values with specific logic.
• Eliminating impossible rows: In a decision table, you may write the values generally not allowed by the system or component specifications. Such rows may give unrealistic outcomes due to invalid scenarios. It is important to remove those rows to avoid any potential error.
• Combining similar rows: There are situations when making a decision table; some rows may have similar values or inputs for all dependent variables. However, values may differ for independent variables that do not impact the outcome. Thus, you should simplify the table and combine those rows into one row. For this, you can use the symbol “X” for the independent variable, which is irrelevant to the outcome, to show that they can have any value.

By following these optimization steps, you create a decision table that is more concise and precise. Other than optimizing the table, it's also important to perform decision table testing.

Why Decision Table Testing is Important?

Decision table testing is a way to test software by trying out different combinations of inputs. It is especially useful for testing complex business logic, where the system's behavior changes depending on the specific inputs.

Other techniques, such as boundary value testing and equivalent partitioning, are also used to ensure good test coverage. However, these techniques are less effective when the system's behavior differs for each input set.

Decision tables are easy to understand and use and can be used to ensure good test coverage for complex business logic. They can also be used as a reference for the requirement and functionality development. The importance of decision table testing becomes clear as the number of inputs increases.

For example, if a system has 10 inputs, there are 1024 possible combinations of inputs. It is obviously not possible to test all of these combinations, but decision table testing can be used to choose a subset of the combinations to test. Decision table testing is important because it helps us test different combinations of conditions and provides better test coverage for complex business logic. It is instrumental when testing the behavior of a large set of inputs where the system's behavior differs with each set of inputs. Decision tables are easy to understand and use, and they can provide good coverage and representation.

Decision table testing is important because it helps us test different combinations of conditions and provides better test coverage for complex business logic. It is instrumental when testing the behavior of a large set of inputs where the system's behavior differs with each set of inputs. Decision tables are easy to understand and use, and they can provide good coverage and representation.

Tools for Creating Decision Tables

Here are some tools that can be used to create decision tables:

• Spreadsheet software: Simple decision tables can be created using spreadsheet programs like Microsoft Excel or Google Sheets. For those familiar with spreadsheet software, this offers a straightforward and convenient method for crafting decision tables.
• Decision table software: Dedicated software tools like RuleDesigner and DecisionTools Suite are designed to create decision tables. These programs offer enhanced functionality tailored to the task of table construction.
• Code generators: Code generators are available in languages such as Java and Python, allowing the automatic generation of decision tables based on predefined specifications.
• Online tools: Numerous online tools are available for building decision tables without additional software installation. Some of them are Cacoo, Gliffy, SmartDraw, etc. Many of these tools are cost-free and offer sufficient capabilities for creating basic tables.

Best Practices of Decision Table

Here are some best practices that can be used to improve the process of creating a decision table:

• Keep it simple: Make your decision table easy to understand. Use straightforward language to describe the situations and the actions to take. Break down complex decisions into smaller, manageable parts.
• Use consistent language and notation: Always use the same terms and symbols in your decision table. This helps everyone understand it better and prevents confusion.
• Test and validate: Before using your decision table in real situations, thoroughly test and check it. Make sure it works correctly and gives the right outcomes in various scenarios.
• Update as needed: Keep your decision table current. When circumstances change, add new rules or modify existing ones to reflect the new situation.
• Include stakeholder feedback: Get input from relevant people when creating your decision table. This ensures that everyone's needs and requirements are considered, making the decision-making process fair and beneficial for all.

Conclusion