Should a tester/developers become a combined entity? Or is this simply representative on the increasing demands on a tester? Stepping back from this boringly over-debated point, there are reasons that the question arises in the first place …From QA Management persepctive, there is weaknesses in the path from user story down to code, and the transparency. Slight deviations can lead to major requirements gaps, and ATDD (or the identical BDD – Bahvaiour Driven Design), is one approach that addressed this on paper – but regards good tools available, they are still very light on the ground.
BDD tools are generally too-developer focussed (as with Cucumber and Specflow). The key bit-in-the-middle is where requirements meet code. The advantages of such products as Specflow is they generate DSL (or pseudo code) from user stories and scenarios, which gives the developers a kick start in the coding. But largely these tools remain used by only developers, though are funtionally effectively at testing requirements, as long as the requirements are amaintained within the tool. This leads to problem just once the first flurry of work is done at requirements and planning level, the process fails to continue. Many a specflow feature file languishes out of date, as the process is not administered or followed through.
Fitnesse is the closest to fit aim of transaprency across the projects – at any time, anyone can go onto Fitnesse site and run (acceptance) tests against the current codebase. The ONLY weakness to Fitnesse is it’s lack of any tools/plugins to effectively do what Cucumber/Specflow do out-of-the-box. Not business-friendly though – for example, to run specflow feature files (i.e. the user stories/scenarios), the user has to actually go into Visual Studio source control to run the test – not ideal. Fitnesse doesnt require anyone from business or testing to go into source control – everything can be administered from Fitnesse.
Of course this is not the complete story of testing – what we have here is regression testing utilising low level units tests, not UI tests. Selenium is a common pairing with Fitnesse, as selenium scripts can easily be called from within Fitnesse to create the UI-driven tests. The added advantage is that Selenium addresses another weakness in Fitnesse in that it is not naturally given to front-end driven tests, whereas Selenium is. Or of course manual testing, which is still a very necessary task given we are dealing with human beings. Though this is a very effective setup, the bit-in-the-middle is still missing. Generating DSL from user stories/scenarios is essential in BDD/ATDD approaches.
Example of Scenario in Fitnesse
!|Scenario |dvrCanSimultaneouslyRecord|number|andWithThese|seasonPasses|shouldHaveTheFollowing|toDoList|
|givenDvrCanRecord |@number |
|whenICreateSeasonPasses |@seasonPasses |
|thenTheToDoListShouldContain|@toDoList |
|Script|Some Random Script|
|Dvr Can Simultaneously Record And With These Should Have The Following|
|number |seasonPasses |toDoList |
|1 |D5_1:5,D6_1:6 |D5_1:E:1-7 |
The middle table mentions a script literally called “Some Random Script”.
The final table names the scenario and therefore requires some class handle the scenario. Since the most recently mentioned script table was “Some Random Script”, Slim will look for a class called SomeRandomScript. Furthermore, the scenario has three lines, and therefore three required methods that the class SomeRandomScript must have:
givenDvrCanRecord
whenICreateSeasonPasses
thenTheToDoListShouldContain
And it is these methods that a developer (or developer-friendly tester) would have to hand-code. The ideal would be that the scenario could be used to automatically generate the DSL, which could then be passed to a developer to complete. This is point where Selenium will help. Assuming development is in C#, we use a C# port of the fitnesse slim server and Selenium C# Client Driver to control pages of our application. This means you could write the next story without any coding except Fitnesse.
This is the part where testing can effectively meet development – the reason that there is an increasing demand for the “developer/tester”, a reaction to the lack of cohesion between them. To solve the problem you don’t make a developer a tester, or vice versa, you deal with the process.
In the next part, I will cover how Selenium can give add value to Fitnesse, and give it the DSL features. I have got a good kickstart from this great article – http://blog.crisp.se/2011/03/24/magnusaxelqvist/1300952760000
Tutorial on Fitnesse/BDD
Useful Links
http://www.slideshare.net/wakaleo/acceptance-test-driven-development2
http://schuchert.wikispaces.com/FitNesse.Tutorials
http://fitnesse.org/FrontPage.VideoTutorials
http://amalkov.blogspot.com/2010/03/fitnesseslimselenium-tandem.html
http://watirmelon.com/2011/02/18/c-sharp-atdd-on-a-shoestring/
Related posts:
