Acceptance criteria are the key to making sure our stories are done, and have as few bugs as possible. When the criteria are weak, not complete, unclear or misunderstood, this can be the root of a whole host of problems. Acceptance criteria are a critical point on which a team can focus to improve their results and delivery.

Acceptance criteria can be implemented as automated acceptance tests. The PO, the Developers, and the QA people on the team should all be in agreement that the acceptance tests do illustrate that the software works as desired.

I wrote another article with more thoughts on acceptance criteria, in a recent post on the TestDrivenDeveloper.com blog site, please check it out!

Acceptance criteria can be a tricky bit, especially if the customer and the team don't have much experience at generating and capturing them. I would definitely consider it a process smell if I saw a continuing pattern of low quality acceptance criteria. Really this can kill a project if left untended to fester on its own.

From what I have seen on several teams, we should all focus more time and effort on acceptance criteria gathering and then automating it in the sprint as part of the criteria for Done.

If you have mechanisms or practices that enhance or enable better collection or identification of acceptance criteria, please post a comment below.

"Obviously, Development should be responsible for the acceptance tests. The developers are the ones on the team who are the best at writing good code. The developers are best able to turn the acceptance criteria into valid executable specifications. Development then can use the automated acceptance tests to drive the development TDD cycle."

"In QA, we never totally trust the developers. We do trust them to do the right thing. However, we have a saying in QA - Trust but Verify. QA should be responsible for the acceptance tests. At the end of the day, it is our job to make sure that the software meets the criteria for acceptance, so it's really a QA ballpark. Dev's should focus on unit tests."

Two strong opinions, and really I think both are right. Development should be using acceptance tests to drive an ATDD cycle. Developers are (usually) better at writing code than SDETs, so they do a more efficient job on acceptance tests. But QA probably has a more even overall view of the software, and from a different and more independent perspective, so they should be writing the acceptance tests as well as the other test automation. QA also has the responsibility of signing off on the code, so they should be writing the acceptance tests.

So, this may be one way to resolve the issue. Have developers and testers both work on automated acceptance tests for the first story. When the tests are completed, developers are free to begin working on the unit tests and code to satisfy the acceptance tests. QA can then begin test case generation and automation implementation.

I believe that this solution is the best of both worlds, because Development and QA will be completely in sync and on the same page for all of the stories where the acceptance tests are co-developed. There won't be any ambiguity on whether the software meets criteria, and both teams will be in agreement as to what is passing and what isn't. The tests will be well-written, and they will run as efficiently and accurately as possible. They will be written with multiple perspectives - the customer (who supplied the acceptance criteria), QA who makes sure that the test accurately guarantees the outcome, and Development, who makes automation quicker to implement and more efficient.

With automated acceptance tests co-written by dev and test, we have a great common point of communication, and a good example of how teamwork can really help software shine and inspire confidence and trust in the eye of the customer.