A guide to Using Decision Tables

What is a decision table?

A decision table is an excellent tool to use in both testing and requirements management. Essentially it is a structured exercise to formulate requirements when dealing with complex business rules. Decision tables are used to model complicated logic. They can make it easy to see that all possible combinations of conditions have been considered and when conditions are missed, it is easy to see this.

Decision Table Example:

Let’s take an example scenario for an ATM where a decision table would be of use.

A customer requests a cash withdrawal. One of the business rules for the ATM is that the ATM machine pays out the amount if the customer has sufficient funds in their account or if the customer has the credit granted. Already, this simple example of a business rule is quite complicated to describe in text. A decision table makes the same requirements clearer to understand:

In a decision table, conditions are usually expressed as true (T) or false (F). Each column in the table corresponds to a rule in the business logic that describes the unique combination of circumstances that will result in the actions. The table above contains three different business rules, and one of them is the “withdrawal is granted if the requested amount is covered by the balance.” It is normal to create at least one test case per column, which results in full coverage of all business rules.

One advantage of using decision tables is that they make it possible to detect combinations of conditions that would otherwise not have been found and therefore not tested or developed. The requirements become much clearer and you often realize that some requirements are illogical, something that is hard to see when the requirements are only expressed in text.

A disadvantage of the technique is that a decision table is not equivalent to complete test cases containing step-by-step instructions of what to do in what order. When this level of detail is required, the decision table has to be further detailed into test cases.

Decision tables can be used in all situations where the outcome depends on the combinations of different choices, and that is usually very often. In many systems there are tons of business rules where decision tables add a lot of value.

Decision tables should best be constructed during system design, since they become useful to both developers and testers. The requirements specialist also becomes more confident that everything that is important is actually documented. If there are no decision tables, testers can create them during test design to be able to write better test cases.

Now the question is how to create decision tables? Here are the steps that you need to use to create decision tables.

Steps to create decision tables:

Step 1 – Analyze the requirement and create the first column

Requirement: “Withdrawal is granted if requested amount is covered by the balance or if the customer is granted credit to cover the withdrawal amount”.

Express conditions and resulting actions in a list so that they are either TRUE or FALSE. In this case there are two conditions, “withdrawal amount ≤ balance” and “credit granted”. There is one result, the withdrawal is granted.

Step 2: Add Columns

Calculate how many columns are needed in the table. The number of columns depends on the number of conditions and the number of alternatives for each condition. If there are two conditions and each condition can be either true or false, you need 4 columns. If there are three conditions there will be 8 columns and so on.

Mathematically, the number of columns is 2 ^conditions. In this case 2² = 4 columns.

Number of columns that is needed:

The bottom line is that you should create more smaller decision tables instead of fewer larger ones, otherwise you run the risk of the decision tables being so large as to be unmanageable. Test the technique by picking areas with fewer business rules.

Now is the time to fill in the T (TRUE) and F (FALSE) for the conditions. How do you do that? The simplest is to say that it should look like this:

Row 1: TF

Row 2: TTFF

Row 3: TTTTFFFF

For each row, there is twice as many T and F as the previous line.

Repeat the pattern above from left to right for the entire row. In other words, for a table with 8 columns, the first row will read TFTFTFTF, the second row will read TTFFTTFF and the third row will read TTTTFFFF.

Tip: There are Excel templates to fill in decision tables if you need help.

Step 3: Reduce the table

Mark insignificant values with “-“. If the requested amount is less than or equal to the account balance it does not matter if credit is granted. In the next step, you can delete the columns that have become identical.

Check for invalid combinations. Invalid combinations are those that cannot happen, for example, that someone is both an infant and senior. Mark them somehow, e.g. with “X”. In this example, there are no invalid combinations.

Finish by removing duplicate columns. In this case, the first and third column are equal, therefore one of them is removed.

Step 4: Determine actions

Enter actions for each column in the table. You will be able to find this information in the requirement. Name the columns (the rules). They may be named R1/Rule 1, R2/Rule 2 and so on, but you can also give them more descriptive names.

Step 5: Write test cases

Write test cases based on the table. At least one test case per column gives full coverage of all business rules.

• Test case for R1: balance = 200, requested withdrawal = 200. Expected result: withdrawal granted.
• Test case for R2: balance = 100, requested withdrawal = 200, credit granted. Expected result: withdrawal granted.
• Test case for R3: balance = 100, requested withdrawal = 200, no credit. Expected Result: withdrawal denied.

Summary

Decision tables are a good way to describe requirements when there are several business rules that interact together. Using decision tables it becomes easier for the requirements specialist to write requirements which cover all conditions. As to the tester, it becomes easier for them to write complete test cases.

Write decision tables early, then they’ll become useful for requirements specialists, developers, end-users and testers.