Decision Table Testing

The techniques discussed so far view multiple input parameters separately from one another, and test cases are designed on the basis of individual values. Dependencies between the various input parameters and their effects on the test object’s output are not an explicit part of the test case specifications.

Side Note: Cause-Effect Graphing

[Myers 12] describes Cause-Effect Graphing—a technique that takes this kind of dependency into account when designing test cases. Part 4 of the ISO 29119 standard [ISO 29119] also describes this approach to testing. The logical relationships between cause and effect and the impact they have on a component or system are illustrated using a cause-effect graph. The precondition for this kind of analysis is that causes and their effects can be derived from the specifications. Each cause is described as an input condition comprised of input values or a combination of input values. Inputs are combined using logical operators (such as AND, OR, and NOT). The input condition—and therefore the cause—either holds true or it doesn’t. In other words, it can be true or false. The corresponding effects are handled analogously and recorded graphically (see figure 5-7).

Withdrawing cash from an ATM serves to illustrate the principle. In order to do this, the following conditions have to be met²³:

• The customer’s card is valid
• The correct PIN is entered
• A maximum of three PIN input attempts is allowed
• Money is available (in the account and in the ATM)

The possible (re)actions of the ATM are as follows:

• The card is rejected
• The user is asked to re-enter the PIN
• The card is confiscated
• The user is asked to enter a different sum of money
• Money is paid out

Figure 5-7 shows this example in the form of a cause-effect graph.

Fig. 5-7Cause-effect graph for an ATM

The graph makes it clear which combinations of conditions need to be met to cause a specific effect/action.

To derive test cases, the diagram has to be converted into a decision table (see table 5-15 below). The steps involved in the conversion are as follows:

1. Select an effect
2. Check the graph for combinations of causes that provoke the desired effect (or not)
3. Create a decision table with one column for all the cause combinations you have found and one for the states caused by the other effects
4. Check for duplicate entries in the decision table and remove if necessary

Decision table testing

Decision tables are often created without the help of cause-effect graph. They are often used during project specification (i.e., before testing) to help clarify certain situations.

Tests based on decision tables serve to identify “interesting” combinations of input values that are likely to cause system failures.

Decision tables are ideal for recording complex business rules (i.e., conditions) that the system must implement correctly. Different combinations of conditions usually cause varying results, and these can be systematically tested using a decision table.

In its simplest form, every combination of conditions yields a test case. However, conditions can influence or preclude each other, making some combinations redundant.

Decision table structure

The upper portion of a decision table contains the causes and the lower portion the effects. The columns on the right define the individual test situations—i.e., the combinations of conditions and their expected effects.

A decision table is divided into four sections:

• Upper left
  This is where the causes (conditions) are recorded in such a way that they can be answered with “yes” or “no”
• Upper right
  This is where all possible combinations of causes are recorded (n causes result in 2ⁿ combinations)
• Lower left
  Contains all the effects (actions)
• Lower right
  Contains records of which effect (action) should be provoked by which combination of causes

A decision table is created as follows:

Creating a decision table

1. All conditions that affect the issue at hand have to be determined. Each condition has to be formulated so that it can be answered with “yes” or “no”. Each condition is recorded in a single row at the upper left of the table.
2. All relevant actions have to be determined and are recorded in individual rows at lower left.
3. All possible combinations of conditions are recorded at upper right with no regard for potential dependencies.
4. All combinations of conditions (i.e., all columns on the right-hand side) have to be analyzed in order to decide which action should result from each. A cross (X) indicates an action that is to be executed. Multiple crosses are possible if multiple actions are required.

Every condition should correspond to at least one “yes” and at least one “no” in the table.

Optimize and consolidate

The decision table is complete when every possible combination of conditions is included. The table thus has as many columns as combinations. Columns that contain impossible combinations or possible but non-executable combinations can be deleted. The table can be further consolidated if different combinations of conditions lead to the same result. Once you have weeded out the unwanted cases, every column represents a test case, and no combinations and/or actions (i.e., test cases) are duplicated. Decision tables can also be checked for completeness, freedom from redundancy, and consistency.

Case Study: Decision table example

This example illustrates the basic principle.

A special offer for a limited period is aimed at increasing vehicle sales. All standard models receive an 8% discount and all special editions (for which no optional extras are available) a 10% discount. If more than three extras are selected for a standard model, these receive an additional 15% discount. All other models receive no additional base discount and no extra discount for additional extras.

The upper part of the corresponding decision table (with all the possible combinations) looks like this (see table 5-12):

Table 5-12The upper part of the decision table showing all combinations of conditions

Because some of the conditions preclude each other, the table can be correspondingly edited (“–” is interpreted as “don’t care”, see table 5-13):

Table 5-13Decision table including “don’t care” cases

The table can now be consolidated. Test cases 1–4 are identical and can be treated as one, as can test cases 7 and 8. The result is the following decision stable with a total of four test cases, each of which leads to a different action or sequence of actions (see table 5-14).

Table 5-14Consolidated decision table

This simple example shows that relatively few conditions and/or dependencies can quickly produce large, complex decision tables.

Side Note: Cause-Effect Graphing continued

To round out the ATM example cited above, here is the consolidated decision table created using cause-effect graphing:

Table 5-15Consolidated ATM decision table

Test Cases

This technique enables you to read the input conditions and dependencies, and the corresponding expected actions for each test case directly from the columns of the decision table. The table defines concrete test cases that, if necessary, can be augmented with preconditions, postconditions, and constraints before testing begins.

Defining Exit Criteria

Simple exit criteria

As with all the other techniques we have looked at, it is relatively simple to define exit criteria for decision table-based tests. The minimum requirement should be that every column in the table is covered by at least one test case. This ensures that every meaningful combination of conditions and reactions is tested.

Benefits and Limitations

This systematic and highly formal technique often reveals combinations of conditions that other test case creation techniques overlook. This technique helps to reveal gaps in the requirements, but you have to be careful not to unintentionally reject relevant test cases when consolidating the table.

As we have already seen, a decision table can quickly become very large and unwieldy with increasing numbers of conditions and corresponding actions. This makes the process difficult to handle without the support of dedicated tools.

Decision table tests can be applied on all test levels in any situation in which the system or component’s behavior depends on combinations of conditions.