A test automation system is supporting software built to verify and document another system’s behavior. It includes more than test scenarios: execution frameworks, libraries, and glue code also shape whether tests remain reliable and understandable. Treating tests as isolated scripts can leave business meaning buried in low-level interactions and produce slow, flaky, hard-to-maintain code. section 14.2
A layered architecture separates stakeholder-facing behavior from the technology used to exercise it. The specification layer captures important workflows, business rules, and examples in language stakeholders can read. The domain layer models the actors’ activities and gives them business meaning. The integration layer turns those activities into interactions with interfaces and tools, such as an HTTP client or browser driver. section 14.2.1 section 14.4
Booking a flight
A traveler wants to book a valid flight, not interact with a web page for its own sake. An automation solution can express that goal as a workflow, model the traveler’s activities, then use the web UI or an API to perform them and check the response. The interface is a means of testing the booking rules, not the subject of the acceptance test. section 15.1
Keeping business activities separate from low-level integrations makes test code easier to reuse across suites and contexts. Candidate workflows can be identified through journey mapping, then automated one business rule at a time rather than in large batches. section 15.0 section 14.4
