Posts

The acceptance tests are written by the business, and run by the builders. The business defines what success looks like, but it’s not their job to verify that the system delivers it; that responsibility belongs to the people who built it. Builders run acceptance tests, fix failures, and ensure the application delivers what has been asked for; before a story is considered done. Running those tests continuously is the only reliable way the team knows the story is complete. ...

I’ve seen teams rewarded for finding as many defects as possible. Better that the teams finds them, rather than end-user, right? Over time the culture and metrics rate a higher defect count as proof of the QA is doing well. Defects become a currency that some team members benefit from. The builders learn that if a high defect count isn’t a problem, then they can meet their delivery deadlines simply by announcing the work as complete before the expected due date (while quietly knowing that it’s imperfect) ...

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. ...