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.

3 Responses to “Definition of Done – Acceptance Tests”

  1. […] Definition of Done – Acceptance Tests (Matt Davey) […]

  2. […] a counterpoint post Matt Davey added Acceptance Testing to the list, bringing up Acceptance Tests as part off the […]

  3. I believe ATDD is another name of BDD for as long as “behaviour” implies driving code via concrete acceptance tests.
    I full agree on the subject of agreeing both terminology (Ubiquitous Language from DDD) and acceptance tests acting as developer friendly mini requirements.
    I was told about Bruce Tuckman idea of project team:
    Forming, then Storming then Performing. This process can be applied both at the beginning of a project itself or from a phase (sprint/iteration or not) and has to be adequately sufficient.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

<span>%d</span> bloggers like this: