Succeeding with Use Cases: Working Smart to Deliver Quality

The overall lesson of this chapter is that model-based specification, in addition to being a good tool for use case failure analysis, is a good tool for test design: any work done modeling the use case for failure analysis is easily translated into test cases. Here's a review of the two major sections of this chapter.

In the first section, you learned why preconditions, postconditions, and invariants, taken as a unit, are a veritable triple threat test case for black-box testing:

• Preconditions are an ideal source for test point selection both in terms of valid and failure scenario test cases.

• Postconditions provide the all important primary expected result.

• Invariants provide a crosscheck on the expected result of the postcondition or can act as a "better late than never" precondition if a precondition is not available. Plus, global invariants have the added benefit of being both a precondition on steroids and a mini test case that can be executed anytime, anywhere in the use case.

The second section reviewed Binder's Extended Use Case Test Design Pattern, a method of specifying test cases from a use case by modeling the use case as a relation described via a decision table, called an operational relation. You also learned that model-based specification can be used as a relational description of a use case and is easily translated into the decision table format of an operational relation. This approacha model-based specification-style operational relationcoupled with an expanded table format, has a number of benefits:

• The workflow nature of a use case is preserved, which is handy for testing.

• The overall combination of a test case described in natural language augmented with a model stated in terms of preconditions, postconditions, and invariants provides a test case that is both understandable and rigorous.

• Use of unprimed and primed state variables allows you to talk about the before and after versions of state variables when describing preconditions, postconditions, and invariants.

• Preconditions, postconditions, and invariants are grouped in such a way to make evident their "team" structure and the use case operation or step they are describing.