Decision Table Testing

I'd stumbled onto solving my first murder case, having found myself the only eyewitness, yet no matter how frantically I pleaded with John Law that the perp was right in front of them and the very dame they'd been grilling - the sultry but devious Miss Kitwinkle, who played the grieving patsy the way a concert pianist player plays a piano - the cops just kept smiling and stuffing crackers in my beak.

— Chris Esco

Introduction

Decision tables are an excellent tool to capture certain kinds of system requirements and to document internal system design. They are used to record complex business rules that a system must implement. In addition, they can serve as a guide to creating test cases.

Decision tables are a vital tool in the tester's personal toolbox. Unfortunately, many analysts, designers, programmers, and testers are not familiar with this technique.

Technique

Decision tables represent complex business rules based on a set of conditions. The general form is:

Table 5-1: The general form of a decision table.

Rule 1

Rule 2

Rule p

Conditions

• Condition-1

• Condition-2

• Condition-m

Actions

• Action-1

• Action-2

• Action-n

Conditions 1 through m represent various input conditions. Actions 1 through n are the actions that should be taken depending on the various combinations of input conditions. Each of the rules defines a unique combination of conditions that result in the execution ("firing") of the actions associated with that rule. Note that the actions do not depend on the order in which the conditions are evaluated, but only on their values. (All values are assumed to be available simultaneously.) Also, actions depend only on the specified conditions, not on any previous input conditions or system state.

Perhaps a concrete example will clarify the concepts. An auto insurance company gives discounts to drivers who are married and/or good students. Let's begin with the conditions. The following decision table has two conditions, each one of which takes on the values Yes or No.

Table 5-2: A decision table with two binary conditions.

Rule 1

Rule 2

Rule 3

Rule 4

Conditions

• Married?

Yes

Yes

No

No

• Good Student?

Yes

No

Yes

No

Note that the table contains all combinations of the conditions. Given two binary conditions (Yes or No), the possible combinations are {Yes, Yes}, {Yes, No}, {No, Yes}, and {No, No}. Each rule represents one of these combinations. As a tester we will verify that all combinations of the conditions are defined. Missing a combination may result in developing a system that may not process a particular set of inputs properly.

Now for the actions. Each rule causes an action to "fire." Each rule may specify an action unique to that rule, or rules may share actions.

Table 5-3: Adding a single action to a decision table.

Rule 1

Rule 2

Rule 3

Rule 4

Conditions

• Married?

Yes

Yes

No

No

• Good Student?

Yes

No

Yes

No

Actions

• Discount (\$)

60

25

50

0

Decision tables may specify more than one action for each rule. Again, these rules may be unique or may be shared.

Table 5-4: A decision table with multiple actions.

Rule 1

Rule 2

Rule 3

Rule 4

Conditions

• Condition-1

Yes

Yes

No

No

• Condition-2

Yes

No

Yes

No

Actions

• Action-1

Do X

Do Y

Do X

Do Z

• Action-2

Do A

Do B

Do B

Do B

In this situation, choosing test cases is simple—each rule (vertical column) becomes a test case. The Conditions specify the inputs and the Actions specify the expected results.

While the previous example uses simple binary conditions, conditions can be more complex.

Table 5-5: A decision table with non-binary conditions.

Rule 1

Rule 2

Rule 3

Rule 4

Conditions

• Condition-1

0–1

1–10

10–100

100–1000

• Condition-2

<5

5

6 or 7

>7

Actions

• Action-1

Do X

Do Y

Do X

Do Z

• Action-2

Do A

Do B

Do B

Do B

In this situation choosing test cases is slightly more complex— each rule (vertical column) becomes a test case but values satisfying the conditions must be chosen. Choosing appropriate values we create the following test cases:

Table 5-6: Sample test cases.

Test Case ID

Condition-1

Condition-2

Expected Result

TC1

0

3

Do X / Do A

TC2

5

5

Do Y / Do B

TC3

50

7

Do X / Do B

TC4

500

10

Do Z / Do B

If the system under test has complex business rules, and if your business analysts or designers have not documented these rules in this form, testers should gather this information and represent it in decision table form. The reason is simple. Given the system behavior represented in this complete and compact form, test cases can be created directly from the decision table.

In testing, create at least one test case for each rule. If the rule's conditions are binary, a single test for each combination is probably sufficient. On the other hand, if a condition is a range of values, consider testing at both the low and high end of the range. In this way we merge the ideas of Boundary Value testing with Decision Table testing.

 Key Point Create at least one test case for each rule.

To create a test case table simply change the row and column headings:

Table 5-7: A decision table converted to a test case table.

Test Case 1

Test Case 2

Test Case 3

Test Case 4

Inputs

• Condition-1

Yes

Yes

No

No

• Condition-2

Yes

No

Yes

No

Expected Results

• Action-1

Do X

Do Y

Do X

Do Z

• Action-2

Do A

Do B

Do B

Do B

Examples

Decision Table testing can be used whenever the system must implement complex business rules. Consider the following two examples:

Example 1

Referring to the Trade Web page of the Brown & Donaldson Web site described in Appendix A, consider the rules associated with a Buy order.

Table 5-8: A decision table for the Brown & Donaldson Buy order.

Rule 1

Rule 2

Rule 3

Rule 4

Rule 5

Rule 6

Rule 7

Rule 8

Conditions

• Valid Symbol

No

No

No

No

Yes

Yes

Yes

Yes

• Valid Quantity

No

No

Yes

Yes

No

No

Yes

Yes

• Sufficient Funds

No

Yes

No

Yes

No

Yes

No

Yes

Actions

No

No

No

No

No

No

No

Yes

Admittedly, the outcome is readily apparent. Only when a valid symbol, valid quantity, and sufficient funds are available should the Buy order be placed. This example was chosen to illustrate another concept.

Examine the first four columns. If the Symbol is not valid, none of the other conditions matter. Often tables like this are collapsed, rules are combined, and the conditions that do not affect the outcome are marked "DC" for "Don't Care." Rule 1 now indicates that if the Symbol is not valid, ignore the other conditions and do not execute the Buy order.

Table 5-9: A collapsed decision table reflecting "Don't Care" conditions.

Rule 1

Rule 2

Rule 3

Rule 4

Rule 5

Conditions

• Valid Symbol

No

Yes

Yes

Yes

Yes

• Valid Quantity

DC

No

No

Yes

Yes

• Sufficient Funds

DC

No

Yes

No

Yes

Actions

No

No

No

No

Yes

Note also that Rule 2 and Rule 3 can be combined because whether Sufficient Funds are available does not affect the action.

Table 5-10: A further collapsed decision table reflecting "Don't Care" conditions.

Rule 1

Rule 2

Rule 3

Rule 4

Conditions

• Valid Symbol

No

Yes

Yes

Yes

• Valid Quantity

DC

No

Yes

Yes

• Sufficient Funds

DC

DC

No

Yes

Actions

No

No

No

Yes

While this is an excellent idea from a development standpoint because less code is written, it is dangerous from a testing standpoint. It is always possible that the table was collapsed incorrectly or the code was written improperly. The un-collapsed table should always be used as the basis for our test case design.

Example 2

The following screen is from the Stateless University Registration System. It is used to enter new students into the system, to modify student information, and to delete students from the system.

Figure 5-1: SURS Student Database Maintenance Screen.

To enter a new student, enter name, address, and telephone information on the upper part of the screen and press Enter. The student is entered into the database and the system returns a new StudentID. To modify or delete a student, enter the StudentID, select the Delete or Modify radio button and press Enter. The decision table reflecting these rules follows:

Table 5-11: A decision table for Stateless University Registration System.

Rule 1

Rule 2

Rule 3

Rule 4

Rule 5

Rule 6

Rule 7

Rule 8

Rule 9

Rule 10

Rule 11

Rule 12

Rule 13

Rule 14

Rule 15

Rule 16

Conditions

• Entered Student data

No

No

No

No

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

• Entered Student ID

No

No

No

No

Yes

Yes

Yes

Yes

No

No

No

No

Yes

Yes

Yes

Yes

• Selected Modify

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

• Selected Delete

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

Actions

• Create new student

No

No

No

No

No

No

No

No

Yes

No

No

No

No

No

No

No

• Modify Student

No

No

No

No

No

No

Yes

No

No

No

Yes

No

No

No

No

No

• Delete Student

No

No

No

No

No

Yes

No

No

No

No

No

No

No

No

No

No

Rules 1 through 8 indicate that no data was entered about the student. Rules 1 through 4 indicate that no StudentID was entered for the student, thus no action is possible. Rules 5 through 8 indicate the StudentID was entered. In these cases creating a new Student is not proper. Rule 5 does not request either modification or deletion so neither is done. Rules 6 and 7 request one function and so they are performed. Note that Rule 8 indicates that both modification and deletion are to be performed so no action is taken.

Rules 9 through 16 indicate that data was entered about the student. Rules 9 through 12 indicate that no StudentID was entered so these rules refer to a new student. Rule 9 creates a new student. Rule 10 deletes the student. Rule 11 allows modification of the student's data. Rule 12 requests that both modification and deletion are to be performed so no action is taken. Rules 13 through 16 supply student data indicating a new student but also provide a StudentID indicating an existing student. Because of this contradictory input, no action is taken. Often, error messages are displayed in these situations.

Applicability and Limitations

Decision Table testing can be used whenever the system must implement complex business rules when these rules can be represented as a combination of conditions and when these conditions have discrete actions associated with them.

Summary

• Decision tables are used to document complex business rules that a system must implement. In addition, they serve as a guide to creating test cases.
• Conditions represent various input conditions. Actions are the processes that should be executed depending on the various combinations of input conditions. Each rule defines a unique combination of conditions that result in the execution ("firing") of the actions associated with that rule.
• Create at least one test case for each rule. If the rule's conditions are binary, a single test for each combination is probably sufficient. On the other hand, if a condition is a range of values, consider testing at both the low and high end of the range.

Practice

1. Attending Stateless University is an expensive proposition. After all, they receive no state funding. Like many other students, those planning on attending apply for student aid using FAFSA, the Free Application for Federal Student Aid. The following instructions were taken from that form. Examine them and create a decision table that represents the FAFSA rules. (Note: You can't make up stuff like this.)

Step Four: Who is considered a parent in this step?

Read these notes to determine who is considered a parent for purposes of this form. Answer all questions in Step Four about them, even if you do not live with them.

References

Beizer, Boris (1990). Software Testing Techniques (Second Edition). Van Nostrand Reinhold.

Binder, Robert V. (2000). Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison-Wesley.

A Practitioners Guide to Software Test Design
ISBN: 158053791X
EAN: 2147483647
Year: 2003
Pages: 161
Authors: Lee Copeland
Simiral book on Amazon