Using Decision Tables for Clear, Well-Designed Testing

Let’s say you, a tester, are presented with a scenario and asked to design the test cases required. In this case, the customer describes the process to log into their newly developed application as follows:

• User enters their user ID
• User then enters their password
  • If the user enters the incorrect password three times, the account is locked

Drawing on your knowledge of specification-based testing techniques, what do you think is the best way to approach test case design for this task?

Consider using decision tables in your testing. Decision tables allow you to create a graphical representation of the possible interactions and provide the information you need to develop an effective, efficient set of test cases.

Designing a Decision Table

Decision tables are used to test the interactions between combinations of conditions. They provide a clear method to verify testing of all pertinent combinations to ensure that all possible conditions, relationships, and constraints are handled by the software under test.

Continuing with the user login example above, to help add clarity to the requirement, you’d take the information provided in the use case and display it visually:

For the situation under test, there are four potential conditions:

1. ID is valid—yes or no?
2. Password is valid—yes or no?
3. There have been three invalid password attempts—yes or no?
4. Access to system is granted—yes or no?

To test each of those interactions, the full decision table contains sixteen columns:

But designing these sixteen test cases is only the first step. An additional layer of analytical review is needed to arrive at what is known as a collapsed decision table.

Refining Test Cases

When trying to test every possible combination, decision tables can become very large. The method of intelligently reducing the number of combinations from every possibility to only those considered "interesting" is called collapsed decision table testing.

In this technique, the combinations are pared down to those that will produce differing outputs by removing sets of conditions that are not relevant for the outcome. We remove redundant tests or tests in which the combination of conditions is not possible.

By adding this additional layer of analysis to the test plan design, the tester can provide more effective and efficient testing.

Looking at the full sixteen combinations we identified, we can now cut those down by eliminating redundant conditions and impossible conditions.

The first thing we notice is that there are multiple conditions where the ID is shown as not valid. We’d expect that all of those would be treated the same way, because the system will always handle an invalid ID entry the same, regardless of the password entered or how many times the invalid ID was entered.

Let’s highlight those conditions on our decision table:

Next, we notice that there is an impossible condition that can be eliminated: When the password is correct, there is no possibility that the third password attempt would be invalid. We can highlight that column in blue on the decision table:

Here’s another redundant condition: When the password is valid and it is not the third attempt, only one test case is needed to cover that condition. Let’s change that scenario on the decision table to green:

Lastly, when the user enters their password correctly on the third attempt, only one test case is needed in that scenario as well. This final update to the decision table is now in purple:

As a result, we can now see that there are only five test cases needed in the collapsed decision table:

This technique also produces a clean table that can be shared with management and stakeholders to help explain why the test scenarios were selected and how the number of test cases was reduced to make testing more effective and efficient.

Here is a sample output:

In the example used here, we were able to cut the number of test cases from sixteen down to just five—a reduction of nearly 70 percent! This is also possible in real-life situations.

Using Decision Tables Practically

Earlier this year, I was presented with a complex scenario where ten conditions would interact with one another. My challenge was to intelligently cull those one hundred test cases to a more reasonable number.

The first thing I did was create the full decision table, just like we went through in the example. After that, based on the requirements, we were able to eliminate half of the test case combinations right away because they dealt with a user already logged into the system, and we didn’t have to consider the situations where the answer to that question was no. That was a 50 percent reduction right away, with very little analysis involved.

After working with development and business partners to define requirements and further think about what we could get rid of, I was able to create a test plan for the application that was only twenty-two test cases—a reduction of 78 percent.

Decision tables are a powerful specification-based test design technique that can be used for a variety of scenarios. The graphical representation is also a great benefit for working with stakeholders and nontechnical members of the project team because it provides an illustrative example that is easily understood by everyone.

Taking the next step and applying the concepts described to reduce the possible conditions and create a collapsed decision table make it easy to further show management how effective and efficient this test technique can be.

Using decision tables is not always easy, but in my experience, the results reaped from the exercise are always worth the effort. Try this technique to make your test design process more efficient, effective, and understandable.