Moving from Stories to Code
Over the years I’ve worked with numerous projects/teams which follow the agile path. The usual problem occurs with a degree of projects; the team is newly formed, and there are a lot of differing views on what “agile” really means in a day to day project activity. Ignoring the general agile coaching that occurs on these types of projects, there still appears to be one area that is in my view, painfully manual: transitioning from stories acceptance criteria/tests to coded (integration) tests.
A story often starts out from being written by the product owner (PO), business Analysis (BA) or User Experience (UX) team. Acceptance criteria/tests are added as appropriate to provide a “box” for the story, so everyone is clear on the scope and testing of the story further down the road. Ideally the list of acceptance criteria/tests increases as appropriate so everyone is clear when the story can be moved into the “done” state.
The issue comes when transitioning from the story card form to a code base with unit and integration tests. The acceptance criteria/tests effectively map to integration tests. In the ideal world the story card acceptance criteria/tests would be written in a DSL and effectively allow auto generation of .feature or similar code files, thus avoiding the dual keying of data.
This leads to a few thoughts around an story acceptance criteria/test DSL/fluent readable language:
Net out, one thought is to push a DSL up to the story card level, and thus educate the PO, BA, UX and QA to write acceptance tests in a more “appropriate” format to reduce down stream “time”