Decision Table Testing: Best Practices for Effective Test Design

Hi everyone!

Ever confused by all the ‘if this, then that’ scenarios in your software testing? We all know how tangled decision rules can get, right? Fortunately, decision table testing can help you turn that chaos into clarity.

Decision table testing is a powerful software modeling technique used to represent and test complex decision logic. By breaking down conditions and their corresponding actions into a tabular form, decision tables make it easier to understand, validate, and systematically derive test cases. These tables are straightforward, making them easy for domain experts to validate. Additionally, testers can systematically derive test cases from decision tables to ensure the system correctly implements the required conditional logic.

In this article, we will explore how decision tables work, their benefits, and how to use them to create effective test cases.

What is Decision Table Testing?

Decision table testing, also known as cause-effect table testing, is a systematic approach to identifying and documenting various conditions and their corresponding actions in a tabular format.

Each column in the table represents a unique combination of conditions, and the resulting actions are mapped accordingly. This technique helps testers visualize the application’s behavior for all possible inputs, ensuring that all scenarios are considered.

Why Use Decision Table Testing?

1. Comprehensive Coverage: Decision tables ensure that every possible condition combination is considered, leading to thorough testing.
2. Clarity and Precision: The tabular format provides a clear and precise way to represent complex logic and business rules.
3. Identifying Gaps and Redundancies: By mapping out all conditions and actions, decision tables help in identifying any gaps or redundant logic in the application.
4. Simplified Test Case Design: Testers can systematically design test cases based on the decision table, ensuring that all scenarios are covered without duplication.

How to Create a Decision Table?

Creating a decision table involves a series of steps:

1. Identify the Conditions and Actions: Start by listing all the conditions (inputs) and actions (outputs) related to the functionality you are testing.
2. Determine the Possible Values for Each Condition: Each condition can have multiple possible values (e.g., true/false, range of values).
3. Create the Table Structure: The table should have rows for conditions and actions, and columns for each unique combination of condition values.
4. Fill in the Table: For each column, mark the condition values and the resulting actions.
5. Simplify the Table (if possible): Merge columns with identical actions to simplify the table without losing test coverage.

Scenario 1:

Let’s begin with a simple example of a decision table. Imagine you are testing a subscription service that offers different plans based on two conditions:

1. Whether the subscription is for a basic or premium plan.
2. Whether the customer opts for an annual commitment or a monthly subscription.

Decision tables offer a structured way to represent all possible combinations of conditions and their respective actions:

This table makes it clear how the combination of conditions determines the subscription price. In this table:

• The top rows represent the conditions
• The bottom row represents the action
• The columns represent different rules or scenarios
• A rule represents a unique combination of condition values that lead to a specific set of actions. Typically each rule in a decision table translates into a test case.

Let’s add some complexity

To illustrate the power of decision tables further, let’s add an additional condition: loyalty discount. The updated conditions and actions are:

When we added one condition, the number of the rules doubled. The next step is simplifying the table. Simplification involves merging columns with identical results:

Rule 2 is merged with Rule 1 because if the subscription is basic with an annual commitment, the loyalty status doesn’t matter — the price is €10. Similarly, Rule 6 is merged to Rule 5 because if the subscription is premium with an annual commitment, the loyalty status doesn’t matter — the price is €30.

After removing duplicate actions, the optimized table is:

In this table, “DC” stands for “don’t care,” meaning the value of that condition does not affect the action.

You might be wondering how this simplification process works and why it’s necessary. Don’t worry; we’ve only outlined the general concept of decision tables so far. In the next scenario, we’ll delve into each step in detail to create a decision table and derive test cases. Here’s our roadmap to achieve this goal:

How to Utilize Decision Table Testing to Generate Test Cases?

Full decision table:

• Must include every possible combination of conditions.
• Identify the conditions and resulting actions, which form the table’s rows, typically with conditions at the top and actions at the bottom.

Simplifying the Table:

• Irrelevant Conditions: “-” denotes that a condition’s value does not affect the action outcome.
• Column Merging: Combine columns where certain conditions do not affect the outcome into a single column.
• Infeasible Conditions:
• “N/A” indicates that a condition is infeasible for a specific rule.
• Deleting Columns: Remove columns containing infeasible combinations of conditions.

Coverage in Decision Table Testing:

• Achieving Full Coverage: To cover 100% using this technique, test cases must exercise all these columns.
• Coverage Measurement: Coverage is measured by the number of exercised columns divided by the total number of feasible columns, expressed as a percentage.

Scenario 2: You are testing a system to analyze employee training certification results.

Implemented Features:

1. If an employee has successfully completed the online training module, they are granted access to the hands-on training session.
2. If it is the employee’s first attempt at the training module, but they did not pass, they are given the opportunity for a second try.
3. If it is not the employee’s first attempt at the training module and they have not passed, they face a consequence of being restricted from attempting the training module again for a period of one month.

Conditions:

1. Has the employee successfully completed the online training module?
2. Is it the employee’s first attempt at the training module?

Actions:

1. Grant access to the hands-on training session.
2. Provide a second attempt at the training module.
3. Restrict the employee from attempting the training module again for one month.

Question: What is the minimum number of test cases to achieve 100% test coverage?

Having identified the conditions and resulting actions, let’s create the table:

Full Decision Table:

What we have here is a full decision table which has all possible combinations of conditions.

Rule 1: The employee has successfully completed the online training module and it is their first attempt. They are granted access to the hands-on training session.

Rule 2: The employee has successfully completed the online training module and it is not their first attempt. They are still granted access to the hands-on training session.

Rule 3: The employee has not completed the online training module but it is their first attempt. They are given the opportunity for a second attempt.

Rule 4: The employee has not completed the online training module and it is not their first attempt. They are restricted from attempting the training module again for one month.

Once we have the full decision table, the next step is to simplify it. But how do we simplify a full decision table? Remember Step 2 of our roadmap:

• Combine columns where certain conditions do not affect the outcome into a single column:

In this step, you should first identify rules that result in the same action. In our scenario, these are the first and second rules. Notice that if the online training module is completed, it doesn’t matter whether it is the first attempt or not; the action remains the same, and access is granted to the hands-on training session. Therefore, the next step is to replace the true and false values of the “first attempt” condition with “DC” (Don’t Care) or simply use a “-” to indicate that this condition does not impact the action.

Now let’s have a look at our simplified decision table and the test cases we derive from this table:

Notice that we don’t need to test the first and second attempts separately if the online training module is completed successfully.

So, what does this table tell you about test coverage? Remember the last item in our roadmap:

• Coverage Measurement: Coverage is measured by the number of exercised columns divided by the total number of feasible columns, expressed as a percentage.

In this table, we have three columns, three different combinations of conditions that result in different actions, which means that we need at least 3 test cases to achieve 100% test coverage.

Now it is time to discuss why we need to simplify a decision table.

Why Simplify a Full Decision Table?

A full decision table provides a comprehensive overview of all possible combinations of conditions and their corresponding actions. While this approach ensures that every scenario is considered, it can quickly become very complex as the number of conditions increases.

The number of possible combinations in a decision table grows exponentially with the number of conditions. For example, with N conditions, there are 2N possible combinations of conditions. This exponential growth can make the decision table very large and complex, especially as the number of conditions increases.

For instance:

• With 3 conditions, there are 23 = 8 possible combinations.
• With 4 conditions, there are 24 = 16 possible combinations.
• With 5 conditions, there are 25 = 32 possible combinations.

When constructing decision tables, it’s crucial to recognize that the number of possible combinations of conditions is influenced by the number of states each condition can have. For instance, if each condition has only two possible states (e.g., true/false, yes/no), the total number of combinations is calculated as 2N, where N is the number of conditions. However, if a condition can have more than two states, such as three possible states, the number of combinations escalates significantly, calculated as 3N.

As the table grows with more conditions and possible states, managing and interpreting it becomes increasingly complex and cumbersome.

Moreover, not every condition is relevant to every action in every scenario. Some conditions may not influence the outcome under certain circumstances. By identifying and removing these redundant or irrelevant conditions, we can streamline the decision table, reducing its complexity while preserving the essential information needed for accurate decision-making.

This simplification process is fundamental to optimizing decision tables. It allows us to cover more conditions and actions with fewer test cases, making the testing process more efficient. In a scenario where we initially had four test cases, simplification reduces this number to three. While this may seem like a minor reduction, the impact becomes more significant as the number of conditions increases.

To further illustrate this, consider the following scenario where we introduce an additional condition and action:

Scenario 3: Testing Employee Training Certification Results

Implemented Features:

• If an employee has successfully completed the online training module, they are granted access to the hands-on training session.
• If it is the employee’s first attempt at the training module, but they did not pass, they are given the opportunity for a second try.
• If it is not the employee’s first attempt at the training module and they have not passed, they face a consequence of being restricted from attempting the training module again for a period of one month.
• If an employee has a supervisor’s approval, they are granted an additional attempt at the training module even if it’s not their first attempt.

Conditions:

1. Has the employee successfully completed the online training module?
2. Is it the employee’s first attempt at the training module?
3. Does the employee have supervisor’s approval?

Actions:

1. Grant access to the hands-on training session.
2. Provide a second attempt at the training module.
3. Restrict the employee from attempting the training module again for one month.
4. Grant an additional attempt at the training module with supervisor’s approval.

Question: What is the minimum number of test cases to achieve 100% test coverage?

Again, let’s start with creating the full decision table:

In this table, we have three conditions, each with two potential states: true or false. To determine the total number of possible combinations, we use the formula 2^n, where n is the number of conditions. In this case, 23 = 8, meaning there are eight distinct rule sets to consider.

Each rule represents a unique scenario based on the different combinations of true and false values for the three conditions. The table then specifies the appropriate action to take for each of these eight scenarios.

Now, you might be asking if you need to test all these combinations. The answer is simply no. First, remember that the number of possible rules grows exponentially as the number of conditions increases. In practical scenarios, you often have more than three conditions, making it infeasible to test every possible variation.

Secondly, not all combinations are relevant. For example, if a candidate has successfully completed an online training module, the condition of “Supervisor’s Approval” might become irrelevant.

To simplify our decision table, we can focus on rules that lead to the same action, thereby reducing the number of test cases without sacrificing the integrity of the decision-making process:

As you can see from the table, when an employee successfully completes the online training module, it doesn’t matter whether it’s their first attempt or not, and supervisor approval becomes irrelevant. In other words, as long as the “Completed the Online Training Module” condition is true, the action is always “Access to Hands-on Training Session,” and the other two conditions have no impact on this outcome. Therefore, we can merge these four columns into a single column.

Additionally, when an employee fails the online training module on their first attempt, they are automatically given a second attempt. In this scenario, the “Supervisor’s Approval” condition has no effect on the resulting action, allowing us to merge these two columns into one.

After merging these columns, the decision table is simplified as follows:

In this table, the “-” symbol in the table indicates that a particular rule’s truth value doesn’t affect the action; the action remains the same regardless of whether the rule is true or false.

If you need to expand a simplified table, you can do so by duplicating any column with a “-” symbol and replacing the “-” with both true and false in the respective cells. This is how you interpret and expand a simplified decision table.

With this understanding, we can now answer the question: We need at least four test cases to achieve 100% test coverage. Each rule in this simplified table corresponds to a distinct test case with its expected result.

Conclusion

In practice, decision tables can become complex with many conditions and actions. However, the systematic approach they offer makes it possible to manage this complexity and ensure robust testing of the decision logic in any application. So, next time you need to test a decision logic, try modeling it with a decision table and see how it can simplify your testing process.

Enjoy turning your decision logic into well-structured decision tables and creating efficient, comprehensive test cases!