Working Smarter: Use Case Packages

In the section titled, "Working Smarter: Scenarios of a Use Case," we looked at the use of the operational profile of the scenarios of a single use case as a tool for planning. In this section, we look at examples that illustrate utilizing the operational profile of a package of use cases for planning.

Time-Boxing for a Package of Use Cases

We've already seen time boxing used as a strategy for deciding which scenarios of a use case should be covered in an inspection (see the "Time-Boxing an Inspection" section). To reiterate, time-boxing is a top-down planning strategy in which the duration of the task or project (that's the "top") is fixed, forcing hard decisions to be made about what scope can be delivered or tasks accomplished in the allotted time. One of the most common uses of time-boxing in testing will be to schedule the amount of time spent on test design per use case. Here's a simple example.

Next week, you are to start designing tests for the new sales order component of Figure 3.11. You have one week to spend on the task. To get an idea of how you want to spend your week, you construct the spreadsheet table of Figure 3.19 using the operational profile of the sales order component (refer to Figure 3.14).

Figure 3.19. Time-boxing the test design of use cases (hours rounded to nearest whole).

To keep it simple, you assume that you have about 40 hours to spend on test design, and then use the operational profile of the sales order component to allocate those hours across the nine use cases of the component. From doing this, you decide to spend a day on each of the four use cases that account for about 81% of the traffic through the component. The last day you'll spend on the other five use cases, which account for 20% of the traffic. Additionally, you decide to approach test design in the order of frequency of use; that way, if time runs out, you have tackled the most critical use cases first.

As you can see, applying an operational profile for a package of use cases is really no different from using a profile of the scenarios that make up a single use case. It is used to allocate effort, resources, or time based on the relative frequency of use cases in the package.

Transitioning from High-Level to Low-Level Planning

If it's not obvious yet, the operational profile for a package of use cases and the operational profile of the scenarios of each individual use case are intended to work in concert with one another. The former works at the high level, allocating time, effort, and resources across the use cases of a project or iteration; the latter works at the low level, allocating each use case's allotment across the scenarios. The next example illustrates this transition from high-level to low-level planning.

Your project is setting up an automated regression test bed that will run a smoke test after each build.^[5] The smoke test focuses on three key use cases, each with four scenarios. Performance is a big part of your project, so the smoke test simulates a load of 500 users logging on, in different ways, to perform various tasks (the use cases and their scenarios). Login account IDs for 500 "fake" users have been set up on the test bed; you have been asked to decide how to allocate the 500 user login IDs across the use cases and their scenarios.

^[5] A smoke test is a relatively simple testtypically automatedthat runs after each baseline build as a sanity check that the baseline doesn't "smoke" when run and is at least sound enough to warrant further attention (e.g., before going on for more thorough testing). Steve McConnell (1996) provides more details on daily builds and smoke tests as a development best practice.

Starting with the operational profile of the three use cases, you build a spreadsheet table that allocates the total number of login IDs across the three use cases (see Figure 3.20).

Figure 3.20. Allocation of login IDs at the use case level. Arrows illustrate calculation of IDs allotted to use case 1 (500 x .64=320).

Of the 500 login IDs, the profile calls for 320 going to use case 1, 100 to use case 2, and 80 going to use case 3.

Next, you extend the spreadsheet table to include the operational profile of scenarios in each of the three use cases; this operational profile takes the number of login IDs allotted to each use case (see Figure 3.20) and further allocates them to the scenario level (see Figure 3.21). The result is a smoke test that loads the system in a manner consistent with how you believe your users will be using the system.

Figure 3.21. Allocation of login IDs to the use case level and then to the scenario level. Arrows illustrate calculation of IDs allotted to use case 1 (500 x .64=320) and then the subsequent calculation of what part of that allotment is to go to scenario 4 (320 x .04=13).

Air Bags and Hawaiian Shirts

There are some things you buy in life hoping to never actually use, air bags for example. Use them once and the price paid is well worth the cost. But then there is that Hawaiian shirt you bought while on vacation with the hula-dancer in a grass skirt saying "Mele Kaliki Maka" (that's "Merry Christmas" in Hawaiian). True, you cut a handsome figure at the office Christmas party in that shirt. But practically speaking, had you paused for a moment and reflected on the number of opportunities in the course of a year that you would actually wear that shirt, you probably would not have shelled out the $80 you paid. Sometimes it pays to evaluate the cost of something in terms of how frequentlyor infrequentlyyou actually think it will be used.

You are reviewing the operational profile for a package of use cases your project's product manager has been working on with the customer and mentally trying to estimate the effort required to implement each use case. In doing this, it occurs to you that, in general, there is no reason why the cost to implement a use case should go down just because it is infrequently used. A use case that is used once a year can cost just as much to implement as one that is used daily. You decide to try an experiment.

Working with nice round numbers, you do a rough estimate of the staff days to implement each use case; for example, two developers for a month = 40 staff days. Combining these estimates with the operational profile, you build the spreadsheet table of Figure 3.22, which includes a column that calculates the ratio of effort to percentage-point of use for each use case. After some scrutiny of Figures 3.22 and 3.23, which plots a bar chart of this ratio, you decide it's time to talk with the product manager to determine if some of these use casesfor example use case 11are air bags (used infrequently, but well worth the cost) or Hawaiian shirts (used infrequently and you paid how much?!).

Figure 3.22. Evaluating ratio of effort to percentage point of use. Is use case 11 an "air bag" or "Hawaiian shirt?"