For the past two months or so, my test team has been experimenting with SpecFlow for test automation development. SpecFlow is a tool used for Behavior Driven Development, or BDD, that describing acceptance tests in a syntax that is in plain English. This plain English “Given/When/Then syntax, called Gherkin, allows one to write tests that make it blatantly obvious what is being tested. It makes it very easy to map a user story to its associated acceptance tests. In this post, I’ll talk about some of the explicit and implicit advantages of using SpecFlow. In a future post, some of the challenges and complexity of choosing SpecFlow will be exposed.
One of the teams have started to incorporate SpecFlow and are integrating it into the planning process. The team has started to include the testers in the pre-grooming meetings to get a sense of what stories are being planned. From this, testers can start writing SpecFlow tests to map to the stories.
Involving the test team and SpecFlow early in the planning process has a number of advantages. First, having test involved in the planning stages could help give a different perspective. Are there key stories missing? What happens in the scenario is changed by doing X? Why do we need this story if we can already do this with the Y feature? A lot of these are questions that already may come up, but the extra diversity may get the team thinking about things earlier. Next having test involved early potentially compresses the development time. Test can get a better understanding of the behavior, stub out tests, and then implement automation in parallel with development thus reducing the amount of time between dev code complete and story acceptance. Quality may increase since test will have better understand early and has more context around what expected behavior should look like (and also have more time to ask clarifying questions). Once SpecFlow gets mixed into the process, now the entire team can get good visibility into what the acceptance tests actually look like and give feedback to help increase the coverage in a language that everyone understands. That last bit is the important part – damn near anyone can understand what a particular test case is actually doing without having to bring up MSDN or decipher curly braces.
Once these SpecFlow tests are created, the tester then has to write the actual automation code and wire up their code to the SpecFlow test (technical details are available at the SpecFlow site). Without getting into too many details, SpecFlow utilized code generation to produce C# code for test execution. If the tester hasn’t completed the automation code or wired it up to the SpecFlow acceptance test, then execution of the SpecFlow test will yield a result of “Inconclusive”. This can give the team a quick and easy status of what tests have been written (result will be Pass or Fail) and what tests are still outstanding (“Inconclusive”). Having written the SpecFlow “test first” gives the team guidance for what they need to do to move a story to acceptance, and give the project manager feedback on the progress and quality of the stories.
Involving test early and practicing scenario based testing gets us closer to the Whole Team Approach of development. It’s not just dev writing code then throwing it over the wall for test to bang on. Rather it’s the whole team producing a high quality feature.