A journey map makes an existing system’s purpose visible before anyone commits to a test design. Start by asking stakeholders whom the system serves and what those people need to accomplish. Recording actors and goals gives the team a shared, blameless place to notice conflicting assumptions. section 14.1.1
Build the map outward from a high-priority goal:
- Separate the goal into workflows. A traveler can find a flight without booking it, and can enter booking without using the flight finder. Those are useful boundaries for reusable test code. section 14.1.2
- Ask what must happen before the first workflow. A prerequisite such as sign-up or sign-in can reveal test-data and runtime dependencies. section 14.1.2 section 14.1.5
- Associate workflows with the features that enable them. One feature may support several workflows, while one goal may require several features. section 14.1.3
- Choose a small set of critical scenarios rather than mapping every workflow upfront. Revisit the map after completing an automation cycle. section 14.1.3
Work backward from a sign-up outcome
For a successful sign-up scenario, first record the verifiable consequence: the traveler’s account exists and the traveler can proceed to sign-in. If the activities needed to reach that outcome are still unknown, mark them to be confirmed rather than guessing. Map unsuccessful scenarios separately so their different consequences are visible. Business rules can then expose workflow complexity and suggest how to divide automation work. section 14.1.5 section 14.1.5
Figure 14.10 Visualizing business rules helps us gauge the complexity of a workflow and spot opportunities to split automation work by business rule.
The business-rule view shows how adding rules to a workflow can reveal complexity and possible divisions of automation work. section 14.1.5
