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!