How to use decision tables for testing and requirements management

There’s only so much the human mind can handle all at once.

When you consider how easy it is for even the most straightforward everyday task, like deciding what to wear for a party, to leave us completely stumped, one wonders how we manage to perform complex activities like software testing without breaking down into a tearful mess!

An excellent tool which we at ReQtest find useful in dealing with complex business rules and clarifying the complicated logic behind them is the decision table.

The use of decision tables for testing and requirements management makes it easier to appreciate all the possible conditions that could arise with a single business rule and their outcomes.

In the example below, we’ll create a decision table that models the logic behind an fundamental business rule that underpins the way ATMs work. The context for this rule is:

A customer requests a cash withdrawal.

And here’s the business rule:

The ATM machine pays out the requested amount if the customer has sufficient funds in their balance or if the customer has the credit granted.

As simple as it may seem in writing, listing all the possible permutations of the conditions attached to that rule in the form of a decision table reveals that this requirement is actually quite a complicated one.

Interpreting a decision table

In its simplest form, a decision table breaks down every condition of a rule in a series of binary Yes/No decisions, which in decision tables are expressed as T (true) or F (false).

Each column in the decision table represents a unique combination of conditions that could happen in real-life when implementing a given business rule, and their outcomes at the very bottom.

In the decision table above, the business rule has been teased out to reveal three possible conditions that could exist at any given moment in time. In practice, each column in a decision table will correspond to a particular test case which confirms whether the software abides by the requirements provided.

The process of creating a decision table is very simple and this useful skill can be learnt in a short time. Here are the four steps you need to do to draw up your table:

 

Step 1: Analyze the requirement and create the first column

 

The requirement in our ATM example is:

The ATM machine pays out the requested amount if the customer has sufficient funds in their balance or if the customer has the credit granted.

The two conditions and outcome stated in that requirement have been highlighted and will be used to create the first column of the decision table.

Step 2: Add Columns

 

Each condition and outcomes listed in the first column is then expressed as being either either T (true) or F (false) in the adjacent columns.

The number of additional columns needed in a decision table depends on the number of alternatives for each condition listed in the first column.

In our example, there are two conditions which can be either true or false, therefore we need to add four extra columns to show all the possible permutations of the requirement in practice.

 

To can easily work out how many columns you need in the decision table if you have more than two conditions by using the following mathematical formula, where the number of alternatives is the base and the number of conditions is its exponential:

(Number of alternatives) ^{number of conditions}

If there are two conditions, and each condition can be either true or false, then 2² = 4 columns. If there are three conditions there will be 2³ = 8 columns, and so on.

As you can see in the image above, the number of columns in the decision table goes up dramatically as the number of conditions increases. Therefore, it is recommended that you create more smaller decision tables instead of drawing up fewer larger ones.

Note: The simplest way to fill in the truth table with T (true) or F (false) for the conditions listed is to make sure that in each row there are twice many T’s and F’s as the previous line. E.g.

Row 1: TF

Row 2: TTFF

Row 3: TTTTFFFF

…

 

Step 3: Simplify the table

 

If there are conditions that do not enter into play in a particular scenario (e.g. if your balance covers the amount requested then no credit is needed), mark the redundant values with ‘-’.

If you notice any duplicate columns delete them to make your decision table more manageable. In this case, the first and third column are equal, therefore one of them is removed.

Step 4: Determine the outcomes

 

Finally, enter the outcomes for the actions in each column in the table.

You can also name the columns to make it easier to refer to a particular scenario. Many people prefer to use simplified names like R1/Rule 1, R2/Rule 2 and so on, but you can also give them more descriptive names.

Your decision table is now complete!

 

Writing test cases based on decision tables

In order to cover all possible permutation of the business rules, every column in your decision table should correspond to one test case.

In our example:

• 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.

 

Advantages and disadvantages of using decision tables

The main advantage of using decision tables is that they help you detect every possible combination of conditions and minimise the risk of having missing requirements that have not been detected and therefore not tested or developed.

Another advantage, is that listed in this graphical manner, requirements become much easier to understand and any illogical requirements can be spotted and corrected immediately.

A disadvantage of the technique is that a decision table does not replace a complete test case, but merely serves as an aid to help you understand how many test cases are needed and the underlying logic that explains their purpose.

 

When to use a decision table

Decision tables can be used in situations where the outcome of a rule depends on the combination of different choices.

Decision tables are ideally creating during system design, since they are useful to both developers and testers, while requirements specialists can be more confident the requirements in the documentation cover all conditions.

If there are no decision tables available, testers can create tables during test design in order to help them write more effective test cases.