A feature can pass a developer’s checks and still miss what users need. Acceptance tests check a feature’s behavior against agreed, business-facing expectations. Unlike unit tests, which focus on individual components, they let users or sponsors judge whether the feature works as intended. section 2.1 section 1.1
Start with a conversation among business stakeholders, developers, and testers. Work through concrete examples and counterexamples before treating a requirement as settled. Record the important examples as acceptance criteria in language the business can read; the same examples can guide implementation and become automated tests. section 1.1 section 1.5
Making a train requirement testable
A request to show the next train sounds clear until the team asks which line, direction, and departures count. A refined scenario says that trains to Chatswood leave at 8:02, 8:15, and 8:21; when a traveler asks at 8:00, the expected result lists 8:02 and 8:15. Those details turn an assumption into a checkable outcome. section 3.4
To turn an agreed example into an automated acceptance test:
- Formulate a scenario with Given for context, When for an action, and Then for the expected outcome. section 3.4
- Write code that exercises the application and verifies the outcome. A scenario with unfinished automation remains pending; the underlying code makes it an automated acceptance test. section 8.0
- Run the tests during development and in the build. Passing criteria provide evidence of implemented behavior and readable, worked examples of how the feature operates. section 3.1 section 3.6
Choose the testing route to suit the behavior. Browser tests can illustrate a user journey, but they can be slow or fail for browser and environment reasons; API interactions offer another route for suitable requirements. Design test code for clarity, reliability, and maintenance rather than accumulating fragile scripts. A failure should prompt attention, not become routine noise. section 13.0 section 9.0 section 9.1
Passing acceptance tests can reduce repetitive regression checking and help testers focus on exploratory work; they do not automatically prove that a release is ready or that the feature delivers its promised business value. That last question needs validation in use. For an existing application, high-level tests can also document current behavior and reduce regression risk as changes are made. section 3.6 section 3.1 section 16.6
