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:

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.

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.

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

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.

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:

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.

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

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.

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.

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

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:

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.

   Are you an orphan, or are you or were you (until age 18) a ward/dependent of the court? If Yes, skip Step Four. If your parents are both living and married to each other, answer the questions about them. If your parent is widowed or single, answer the questions about that parent. If your widowed parent is remarried as of today, answer the questions about that parent and the person whom your parent married (your stepparent). If your parents are divorced or separated, answer the questions about the parent you lived with more during the past 12 months. (If you did not live with one parent more than the other, give answers about the parent who provided more financial support during the last 12 months, or during the most recent year that you actually received support from a parent.) If this parent is remarried as of today, answer the questions on the rest of this form about that parent and the person whom your parent married (your stepparent).

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.