DECISION TABLES

9.6 DECISION TABLES

A major limitation of the EC-based testing is that it only considers each input separately. The technique does not consider combining conditions. Different com- binations of equivalent classes can be tried by using a new technique based on the decision table to handle multiple inputs. Decision tables have been used for many years as a useful tool to model software requirements and design decisions. It is a simple, yet powerful notation to describe complex systems from library information management systems to embedded real-time systems [18].

The general structure of a decision table is shown in Table 9.11. It comprises

a set of conditions (or causes) and a set of effects (or results) arranged in the form of a column on the left of the table. In the second column, next to each condition, we have its possible values: yes (Y), no (N), and don’t care (dash). To the right of the values column, we have a set of rules. For each combination of the three

conditions {C 1 ,C 2 ,C 3 }, there exists a rule from the set {R 1 ,R 2 ,···,R 8 }. Each rule comprises a yes, no, or don’t care response and contains an associated list

of effects {E 1 ,E 2 ,E 3 }. Then, for each relevant effect, an effect sequence number specifies the order in which the effect should be carried out if the associated set

of conditions are satisfied. For example, if C 1 and C 2 are true but C 3 is not true, then E 3 should be followed by E 1 . The checksum is used for verification of the combinations the decision table represents.

TABLE 9.11 Decision Table Comprising Set of Conditions and Effects Rules or Combinations

Conditions Values R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8

C 1 Y, N,—

NNNN C 2 Y, N,—

YN C 3 Y, N,—

YNYN

Effects

Checksum

249 Test data are selected so that each rule in a table is exercised and the actual

9.6 DECISION TABLES

results are verified with the expected results. In other words, each rule of a decision table represents a test case. The steps in developing test cases using the decision table technique are as follows:

Step 1: The test designer needs to identify the conditions and the effects for each specification unit. A condition is a distinct input condition or an EC of input conditions. An effect is an output condition. Determine the logical relationship between the conditions and the effects.

Step 2: List all the conditions and effects in the form of a decision table. Write down the values the condition can take.

Step 3: Calculate the number of possible combinations. It is equal to the number of different values raised to the power of the number of conditions.

Step 4: Fill the columns with all possible combinations—each column corre- sponds to one combination of values. For each row (condition) do the following:

1. Determine the repeating factor (RF): divide the remaining number of combinations by the number of possible values for that condition.

2. Write RF times the first value, then RF times the next, and so forth until the row is full.

Step 5: Reduce combinations (rules). Find indifferent combinations—place a dash and join column where columns are identical. While doing this, ensure that effects are the same.

Step 6: Check covered combinations (rules). For each column calculate the com- binations it represents. A dash represents as many combinations as the condition has. Multiply for each dash down the column. Add up total and compare with step 3. It should be the same.

Step 7: Add effects to the column of the decision table. Read column by column and determine the effects. If more than one effect can occur in a sin- gle combination, then assign a sequence number to the effects, thereby specifying the order in which the effects should be performed. Check the consistency of the decision table.

Step 8: The columns in the decision table are transformed into test cases. Decision table–based testing is effective under certain conditions as follows:

• The requirements are easily mapped to a decision table. • The resulting decision table should not be too large. One can break down

a large decision table into multiple smaller tables. • Each column in a decision table is independent of the other columns.

Example: Let us consider the following description of a payment procedure. Consultants working for more than 40 hours per week are paid at their hourly rate for the first 40 hours and at two times their hourly rate for subsequent hours. Consultants working for less than 40 hours per week are paid for the hours worked