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
Buy?	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
Buy?	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
Buy?	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.

   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.