Definition of Done (DoD) and Acceptance Criteria
The Definition of Done (DoD) and Acceptance Criteria are the two most powerful quality tools in an Agile team's toolkit. They transform 'quality' from an abstract aspiration into concrete, measurable standards. QA engineers who own and evolve these tools move from reactive testers to proactive quality architects.
Definition of Done - The Team's Quality Contract
The Definition of Done is a shared list of conditions that EVERY user story must meet before being considered complete - regardless of what individual developers think 'done' means. A strong DoD includes: Code written and peer-reviewed, Unit tests written and passing (>80% coverage on new code), Integration tests passing, QA functional testing complete with no open Critical or High defects, Accessibility checked (WCAG AA for UI features), Performance verified (meets response time SLA), Security review completed for authentication/data handling features, Documentation updated (API docs, user docs if applicable), Product Owner has accepted the story. The DoD is enforced - a story that doesn't meet DoD is NOT done, regardless of deadline pressure. When the team feels pressure to lower DoD standards, QA engineers document the decision and the risk accepted. Over time, a consistently enforced DoD reduces defect injection dramatically as developers internalize the quality standards.
Gate: all tests must pass. Coverage minimum 80%.
Writing Testable Acceptance Criteria
- Given/When/Then format (BDD-style): 'GIVEN a registered user on the login page, WHEN they enter a valid email and correct password and click Login, THEN they should be redirected to /dashboard within 2 seconds, the header should display their first name, and an audit log entry should be created'
- Characteristics of good acceptance criteria: Specific (measurable, not vague), Complete (covers happy path AND key error paths), Unambiguous (two people reading independently reach the same interpretation), Testable (QA can write a test case directly from it), and Realistic (achievable in the sprint)
- Common acceptance criteria failure: 'The feature should work correctly' - this is not an acceptance criterion, it's a hope. Any criterion that can't be directly converted into a test case step with a measurable expected result needs to be rewritten
- QA's role in criteria review: Before sprint planning ends, QA reviews every acceptance criterion for each story in the sprint. Any criterion that can't be directly tested gets flagged before coding starts - not discovered at the end of the sprint
Tip
Tip
Practice Definition of Done DoD and Acceptance Criteria in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Definition of Done DoD and Acceptance Criteria from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Definition of Done DoD and Acceptance Criteria is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- The Definition of Done (DoD) and Acceptance Criteria are the two most powerful quality tools in an Agile team's toolkit.
- Given/When/Then format (BDD-style): 'GIVEN a registered user on the login page, WHEN they enter a valid email and correct password and click Login, THEN they should be redirected to /dashboard within 2 seconds, the header should display their first name, and an audit log entry should be created'
- Characteristics of good acceptance criteria: Specific (measurable, not vague), Complete (covers happy path AND key error paths), Unambiguous (two people reading independently reach the same interpretation), Testable (QA can write a test case directly from it), and Realistic (achievable in the sprint)
- Common acceptance criteria failure: 'The feature should work correctly' - this is not an acceptance criterion, it's a hope. Any criterion that can't be directly converted into a test case step with a measurable expected result needs to be rewritten