- 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
Involve Testing and Quality Assurance Before Thinking About Design
Although you might want to start thinking about how to design the application as soon as you have a hint of a requirement, it's better to curb this initial enthusiasm for design and instead think about how to test the resulting application. Thinking about quality assurance first is a natural extension of the ideas of test-driven development (see Part 2 of this series) and results in fewer surprises later on.
By thinking early about how to test the application, you can get a good handle on all of the weird and wonderful things that can go wrong at each step of the use case. Ideally you should involve your quality assurance and testing people in eliciting requirements, because they'll be great at suggesting "what if" scenarios for users to think about. Testers are a great addition to the requirements elicitation activities because they're detail-oriented and want to know what's supposed to happen in really specific circumstances like these:
What happens if the network connection to the email server fails after we send an email but before we get back the confirmation? Should the application consider that email as sent, or not?
If sending is interrupted in any way, what is the application supposed to do? Automatically retry later, try a different email server, let the user resend the notification, or what?