How Can I Use the Business Use Case Models?
As we discussed in Chapter 2, business use case models provide the context in which your business operates. They serve as a context diagram for your business, depicting what is outside of your business (the business actors), what is inside the business (the business use cases), and their relationships (see Figure 7-1).
Business use cases are a source of candidate subsystems in the architecture of your system. The business use case diagram in Figure 7-1 might yield part of the system architecture as shown in Figure 7-2. Note that there is not necessarily a one-for-one relationship here. Every business use case does not necessarily become a subsystem. Multiple subsystems could be created for each business use case, or one subsystem could be derived from more than one business use case. This is why we say they are “candidate” subsystems—they are just a starting point for an architecture that will evolve during its development.
Figure 7-2. System architecture diagram.
System, Integration, and Subsystem Testing
This system architecture and its candidate subsystems can help you structure your testing. Where you focus establishes the structure and scope of your testing. For example, if you focus on the individual subsystems and their particular actors, you're performing a subsystem test. If you look at subsystems in combination, these provide the basis for integration tests between these subsystems. When you test all subsystems together, you're performing a system level test (see Figure 7-3).
The business actors in these models are the roles that testers can assume for testing purposes. What should these testers do? They can establish the specific test procedures using the activity diagrams that were developed as part of the business use case model. Remembering that the activity diagram scenarios in the business use case model depict the interaction between your external users and the system, they provide the basis for black box testing. Black box testing focuses on testing the externally visible behavior of the system (or element of the system) without knowledge of the internal structure of the element.
As we noted earlier, the business use case model can provide organization and structure to your test planning. You can easily identify candidate test plans based on the subsystems or combinations thereof. The activity diagrams of the business use case model can also provide a great start to the development of test procedures. The flows defined in the diagrams can provide the core of your test procedures, offering a great jump-start to their development.
Of course, you will need to add further details based on the standard information you include in your procedures. The activity diagrams can help to identify some of that additional information. For example, let's revisit the activity diagram from Chapter 2 for processing a sale (see Figure 7-4).
Activity diagrams can indicate places to define ranges of test data to use in your test scenarios. A good place to start is where the flows cross over between swimlanes (highlighted in Figure 7-5). Data and control information are often related to the activities that are connected by these flows.
Figure 7-5. Looking for data or control information between the swimlanes in activity diagrams.
For example, one activity asks for the “Payment Method.” This obviously leads you to a range of values for payment method, such as cash, credit, check, and maybe some less obvious ones, such as gift certificate or gift card, cashier's check, store credit voucher, and so forth. What about the activity “Give receipt to retail customer?” If that receipt is not given (i.e., nothing flows across the swimlanes), what happens? Consider the activity “Provide total cost.” Where does it get the cost to provide to the customer? This leads back to the activity “Enter price manually.” What actual prices would you use in testing? Don't forget boundary testing, that is, using test data that is at the extremes of the expected data range, particularly just beyond, at, and just within the upper and lower bounds of the data range. In this case, what happens if you enter $0.00 as a price? Can you enter a price such as “three for $1.00?” This question leads you to think about your expected results. If you buy two items at “three for $1.00,” at what level of precision do you expect the “Provide total cost” activity to provide the cost to the customer? When dealing with prices, you might expect an answer to two decimal places. But you need to verify that. And what about numeric rounding?
As with most visual models, activity diagrams can trigger a tremendously beneficial amount of critical thinking. In fact, as you use these diagrams to help create your test procedures, you are likely to find additional alternate paths that the designers might have overlooked. UML diagrams can provide a point of focus that no text-only representation can provide.