Saturday, 3 November 2012

From a deck of Business requirements to Automation testing

Lately I have been heavily involved with preparing BDDs with BIAs and then entering them to Fitnesse as Scenarios with testers. For both teams, these concepts are new.
BIAs, in some cases, are taking BDDs as "Forget what you have learned so far on how to do your work and start doing them in BDD format". In some other cases, they see them as "too technical" when combined with scenarios (test cases). Then, in some other cases, they are saying that all they have to do is "small enhancements" so writing BDDs is not necessary. I had the chance to run a session with them and explain this. I started with the Story Map and explained that as "10K feet view". Then, we zoom in to "1K feet view" and look at MMF (Minimum Marketable Feature). Then we zoom again to "100 feet view" which is one of the stories and finally, zoom really close to a Feature. How do we explain what this feature is? We write requirements! How do we write requirements? In a way that everyone in the team (BIA, Developer, Tester and Client) understand. What would that be? As simple as possible, make it a picture, a drawing, a sentence,  whatever helps you explain but keep it simple and meaningful. Suggested: BDD.
Why BDD? Well, one benefit is that it can become executable, testable. There are different apps for that. One easy to grip on is Fitnesse. Others are more advanced but even more complicated to setup. Since we have a lot of Web testing to do, Selenium was a must. So found a way to connect Fitnesse and Selenium and have one entry point, Fitnesse.
Now we had to prove that a BDD can be executable. So we created some Fitnesse pages for different test cases and tried to "sell" it to BIAs. That didn't go very well. It felt like they had to write scripts, program, develop. It also felt very technical in the sense that they had to put together numbers and create cases of what to enter and what to expect, something that usually is done by testers.
We learned that our BIAs are not ready to write anything that is not pure English (wiki language that Fitnesse uses does not fall in pure English). We learned that our testers at the beginning were scared that Fitnesse will replace them, but after, they didn't like it that they had to write test cases and then change them when ideas were changed.
One thing we won, is a place where we can send testers and BIAs to see how requirements look like when they are done well, with testing in mind and when people work together. All I can hope is that now that they know how the end looks like, they can start a new project in the right way, they can do the right thing at the beginning.


  1. The idea behind BDD is quite different. That is very good described by Gojko Adzic in his "Specification by Example" book. The main goal of this process is to have a conversation between 3 parties: business, developers and testers. Acceptance Test is the one of the possible outcomes of the discussion. Those tests can be written in format team prefer: Gherkin syntax, Wiki Tables, Keywords, Fitness, Plain English etc

    Idea is to have test-first mindset change for the whole development team. They should think how that feature should work for end user, how that user is going to use the system. The implementation starts from test in ATDD cycle. Write acceptance test -> run it -> fail? -> switch to application code -> write unit test -> run it -> fail -> implement feature that make test pass -> run test again -> passed? -> refactor -> run acceptance test -> passed? -> refactor -> run again -> move next ....

    Sorry for such complex response. There are a lot of articles where that described simpler :)

  2. Andrii, I agree with your suggestion on "Specification by example" I was trying to cover that on this sentence "As simple as possible, make it a picture, a drawing, a sentence, whatever helps you explain but keep it simple and meaningful."
    In this particular case, we used BDD as the Given-When-Then syntax that is was easy for Fitnesse+Selenium setup we tested.