Definition of Done – Acceptance Tests

InfoQ has an interesting article on QA in Scrum.  The article offers a very simple Definition of Done (DoD) list, which is a good start – especially as in many organisations “Done” is often unfortunately accepted as a word, with no real evidence.  I’d offer that what is missing from this list one of the constructs of a good story – acceptance tests.  Additionally, I’d say that “acceptance test cases” need to be correlated back to acceptance tests on the story, else you could have somewhat of a delta between that the engineering team is using to test the story, and get to Done, and what QA is using to test the story – one source of truth.  Mike Cohn sums up acceptance testing quite clearly for all involved in “testing” stories that need to be deemed “Done”:

“Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer team expected it to work.”

Further, from Implementing Agile:

1. Acceptance tests are used by the product owner to know that the acceptance criteria have been met and the User Story is “Done” to their satisfaction.
2. Acceptance tests help drive development in an “Acceptance Test Driven Development” environment.
3. Acceptance tests serve as the source of product regression tests.

This nicely leads to ATDD.  I’m still shocked at how badly the software engineering industry is still behind in “old” concepts like TDD and BDD.  I can only imagine the number of people running for the door on the mention of ATDD 😉  The Microsoft MSDN blog offers an interesting read on ATDD.

Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. It’s the best way I know to ensure that we all have the same shared understanding of what it is we’re actually building. It’s also the best way I know to ensure we have a shared definition of Done

So in summary, this morning when your having your Scrum daily stand-up (assuming its not a team meeting fictitious Scrum faily stand-up – call it what it is!) review your teams DoD, and serious consider moving into the 21st century with regards to software engineering agile practices!

~ by mdavey on December 11, 2013.