BDD + UADD

This is a cool way of satisfying most of the stakeholders in the development process as well as automating, to a large extent, the scenarios and the acceptance criteria of the tester, without burdening the software development process with too many artifacts or overheads.

In fact, you can accomplish both BDD (Business ("B" for Business or Behavior? I will be exploring this in the upcoming Agile NCR 2010) Driven Development) as well as UADD (User Acceptance Driven Development) with the help of Slim without burdening the underlying development model.

The Scenario tables do not do anything by themselves but when combined with Script or Decision tables they help in maintaining a level of automation in the SDLC that help the business analyst understand that his requirements are visibly satisfied. This can be understood as a BDD approach with the acceptance criteria being defined by the "business" in the Scenario table itself. Of course, there is a maturity level and sense of responsibility to be assumed by the "business" in this approach.

The same acceptance criteria can be defined in Decision tables, which will come at a functional/acceptance test phase that can be identified as a UADD approach. In this form, the tester writes the acceptance criteria after the "Dev completed" swimlane is achieved.

More tools like "Trinidad" (for Java developers) ensures that the developer, too, is able to understand how the acceptance tests are working by running the fitnesse tests right from within JUnit!

Of course, ultimately the goal is the same - to deliver working software at the end of a timebox; the only difference is in how you want to drive the software development process. It is just the packaging that is different!

Decision & Scenario Tables in Slim

There are two exciting features in Slim - the Decision Table and the Scenario Table. Below are the screen shots of both:

A Scenario table, as in the above image, does not by itself do anything and that is why the Scenario does not show green but, when combined with the Decision table, you get the desired test behavior as in the below image.

Every scenario described in the scenario table gets executed when a Decision table contains the exact name of the Scenario. Here, it is a Script table that helps Slim knows that it has to execute the Scenario script and not the fixture code.

More about the script and the code in a later post.