Normally ATDD and BDD are associated with special tools that allow non-developers like business people and testers write or at least read tests, without having to write code. Examples of such tools are FitNesse, M-Spec, SpecFlow, Cucumber and more.
However, even though these tools allow to specify tests scripts without code, often for business analysts these tools are too technical, or they just don’t have the mindset to specify tests in a well-structured “Given-When-Then” format.
About two years ago, the core group in Retalix tried to adopt ATDD using FitNesse, where the BA’s (Business Analysts) had to write the tests instead of writing specs, before handing them to the developers. Except for one team where the BA had very strong technical skills, all the rest abandoned the methodology and some even became eager objectors to it.
These days we start to re-adopt ATDD in Retalix, but in a different format: we’re separating the task of defining the scenarios (AKA examples or tests) from the task of writing them in a structured tool that can execute them. In addition, we’ve decided that it won’t be the responsibility of the BA to define all the relevant scenarios, but rather it will be a collaborative work of the BA, QA and developer. This collaboration helps nail down potential issues and misunderstandings early on. It also joins the strengths of all of the participants to yield more relevant scenarios, and a more polished specification. Usually, the BA brings the deeper business knowledge, the QA brings a more critic view, looking for edge cases, and the developer brings the more structured view that looks for similarities with other cases.
The Specification Workshop
This collaborative task of defining the scenarios that represent the desired feature to cover the user story is done in a special meeting, called a “Specification Workshop”*. In this meeting, which takes place once for each user story (or once per iteration for all user stories), the participants define the scenarios in collaboration and write them down as a free text Word document or email.
Developing the test in MS-Test
After the workshop, the developer starts implementing the tests in MS-Test using Visual Studio. Even though he writes the test in C# code, he must write it in the most readable way that reflects the scenario as close to the Word document as possible, hiding any implementation details in private methods. It’s the QA’s responsibility to make a code review to enforce this (even if the tester doesn’t know c#!). Only then is when the developer starts implementing the production code to make the test pass. Also, even though MS-Test (or NUnit to that matter) are mainly aimed at unit tests, these tests should be implemented at a higher scope, like integration tests.
* The term is “Specification Workshop” is taken from Gojko Adzic’s book “Bridging the Communication Gap”. ISBN: 978-0-9556836-1-9