Myth: Acceptance Tests should be prepared early in the story life-cycle
Acceptance tests are best defined as late as possible. An acceptance test that is not running green, that is not plugged into functioning code, is dead documentation: it describes something ethereal; something that may never be. In lean terms, it is inventory. It has time to get out of date and become unclear to the writer. The value is only realised when it runs against functioning code, and in XP/Agile/Lean we like to realise value soon after the work is done.
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)
1 Comments:
I worked on a project where we got a lot of value by writing the acceptance test for a story before starting to code it. The tests were described in English, and run manually by an independent testing team. Developer, tester and domain-expert customer wrote the acceptance test together. Having the test as a deliverable motivated the conversations and discussions that powered the story, and prompted timely discovery of the important decisions and edge cases. Tests were updated as the story progressed and actual code led to further discoveries, of course.
(We were *supposed* to gradually automate the manual tests in a wonderful framework. This didn't happen much, so the tests usually remained in English and were expensive to run. But writing the tests in this form was not expensive, and we realized value straight away,)
Post a Comment
<< Home