Quality Assurance

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