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”


~ by mdavey on December 4, 2012.

2 Responses to “Moving from Stories to Code”

  1. In addition to the above Frameworks you could consider a tool / framework such as SpecFlow (.NET) for taking acceptance / behaviour tests written in plain English (Gherkin) and executing them. I have used this in several project teams now including one team where the BAs literally wrote / defined the tests.

  2. If, as I understood, you use Java or any JVM based language for development then I would suggest you the use of Cucumber-JVM which is Gherkin based and allows to easily describe you acceptance tests in an executable feature file which will then be mapped to your JVM code.
    On top of that, if you use the Eclipse IDE, I would like to suggest a wonderful plugin called Natural that you can find among my GitHub repositories 🙂

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

%d bloggers like this: