Test Design Techniques: Decision Tables

Posted in Functional Testing

Part one of the Test Design Technique series covered equivalence partitioning (EP). Part two of the Test Design Technique series covered the use of boundary value analysis (BVA).

Decision tables, also known as cause-effect tables, are used as a test design technique to determine test scenarios from combinations of inputs. A table consisting of rows and columns is filled in with conditions, True or False designations, and the result(s) expected to occur based on combinations of the conditions. These can be used by software testers as an easy way to lay out all possible combinations of inputs and determine all the scenarios that can be exercised.

Let's assume we are tasked with testing whether free shipping is available for online purchases for an e-commerce website. One of the requirements states that free shipping is available for users who have a paid membership to the website. Another requirement states that free shipping is available for purchases $25 and over. From these requirements, a decision table can be generated:

Decision Table

There are four possible scenarios when testing these two conditions together, three of which should result in free shipping for the customer, and one which should result in the customer paying for shipping.


Additional Conditions

Suppose there is another requirement that international addresses are excluded from receiving free shipping for orders over $25, unless the person has a paid membership. Our updated decision table then looks like this:

Decision Table

Notice that by adding just one condition, the number of possible combinations doubled to eight. Four conditions requires 16 columns, five conditions require 32 columns, and so on. Given the complexity of testing so many combinations, testers may want to use many decision tables with few conditions, rather than a few decision tables with many conditions.


Additional Actions

In addition to multiple conditions, decision tables can have multiple actions. For this example, we'll assume that we are tasked with testing auto insurance discounts. The first requirement is that a Safe Driver discount will be applied if the driver is under 25 years old and has not had an at-fault accident or moving violation in the past three years. The second requirement is that a Good Student discount will be applied if the driver is under 25 years old and maintains a 3.5 GPA. We can determine that there are three conditions, one of which is shared between the two discounts. The two actions will be the two separate discounts that could result from the possible combinations of the conditions. So, a decision table for testing these requirements should look like this:

Decision Table

Summary

By generating decision tables based on the requirements, testers have an easy visual to help determine test scenarios. With each condition added, however, the number of scenarios doubles, so the usefulness of a decision table is limited if there are numerous conditions. Each scenario should be used to create more detailed test cases that show, step-by-step, the conditions being applied and the expected results.


COMING SOON: Part 4 of the Test Design Technique series will cover state transition testing.