How Can I Use the Business Analysis Models?

While the business use case model provides the external view of your business, the business analysis model provides the view of what your business does internally. As you might recall, the business analysis model elements are those people and things inside your business that perform the activities to satisfy the requests made upon your business. (See Figure 7-6, which depicts a business analysis model we showed you in Chapter 2.)

In this case, this business analysis model shows what happens inside your business to fulfill an order. This obviously leads us to realize that the business analysis model can help establish the white box tests of your system. White box testing focuses on testing the internals of the system (i.e. elements that exist inside your subsystems). One possible architecture is shown in Figure 7-7.

Figure 7-7. Business analysis model elements and subsystems.

[View full size image]

Integration and Subsystem Testing

As with black box testing, your focus during white box testing determines the scope and structure of the white box testing you will perform. If you focus on the individual subsystems and their particular business workers, then you have a subsystem white box test. If you look at subsystems in combination, these provide the basis for white box integration tests between these subsystems (if there is a need to do such detailed testing at an integration level). When you take all subsystems together, you have a system-level white box test. Keep in mind that in a system of significant size, such a system-level white box test might be prohibitively complex. However, such an approach would provide a great way to validate your architecture early in the development. Some wise advice: “Test the architecture by using the scenarios to walk through the system. Does this work? Do you have all the interfaces you need to implement the scenarios?” [SCHN1]

Details for these white box test procedures can come from the business analysis model's sequence diagrams. They indicate the flow of control and messages between the elements in your model, providing a jump-start to test procedure development. As with the activity diagrams for white box testing, you might need to add additional testing details to your procedures. You can augment the sequence diagrams to add that additional information. For example, let's revisit the sequence diagram from Chapter 2 for creating an order (see Figure 7-8).

Figure 7-8. Sequence diagram for creating an order for a retail sale.

[View full size image]

The sequence diagram flow provides the basic test flow for this scenario. Each message flowing between the model elements is a potential place for further elaboration. If the message is providing data at a given point (such as “Add Personal Information” in Figure 7-8), you could test various data ranges there. If the message indicates the system is performing certain processing (such as “Calculate Total Price” in Figure 7-8), you must consider whether you should test performance requirements there. If the system must return the Total Price within 10 seconds, you can annotate this diagram appropriately. Control flows (such as “Add Product to Order” in Figure 7-8) provide excellent opportunities to examine possible alternate flows. Hopefully, whoever created these diagrams already considered such alternate flows. But if not, here is another opportunity for test people to affect the system design early in the development lifecycle, helping create a more robust and higher quality system (see the test-related annotations in Figure 7-9).

Figure 7-9. Annotated sequence diagram for a retail sale (creating an order).

[View full size image]

Deep Dive—Database Testing—Move On Up As mentioned earlier, sequence diagrams are probably the most versatile and useful diagrams in the UML. Not only do they serve their intended function of showing a time-ordered sequence of collaboration between the elements of the system, and not only can they help provide details for test procedures, but they can also help to test the database. How? A database transaction is “an action or series of actions, carried out by a single user or application program, which accesses or changes the contents of the database.” [CONN1] Look back at Figure 7-8. In it, a user (Salesperson) creates, changes, and accesses various business entities (i.e., Order, Product, Customer). Sequence diagrams can be diagrams of your database transactions. Realize that these are high-level (business-level) diagrams. Order, Product, and Customer are domain entities that are key to your business operation. In the actual implementation of the database, more tables likely will be involved in such a transaction. During database implementation, the database design typically is significantly modified from its logical or conceptual design. However, these sequence diagrams depict what needs to be done from a business point of view. You can use them to determine if these business transaction scenarios can actually work after the detailed database implementation is complete. You should consider whether your implemented database can support these intended business functions. Sequence diagrams provide a basis for your database validation. Just as test people should be involved early in the lifecycle, database analysts should also be moved up to the early stages of development to help in the definition of such sequences.