Decision Table Testing

Decision table testing is a black box testing method used to evaluate the logical relationships between two or more inputs. Decision tables are an excellent way to capture complex business rules that a system must implement. The decision table is called a Cause-Effect table, as the causes and effects of comprehensive test coverage are captured. This technique is helpful for testing situations where software behavior depends on a combination of conditions at any test level.

Table of Contents 

1. How to Create a Decision Table
2. Types of Decision Table
3. Decision Table Example
4. Test Coverage in Decision Table Testing
5. Advantages of Decision Table Testing
6. Disadvantages of Decision Table Testing
7. Video Tutorial

How to Create a Decision Table

Creating a Decision Table is a process of organizing input combinations and their corresponding system behavior in a tabular format. A decision table represents several input values, rules, test conditions, and actions.

When designing decision tables, the tester must identify the conditions (commonly inputs) and the resulting actions (commonly outputs) of the system under test. These elements comprise the rows of the table, with the conditions typically located at the top and the actions at the bottom. Each column in the table represents a unique decision rule that defines a combination of conditions that, when met, trigger the execution of the actions associated with that rule.

When creating decision tables, the values of the conditions and actions are typically represented in various formats, such as:

1. Boolean values: true or false
2. Discrete values: e.g., red, green, or blue
3. Numbers or ranges of numbers

It is common to find different types of conditions and actions in the same table.

When creating decision tables, following a consistent notation to document and understand the system's expected behavior under different scenarios is essential. The standard notation commonly used in decision tables is as follows:

For conditions:

• Y represents the condition is true (may also be represented as T or 1)
• N represents the condition is false (may also be represented as F or 0)
• — denotes the value of the condition is not relevant (may also be represented as N/A)

For actions:

• X represents the action that should occur (may also be defined as Y or T, or 1)
• Blank represents the action that should not happen (may also be described as – or N or F or 0)

Using a consistent notation for conditions and actions makes it easier for stakeholders to understand and review the decision table and identify the system's expected behavior under different scenarios.

Decision Table Example

Let's create a decision table for a login screen that asks for a UserId and Password can be done by following these steps:

1. Identify the conditions: In this case, the conditions are the UserId and Password inputs.
2. Identify the actions: The first action is, displays an error message if the input is wrong, and the second is redirecting to the my account if the user enters the correct UserId and Password.
3. Create the decision table: The decision table below illustrates that when the UserName and Password values are correct, there will be no error displayed and the user will be redirected to the My Account page. However, if either the UserName or Password value is incorrect, an error will be displayed.
4. Review the decision table: Review the decision table to ensure that all possible combinations of conditions have been captured and that the correct actions have been identified for each combination.
5. Test the system: Use the decision table to test the system by inputting the different combinations of UserId and Password and verifying that the system behaves as expected

E: Invalid Username or Password Error, M: Display My Account Page, T: Correct Value, N: Incorrect Value, Y: Action should Occur, N: Action should not occur

Types of Decision Tables

Decision tables are a widely used technique for testing software systems and can be classified into two main types:

1. Limited Entry Decision Tables: These tables restrict the condition entries to binary values, meaning the conditions can only take on two possible values (e.g., true or false).
2. Extended Entry Decision Tables: These tables allow for condition entries with more than two values, meaning that the conditions can take on multiple possible values. These decision tables are used when the system under test has various conditions where a condition may have many possibilities instead of just true or false.

Test Coverage in Decision Table Testing

A complete decision table includes enough columns (test cases) to cover all possible combinations of conditions. By removing columns that do not affect the outcome, such as impossible combinations of conditions, the number of test cases can be reduced significantly.

The commonly accepted minimum coverage standard for decision table testing is to have at least one test case per decision rule. This typically involves covering all combinations of conditions to ensure comprehensive testing.

The coverage of the decision table is measured by determining the number of decision rules that have been tested by at least one test case, divided by the total number of decision rules. This is generally expressed as a percentage. It is essential to strive for high coverage to ensure that the system under test has been thoroughly evaluated and that any defects or issues have been identified.

Advantages of Decision Table Testing

Decision table testing is a powerful technique for evaluating software systems that offer several advantages, including:

• Identifying all essential combinations of conditions: By creating a decision table, the tester can identify all possible combinations of conditions, some of which might otherwise be overlooked.
• Finding gaps in requirements: By reviewing the True (T) and False (F) values assigned for conditions, the tester can quickly identify any requirements that have been overlooked or skipped.
• Analyzing complex business rules: Decision tables provide developers with a clear and easy-to-use tool for analyzing and documenting complex business rules.
• Easy to understand and implement: Decision tables are easy to understand and implement and can be used by anyone, including testers and developers, without prior experience.
• Robust specification-based testing technique: Decision tables are a robust specification-based testing technique that can be used in many testing scenarios.
• Clear and effective representation: The tabular and graphical representation of decision tables is particularly beneficial for all stakeholders, including non-technical members, as it is easy to understand.
• Handling different behavior for different inputs: When the system behavior is different for various inputs and not the same for a range of inputs, equivalent partitioning, and boundary value analysis may not be as effective, but a decision table can be used to test the system's behavior under these conditions.

Disadvantages of Decision Table Testing

While decision table testing is a powerful technique for evaluating software systems, there are also some disadvantages to consider, such as:

• The complexity of data: Decision tables can become large and unwieldy when the data is complex, and every combination of conditions needs to be tested. However, this problem can be addressed by using Collapsed Decision Table Testing, a technique that reduces the number of varieties in each possibility to only the interesting and impactful ones.
• Inadequate coverage: Decision tables alone may not be sufficient to catch all defects in a system, and they should be used in conjunction with other testing techniques, such as boundary value and equivalence partitioning, wherever possible.
• Redundant combinations: Decision tables can introduce redundant combinations if the tester solely goes by the permutations without considering the relevance of the conditions to the outcome.
  Time-consuming: Decision table testing can be time-consuming, especially when the data is complex and every combination needs to be tested.