What is decision table?

A decision table is a good way to deal with different combination inputs with their associated outputs and also called cause-effect table. Reason to call cause-effect table is an associated logical diagramming technique called ’cause-effect graphing that is basically use to derive the decision table.

Decision table testing is black box test design technique to determine the test scenarios for complex business logic.

We can apply Equivalence Partitioning and Boundary Value Analysis techniques to only specific conditions or inputs. Although, if we have dissimilar inputs that result in different actions being taken or secondly we have a business rule to test that there are different combination of inputs which result in different actions. We use decision table to test these kinds of rules or logic.

Why is Decision Table Important?

A decision table is an outstanding technique used for testing and requirements management. Some of the reasons why the decision table is important include:

• Decision tables are very much helpful in test design technique.
• It helps testers to search the effects of combinations of different inputs and other software states that implement business rules.
• It provides a regular way of stating complex business rules which benefits the developers as well as the testers.
• It assists in the development process with the developer to do a better job. Testing with all combination might be impractical.
• It the most preferable choice for testing and requirements management.
• It is a structured exercise to prepare requirements when dealing with complex business rules.
• It is also used in model complicated logic.

How to create a decision table?

To explain how to create a decision table we will illustrate it with the login feature. What cases should we consider?

• A user can enter a valid email or invalid email.
• The user’s email is in the database.
• A user enters a correct or incorrect password (a password that doesn’t fit the account or password is invalid).
• A user can be blocked.

The table above looks overcomplicated, but we still have to optimize it by removing cases that cannot exist and combining cases for which a change in one of the conditions is not relevant to the action of the system. We can see that some cases don’t have any sense.

Case 3, 9, 10, and 15 cannot occur because, when an email is invalid, it cannot be saved in the database, so we can delete those cases. The next cases to be removed are 4, 7, 11, and 14 – if the email is not saved in the database, it cannot be blocked.

We can also combine cases 1 and 5 if the email is invalid (it doesn’t matter if the password is). Let’s see what the table looks like now, after simplifying and removing a few cases.

Of course, in decision tables, we can use Yes/No or True/False – which are analogous to 0/1 values. We can use number value (for example, temperature), words, or pictograms (or whatever we need).

An example of such a decision table may be a table containing information about access to various locations of the application by users, depending on the type of user.

Let us look at a Car Rental Example

The specification says: If Age is over 23 and the person has a Clean driving record, supply rental car, else reject.

There are 2 conditions: Age and Clean driving record
And 2 Actions: supply rental car, do not supply rental car
2 conditions = 4 rules.

We list the conditions in the first column, followed by the Actions.

Then, we start evaluating the conditions to be True or False and for the combinations that arise, the appropriate action.

 With 2 conditions, there are 4 combinations (two to the power of the number of things to be combined), so if three conditions – the number of combinations is 8(2^3), and for 4 conditions, the number of combinations is 16 (2 ^ 4).

Decision Table technique is used after Equivalence Partitioning and Boundary Value Analysis have been applied.

Advantages

• Makes it easy for the testers to design test for complex scenarios
• It provides clarity for complex business scenarios
• It follows an iterative process that is the table created for the first input can be used for the second and the second can be used for the third and so on
• It reduces the rework on writing Test Cases and Test Scenarios

Conclusion

This process is a good way to deal with different combinations of input and following a structured way of sorting out the requirements of the complex business scenarios.