Acceptance Tests

Quality Assurance must stop being a back‑end gatekeeper. QA belongs at the front, providing early input to prevent errors and omissions, not just measuring and reporting them later. The team injects QA activities into planning, define acceptance criteria, and automating test execution as the features are being built. When QA focus and practices are incorporated from the start, the team can reduce rework, be met with fewer negative surprises, and deliver value at a consistent pace. ...

Each user story should have at least one acceptance test. The tests are drafted by the business (with support from the BAs and QA) they describe the behavior they expect to see in the application when the story is complete. When it’s practical the builders aim to automate the execution of these tests. As the builders and the business’ understanding of the requirements converge and they come to an agreement on what’s to be delivered by the story, they start to build and automate the acceptance tests to prove that it’s the ask has been fulfilled. ...

A specification can be described as a test. For example: when a user enters a valid username and password and clicks “login,” the system shows the “Welcome” page. That sentence is a requirement and can also act as a test. Acceptance tests should be automated whenever practical. The business team owns the requirements; and the builders make them runnable. The confusion comes when only one side works on the tests. In practice the team needs to write them together. ...

Different teams have different ideas about how much details need to be specified in the requirements. Some teams keep them as vague wishes and others specify pixel-perfect prescriptions. It’s useful for the product team to describe the desired behavior with some clear examples. Builders then translate those examples into automatable scenarios written in domain language. And the team then iterates until the tests clearly capture the business intent (rather than technical details). ...