- Introduction
- Involve Testing and Quality Assurance Before Thinking About Design
- Identifying the Ways in Which a Use Case Can Fail
- Documenting the Extension Handling Steps
- Creating the Acceptance Test Cases
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Identifying the Ways in Which a Use Case Can Fail
Every step in the main success scenario is a "subfunction goal" for an actor or the application. Every single subfunction goal can fail in one way or another. If the failure is unrecoverable, the use case still must deliver on the minimum guarantees, and it must not deliver on the success guarantees. On the other hand, if the failure is recoverable, the overall use case must still deliver on all of the guarantees.
Recording how the application recovers from these failures is the job of the extension handling steps, but don't get ahead of yourself. Before wondering how to recover from any of the failures, you first need to get the help of the users and testers in identifying all of the possible things that could go wrong. For every failure condition identified, you need to confirm that it's something the application can detect, and that the users think it's important that the failure is handled. Everything that passes these two checks should be recorded in the extensions section of the use case, immediately below the main success scenario.
Extensions:
1a Computer crashes while entering event details.
1b Duplicate event.
2a No members selected.
3a Club Secretary selects Cancel.
3b Timeout on waiting for user response.
3c Club Secretary chooses new subset of membership.
4a Mail server does not respond.
4b Mail messages rejected by mail server.
5a Member not found.
* A user closes the application.
The extensions are labeled with the step number and a letter to distinguish multiple failure conditions on the same step.
Sometimes a failure can occur on any step. In that case, you can either denote the step number with an asterisk (*) or report the range of steps over which it could occur (1–5 in this example).
Even though the list of extensions is incomplete (invalid email addresses, mailbox full, and so on), you should now be getting a sense of the complexity that can hide within a use case. As a developer, you have to design the application to detect and handle each one of these failure conditions. You also have to make sure that if extra failure conditions are identified later, these new extensions can be incorporated into the application relatively painlessly.
Although you now have enough information to start thinking about the design of the application to support this particular use case, defer making any design decisions until you have the final piece of the use case puzzle—the extension handling steps.