Some notes and links on Agile Acceptance Testing.
First the links.
Read the online Acceptance Testing chapter from “Test Driven - Practical TDD and Acceptance TDD for Java Developers” by Lasse Koskela. (note 20200315 - no longer available on line)
Read Brian Marick’s article Series Agile Testing Directions he refers to ‘acceptance tests’ as ‘checked examples’.
And now the notes:
To me, the phrase a ‘checked example’ implies that acceptance tests represent a set of agreed ‘good enough’, ‘broad enough’, base set of tests that we can reuse. We need to do further investigation to determine our confidence in their ‘checkedness’ and ‘comprehensiveness’. So we supplement these checked examples with additional user/exploratory testing/functional automation/unit tests etc. I think that Scott Ambler alludes to this in this Dr Dobbs article.
Acceptance Tests represent examples from the customer so we want the customer to understand the test and so we have to write the test in a way that supports us communicating them to the customer. Preferably documented in a way that the customer can read and understand the test without help, and in their most idealised form - written using a tool that the customer can amend/create the tests.
But ignore any fancy abstraction approaches until you get a set of tests that the customer can understand. This allows the customer to agree that the tests implement their basic coverage acceptance examples. Over time you can amend the tests to write them in a more customer friendly way, as you learn more about the domain and the customer’s preferred representation style.
Then comes the fun part. In addition to examples, identify any risks. Identify things that you think you might have concerns about but don’t yet see the value in formalising into an automated acceptance test. Think through the ‘other’ questions that you have about the stories because they can help you build your starting charters for your exploration of the implementation.
