Overview
The Contract Between Product and Engineering
Without clear acceptance criteria, 'finished' is just an opinion. These criteria act as the binary switch that tells the team when a feature is truly complete.
For a QA Engineer, Acceptance Criteria (AC) are the bible. They form the basis of your test cases. If a bug is found but the behavior matches the AC, it is not a bug—it's a change request. Good ACs remove ambiguity and prevent scope creep.
Best Practices
Dos and Don'ts
Avoid common mistakes that can lead to flaky tests and maintenance nightmares.
What to do
- •Use the 'Given-When-Then' format if possible.
- •Make criteria pass/fail (binary), not subjective.
- •Include negative scenarios (what happens when things go wrong).
Common Pitfalls
- •Don't write criteria that describe *how* to implement the code.
- •Don't use vague words like 'fast', 'easy', or 'better'.
- •Don't change criteria mid-sprint without team consensus.
The Details
From Criteria to Automated Tests
In Behavior Driven Development (BDD), Acceptance Criteria are directly translated into executable test specifications using tools like Cucumber or SpecFlow. This ensures that the documentation implies the test, and the test implies the documentation, creating a 'Living Documentation' system.