Earlier in the book we described a use case as a sequence of events between an actor and a system. We also stated that a variety of alternate paths can be executed. In each case, we described this in the abstract, that is, things the system can do and things the user can do, but without specifics. As we move into test cases, we need to be more specific, and we need to think in terms of specific scenarios that occur for each use case.
For example, let's look at Figure 26-2. You'll note that there are multiple possible scenarios. For example, a user might begin by following the basic flow, followed by alternate flow #1. Or, a user might execute part of the basic flow, followed by alternate flow #1, followed by alternate flow #2, resulting in a premature exit from the use case, perhaps due to an error condition. Each of these paths is a scenario, or use-case instance, that can be both executed and tested .
Figure 26-2. Scenarios for a use case
In understanding this, we also come to understand one of the most significant challenges with system testing: even with a limited number of use cases, a large number of specific scenarios must be tested to assure that the system behaves in accordance with its requirements.