A traveler looking for a flight may only want to compare prices, not book. Treat finding a flight and making a booking as separate workflows: each is a sequence of activities that serves a goal, and the booking can begin without the flight finder—for example, from a newsletter link. Clear boundaries make test code easier to reuse. section 14.1.2
Map a workflow from the actor’s goal toward a verifiable result:
- Identify the critical workflows first, then ask what must happen before the actor can begin. Prerequisite workflows reveal test-data and runtime dependencies. section 14.1.2
- Associate each workflow with the system features that enable it. A goal may cross several features, while one feature may support several workflows; avoid mapping every possibility upfront. section 14.1.3
- Work backward from the outcome: decide what observable consequences would show success or failure before filling in the actor’s exact activities. section 14.1.5
Sign-up before sign-in
An account being created is a verifiable consequence of a successful sign-up workflow. Sign-in can follow, but its dependency on sign-up matters when planning an automated test. If the exact sign-up tasks are still unknown, mark them for confirmation rather than pretending the sequence is settled. section 14.1.5
Figure 14.9 Visualize both happy and unhappy path scenarios to highlight their different consequences.
Compare successful and unsuccessful paths by their different consequences; those differences guide what each scenario must verify. section 14.1.5
In test automation, keep the business process visible in the domain vocabulary instead of burying it in lower-level integration details. That separation supports reusable, portable test code. section 15.0
