Posing Sharp Questions in Use Case Failure Analysis and Test Design
"The main role of models is not so much to explain and to predict…as to polarize thinking and to pose sharp questions."
Marc Kac, Some Mathematical Models in Science
As the popularity of use cases grows, so grows the need for systematic means of doing failure analysis and test design from use cases. This is particularly true for productsor components of productsthat are safety-critical, mission-critical, business-critical, or in general require high assurance. And virtually all products, whether safety-critical or not, have at least a few use cases the project team would like to make sure are rock-solid reliable!
In Chapter 5, "Use Case Preconditions, Postconditions, and Invariants: What They Didn't Tell You, But You Need to Know!" we will look at a time tested technique for specifying the expected behavior of abstract data types and objectsmodel-based specificationand apply it in a fresh way to pose sharp questions in use case failure analysis: the analysis of potential ways a system, specified by a use case, might fail. In doing so, the reader will learn some things about preconditions and postconditions they forgot to mention in "Use Case 101!" This approachthinking about failures while writing use casesis a powerful, risk-driven strategy, focusing testing on detection of high impact defects first and providing the requirements needed to design systems that fail in a safe way. The chapter concludes with ideas on how to work smart in applying model-based specification, including the "The Absolute Least You Need to Know: One Fundamental Lesson and Three Simple Rules" section, which, if you get nothing else from the chapter, will give you a take away that you can apply to any and all use cases right away.
In Chapter 6, "Triple Threat Test Design for Use Cases," you will learn that not only does model-based specification with its preconditions, postconditions, and invariants provide an integrated basis for use case failure analysis, it also provides just what is needed for test design by using Robert Binder's Extended Use Case Test Design Pattern. And because the test cases are designed from the results of our failure analysis, they will target defects that represent high impact failures.
Finally, a brief comment is appropriate about one of the main examples used in both chapters: A tank used to store chemicals needed for a manufacturing process. The storage tank has a pipe through which the chemical flows to fill the tank and a pipe out of which the chemical flows to manufacturing. This example is a variation of the classic "bathtub" problem that is used in teaching systems thinking or system dynamics (Weinberg and Weinberg 1998). [1] The problem, though easy to state and initially understand, turns out to have many nuances that tend to elude intuition, requiring some systematic methodsuch as modelingwhich leads us to pose the sharp questions that need to be asked in use case failure analysis.
[1] A similar example is used by Storey (1996) as part of the discussion on fault-tolerant architectures.
