Fitnesse Friday
You know the drill. Your software needs better automated test coverage. Your testers need an easy way to create that coverage. You need a lever over your verification rate, but closing the gap is always out of reach of the individual team member.
Until Fitnesse Friday. Four developers closing the gap in one concerted effort. In a room together... all day friday.
Consider the classic problem Fitnesse excels at - a significant amount of complex business logic that lends itself to tabulated scenarios: Given a set of system state and inputs, a set of responses should be returned. In our case it's a scheduling service offering appointments. The operating hours, existing appointments, rules, scheduling and appointment scoring strategies, and asset configuration all combine to determine what appointments are offered when a user requests an appointment.
Verifying the correct behavior requires a large amount of test cases, and each test case (when done manually) is expensive with its non-trivial and at times obscure set-up. With Fitnesse, we leverage the fact that system state can be automatically set from the values in a test scenario wiki. And of course any scenario can be run automatically, over and over again.
Fitnesse Friday makes the whole of the effort greater than the sum of its parts - collaborating and sharing the work creates the synergy needed to close the gap. A few things that made it successful:
Incorporate Your Testers.
If you are lucky, they're collocated with developers and this is natural. If not - make sure to understand how they perceive the volume of work they are expected to test, and where Fitnesse fits in managing that workload. They are the customer, even if Fitnesse is largely going to be used by developers.
Prep a Backlog
Prep a backlog. Developers and testers met before the friday to prepare a backlog of features they wanted supported in the test scenarios. This ensured we were doing the most important things in the testers eyes and had a set of tasks for friday. And it lives beyond the friday - have some time to implement the next most useful thing? see the backlog.
Prep a Skeleton
Coming in cold on Friday would have required significant time just to get the basics plumbing stood-up, and that wasn't the backlog. One developer with previous Fitnesse experience spent a few hours wiring up the most basic scenario, then leading the developers in a quick intro. We also prepared a standalone Fitnesse environment on a spare PC to ensure we could provide an always-available Fitnesse installation.
Team Room
Get your team all in one room - non-negotiable.
Make it Fun
Franklin equipment makes sports bands with an F on them! Surely each team member needs one. We kept it light with team cheers and the Franklin Fitnesse Friday sweat band of solidarity. See the gallery below... Sports water and protein snacks kept the fitness theme going.
Our Fitnesse lessons learned...
Test Data Layout
We ended up deciding that each scenario should have its own page, rather than tabulate all scenarios in one long complex table. We use Fitnesse's 'SetUp' pages for repeated set-up tasks, and also the page inclusion to reference reusable system state elements.
Ex. !include -c SetupStandardOperatingHours
A given page will have several tables of set-up, a tabulation of inputs, and a tabulation of expected results. We build the system state up in a singleton as each table is processed by Fitnesse/Slim. The expected results fixture uses the built-up state.
Use Domain Terms/Natural Language
We started with a somewhat obscure approach for indicating system state elements based on pre-existing unit tests. We converted that to simple tables with the domain terms our testers expect. In some cases it was valuable to write a simple interpreter - for example - to understand the days of the week names as inputs 'monday', 'tuesday'. This makes the test definition easy to read and understand.
Prove value - then Assess Priority
We have a lot of open questions - how will we automate the update of the Fitnesse environment with the latest code? How to version/save/share test scenarios? First - do the simplest thing to provide value. We expect a payback in a single release, and lessons that will guide our next steps to improve this tool use.
