Where do you store your Given-When-Then statements?

Given When Then was created as a template to improve communication between developers (using TDD) and subject matter experts (Business People, Product Owners, Business Analysts and Testers etc.). It supported the example driven development approach (Break the Model) that Sanela Hodzic and I refined at BP in 2003.

As an agile coach, I have come to appreciate the word “better”, and have disdain for the word “best”. “Best” results in teams who stop their journey of continuous improvement when they achieve “Best” practice. “Better” helps teams continually reach further and further. “Better” allows teams to celebrate improvement, even if they have not reach “best” practice. “Best” is a stick to beat those who are on a learning journey, who have yet to arrive.

A common pattern with Given-When-Then statements is that business analysts/product owners write them as acceptance criteria for stories, often in Jira. A test developer then uses these to create feature files for cucumber, specflow etc. This is “better” than the business analyst writing abstract requirements, or writing their requirements in prose.

There are potential drawbacks with this approach:

1. The test developer may interpret the Given-When-Then statements in order to get them to work with cucumber/specFlow. The automated tests may be subtly different to that intended by the business analyst as there is often nothing in the process to ensure that they are reviewed.
2. The business analyst/product owner versions of the Given-When-Then is not managed under source control.
3. Subsequent changes to the Given-When-Then by the BA/PO are independent of the feature files used by the development team. The changes may be disconnected from the behaviour specified in the feature files.
4. The test developer may prepare the feature files and cucumber integration in parallel to the development of the functionality. This brings the tests and functionality together in a big batch of testing at the end of the two parallel processes.

I am fortunate to be working with an extremely smart and competent business analyst called Ilona whose flexible and collaborative attitude has resulted in a new process.

• For each epic, the Cotswold Way is followed. First the value to the customer is understood. The outputs are designed that will deliver the value. Eventually the behaviour is described.
• Ilona writes the features files and manages them in a version control system (Git). The feature files are created on a branch for the epic.
• Then Ilona holds a three amigoes session with the development team to establish the stories needed to automate the tests and implement the code. The stories link to the feature files.
• If subsequent changes are needed to the feature file, Ilona edits it on a branch. When the automated tests are run on the branch, they fail (red) until a developer fixes them (green) at which point the branch can be merged back into master.

Is this a “better” process? Is it already documented somewhere else (I think it might)?

The approach would appear to address a number of the issues with the process I originally described. The major drawback is finding business analysts/product owners who are prepared to learn to use git and write Given-When-Then in a style constrained by the way cucumber works.

What “better” ways do you know? Please provide links or descriptions in the comments.