Deriving Test Cases from Use Cases: A Four-Step Process

   

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.

  1. Identify the use-case scenarios.

  2. For each scenario, identify one or more test cases.

  3. For each test case, identify the conditions that will cause it to execute.

  4. Complete the test case by adding data values.

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

Scenario Number

Originating Flow

Alternate Flow

Next Alternate

Next Alternate

1

Basic flow

     

2

Basic flow

Alternate flow 1

   

3

Basic flow

Alternate flow 1

Alternate flow 2

 

4

Basic flow

Alternate flow 3

   

5

Basic flow

Alternate flow 3

Alternate flow 1

 

6

Basic flow

Alternate flow 3

Alternate flow 1

Alternate flow 2

7

Basic flow

Alternate flow 4

   

8

Basic flow

Alternate flow 3

Alternate flow 4

 

graphics/26fig02.gif

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.

  1. The use cases developed for implementation are not 100 percent exhaustive and are written at a level of detail that may be insufficient for testing.

  2. The test team's review process will create new discoveries and additional scenarios that may result from executing the use case. Some of these may not even have been considered in the design and may thus require design modifications.

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

Test Case ID

Scenario/ Condition

Data Value 1

Data Value 2

Data Value N

Expected Result

Actual Result

1

Scenario 1

         

2

Scenario 2

         

3

Scenario 2

         

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.

The homeowner enters the desired lighting sequence for each day of the week up to a maximum of seven different daily settings. The system confirms acceptance of each daily entry with a beep.

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

Test Case ID

Scenario/ Condition

Description

Expected Result

1

Scenario 6

Less than seven sequences entered

Sequence saved

System beeps

2

Scenario 6

Attempt to enter an eighth sequence

Error?

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.

  1. Valid (V) indicates a condition that must be true for the basic flow to execute.

  2. Invalid (I) indicates a condition that will invoke the alternate flow, causing a specific scenario to occur.

  3. Not applicable (N/A) indicates that an identified condition is not applicable to that specific test case ID.

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

Item

Value

Use-case name

Control Light

Actors

Resident and Light Bank

Brief description

This use case prescribes the way in which lights are turned on and off and also how they are dimmed and brightened in accordance with how long the user presses a button on the Control Switch.

Flow of events

Basic flow begins when the Resident presses the On/Off/Dim button on the Control Switch.

When the Resident removes pressure on the On/Off/Dim button within the timer period, the system "toggles" the state of the light as follows .

  • If the light is On, the light is then turned Off, and there is no illumination .

  • If the light is Off, the light is then turned On to the last remembered brightness level.

Alternative flow of events

When the Resident holds down the On/Off/Dim button for more than 1 second, the system initiates a brightening/ dimming activity for the room's Light Bank.

While the Resident continues to press the On/Off/Dim button:

  1. The brightness of the controlled light is smoothly increased to a system-wide maximum value at a rate of 10 percent per second.

  2. When the brightness reaches its maximum value, the brightness of the controlled light is then smoothly decreased to a system-wide minimum value at a rate of 10 percent per second.

  3. When the brightness reaches its minimum value, the use case continues at subflow step 1.

    When the Resident releases the On/Off/Dim button:

  4. The use case terminates and the brightness stays at the current level.

Pre-conditions

The selected On/Off/Dim button must be Dim Enabled.

The selected On/Off/Dim button must be preprogrammed to control a Light Bank.

Post-condition

On leaving this use case, the system remembers the current brightness level for the selected On/Off/Dim button.

Special requirements

Performance: For any action that is perceptible to the Resident, the response time from a control panel action to system response must be less than 50 milliseconds .

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

Test Case ID

Scenario

Description

Condition: Button Pressed < Timer Period

Condition: Button Pressed > Timer Period

Condition: Button Released After Being Held

Condition

Expected Result

1

1

Basic flow : Resident releases button before timer period ends

V

I

N/A

Light on

Light goes off

2

1

Basic flow : Resident releases button before timer period ends

V

I

N/A

Light off

Light goes on

3

2

Alternate flow : Resident continuously presses button for longer than timer period

I

V

N/A

N/A

Light level goes up and down continuously

4

3

Resident releases switch after continuously pressing button

I

I

V

N/A

Light stays at last brightness

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

Test Case ID

Scenario

Description

Condition: Button Pressed < Timer Period

Condition: Button Pressed > Timer Period

Condition: Button Released After Being Held

Condition

Expected Result

1

1

Basic flow : Resident releases button before timer period ends

< 1 sec. in .1-sec. intervals

I

N/A

Light on

Light goes off

2

1

Basic flow : Resident releases button before timer period ends

< 1 sec. in .1-sec. intervals

I

N/A

Light off

Light goes on

3

2

Alternate flow : Resident continuously presses button for longer than timer period

I

160 sec.

N/A

N/A

Light level goes up and down continuously

4

3

Resident releases switch after continuously pressing button

I

I

V

N/A

Light stays at last brightness

   


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
EAN: N/A
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net