Working Smarter: Scenarios of a Use Case

To this point, we've been talking about how to build an operational profile of the scenarios that make up a single use case. Now we get to the working smarter part of operational profiles: putting them to work.

In this section, we look at examples that illustrate utilizing the use case operational profile in planning. Many of the examples will come from test planning; testing is a key consumer of the operational profile, plays a fundamental role in product reliability, and represents one of the biggest costs in a project. But keep in mind that operational profiles can be used as a way to prioritize and allocate effort and resources for just about every facet of development.

In planning and estimation, two common approaches are time-boxing and bottom-up. Time-boxing is a top-down strategy usually associated with iterative software development in which the duration of task or project (that's the "top") is fixed, forcing hard decisions to be made about what scope can be delivered in the allotted time. The other strategy is bottom-up, in which you start with the scope to be developed and tested (use cases; that's the "bottom"), then roll-up estimates from that level to determine the time needed for the overall task or project (the "top").

In the next several examples, we look at the operational profile as used in top-down and bottom-up planning.

Time-Boxing an Inspection

Let's say you are planning an inspection of the use case your team has just developed, and the decision graph of Figure 3.2 and operational profile of Table 3.1 are for this new use case. You have a one-time shot at getting key domain experts and customer reps as part of the review team. The inspection is scheduled to last three hours. What is the best use of the review team's time?

First, you determine the order in which to review the materials by using the operational profile for the use case: those with highest relative frequency in the operational profile first. That way, if you run out of time in the reviewand chances are, you willyou will have covered the most frequently used scenarios first. Second, the operational profile provides a way to sensibly allocate time in the review in proportion to the relative frequency of the scenarios in the use case.

The spreadsheet of Figure 3.8 illustrates an allocation of review time in hours per scenario based on the operational profile. Scenario 1, 2, 3, 4 accounts for 64% of the traffic we expect through this use case; accordingly, you decide that if the review team is on a roll and finding good issues, you plan to allocate 64% of the review time1.9 to 2 hoursto just this high-frequency scenario. If the review team finishes in less time, great! Otherwise, it's worth a full two hours. At the end of the two hours, you plan to move on to the next two scenarios1, 2, 3, 1 and 1, 2, 3a, 4which account for 16% and 13% of the use case traffic, respectively. This works out to about one-half hour of review time each for these two scenarios (3 hours times 16% = .5 hours; 3 hours times 13% = .4 hours).

Figure 3.8. Priority order and breakdown of time (hours) to allocate per use case scenario during inspection.

In the three-hour review, you plan to spend your time on the scenarios that account for 93% of the traffic through the use case. If the review team finishes these scenarios ahead of time, you can move on to the last three, which collectively account for only 7% of the traffic. This, you feel, is a better strategy than having the review team rush to try to get through all six scenarios.

As this example illustrates, the idea behind working smart with operational profiles is very straightforward: you simply allocate effort, resources, or, in this case, time, based on the relative frequency of each scenario in the use case. Next, you'll see an example of allocation of resource via an operational profile; in this case, test cases.

Bottom-Up Estimation of Tests Needed per Scenario

The previous example looked at using an operational profile in a top-down, time-boxing fashion. Another common strategy for planning is bottom-up. In bottom-up planning, you start with the scope to be developed and tested (use cases; that's the "bottom"), make estimates at that level, and then roll them up to determine the time needed for the overall project, event, or phase (the "top"). Here's an example of an operational profile used in bottom-up planning to estimate the number of tests you need for each scenario of a use case. Time estimates, say for test design and or test execution, can be made by multplying the number of tests by an estimate of time needed per test. For a package of use cases, this process would be applied for each use case in the package to get a bottom-up estimate for the package as a whole.

You have been asked to design and run tests on the new Widget Manager Use Case and asked for an estimate of how long it might take. The use case has six scenarios, so to get things going you start with the assumption that, at minimum, each scenario will require one test, for a total of six. Using the use case's operational profileimplemented via a spreadsheetyou build the table shown in Figure 3.9 to see how those six tests would be allocated as per the profile.

Figure 3.9. Allocation of six tests via the operational profile. Formula shown in Excel.

The operational profile calls for the bulk of tests to be allocated to the first three scenarios, which account for 96% of the use case traffic; this makes sense. You see, however, that the last three scenarios, which only account for 4% of the use case traffic, receive only fractions of a test each. You realize fractions of a test make no sense. But rather than pull tests away from the other scenarios (remember that they are 96% of the use case traffic), you decide to round up all fractions to the next higher whole number of tests (see Figure 3.10).

Figure 3.10. Fractions of tests as per operational profile are rounded up to the next higher whole number of tests. Formula shown in Excel.

Eleven tests, as allocated in Figure 3.10, strike a good balance between allocating tests in a way that makes sense as per the operational profile and having at least one test per scenario. Finally, you estimate three staff hours to design and execute a test, for a total of 33 staff hours for the whole use case.

Whether you plan top-down (e.g., time-boxing) or bottom-up, operational profiles are a smart way to allocate time, effort, and resources across the scenarios of a use case.