Use cases and test cases come from different origins and serve different, albeit related , purposes. Moving from one to another is a nontrivial but reasonably stepwise process. Now that we've defined the concept of use-case scenarios, we can prescribe a four-step process to accomplish this objective.
Step 1: Identify the Use-Case Scenarios
Since we have a oneto-many relationship between use cases and scenarios, we need some organizing technique to manage this potential information explosion. We'll use a simple matrix that can be implemented in a spreadsheet, database, or test management tool. In order to keep track of things, we also need to number each scenario and define exactly what combination of basic and alternate flows that particular scenario represents. Returning to Figure 26-2, we could construct a matrix similar to the one in Table 26-1.
In Table 26-1 we've identified eight possible scenarios for the sample use case. Note that the use case we've described is not an overly complex one, and yet a significant number of scenarios may result. As the use cases grow more complex, more and more scenarios will result. In many situations, the tester will need to devise a testing strategy that recognizes that it is impractical to test all possible scenarios but still assures that adequate testing is achieved. Even then, this technique can be used to identify all the possible scenarios that could be tested .
Table 26-1. Scenario Matrix for Figure 26-2
In addition, the tester should be aware that not all scenarios may be described in the original use case and that this scenario discovery process may well need to be conducted interactively with the development team. There are two reasons for this.
This is yet another reason we've adopted the iterative model in our lifecycle approach; it allows us to effectively plan for and manage this process. In any event, the process is a beneficial one, and a better system should result as the testing team reviews the use cases and finds holes and additional alternate scenarios.
Step 2: Identify the Test Cases
Testing processes vary from company to company and even from project to project, but in each situation a test case documents a number of common items. Whether in a spreadsheet, document, database, or testing tool, the test case should contain the parameters of the test to be conducted, including the conditions of the test and the expected results. One common format, illustrated in Table 26-2, is to use a matrix in which each row represents a specific test case and the columns represent scenarios, conditions, data values, and expected and actual results.
Table 26-2. Matrix for Testing Specific Scenarios
Note in Table 26-2 that more than one test case can result from a specific scenario (see test case IDs 2 and 3, both for scenario 2). Typically, this arises because of various logical constructs identified in a single step in a use case. For example, consider the following step in a HOLIS use case.
This single step in the use case will produce two test cases from this step (Table 26-3).
In addition, note that in this process we've discovered an ambiguity that will have to be resolved: "What does the system do if the user attempts to enter more than seven settings?" The test team will have to caucus with the development team on that one. Such is the nature of our iterative discovery process.
Table 26-3. Two Test Cases for One Scenario
Step 3: Identify the Test Conditions
The next step is to identify the specific conditions in the test case that would cause it to execute. In other words, what conditions cause a user to execute a specific event or sequence of events within a use case? During this process, the tester searches the use-case steps for the various data conditions, branches, and so on that would cause a specific test case to occur. For each such condition identified, the tester enters a new column in the matrix, representing the specific condition identified. In this initial pass, it is adequate to simply identify that a condition exists, create the column entry, and then indicate which of the three states that could occur for that condition (valid, invalid, or not applicable ) is appropriate.
To illustrate , let's look at another HOLIS example. Consider the Control Light use case described in Table 26-4.
In this use case, we have three separate conditions to consider (button pressed for less than one second, button pressed for greater than one second, and button released after being pressed for more than one second) that trigger changes in the behavior of the system. Specifically, they trigger scenario 1, scenario 2, and scenario 3, which in this case translates to the basic flow and alternate flows plus a branch on the alternate flow.
We can now create a matrix of the test cases, Table 26-5, which identifies each of these conditions as valid or invalid, and we can document the expected result in each case.
Table 26-4. Sample HOLIS Use Case: Control Light
Step 4: Add Data Values to Complete the Test Case
We've made good progress. We have now identified all the conditions that need to be tested to test a specific use case fully. We're not quite done, howeverwithout real data, test cases are merely descriptions of conditions, scenarios, and paths without concrete values to identify them succinctly. Without such data, it's not possible to execute the test case and determine the results. In many cases, the use cases themselves will not directly identify these data values, and you will have to look to supplementary specifications to find performance specs , valid data ranges for input forms and interface protocols, and so on. However, this is not a new problem to the tester; just use your normal techniques for finding the data ranges.
Table 26-5. Control Light Test Cases with Identified Conditions
This is also the time to make sure that test cases address any special requirements defined for the use case. These include such things as minimum/maximum performance, sometimes combined with minimum/maximum loads, or data volumes expected during the execution of the use cases.
Once you have identified the data ranges, you can finalize the test matrix with those values. Then you are ready to execute the test cases. For our HOLIS Control Light test case, the result might look like Table 26-6.
Table 26-6. Control Light Test Cases with Data Values