I’m keen on Specification by Example particularly with a tool like Cucumber to automate tests. However this style of specification is also useful without the automation. I introduced my current team to Specification by Example and, with some help from me, the customer is now using the same disciplines to define requirements to hand to a 3rd party development shop. The experiment has been very successful.
In the past the customer gave fairly convention specifications to their vendors. “The system shall do this and must do that”. This works for a small piece of work supported by a lot of conversation. Less conversation, less success.
Introducing Specification by Example
I had already demonstrated how Specification by Example had helped my team get clarity about what is being built, and provides “living documentation”. So I suggested to my customer that they try the same approach with a new vendor, accepting that there would be no automation because this was a change to a legacy system.
I thought Specification by Example would work in this context because the concrete examples are very powerful. The format is precise, complete, and realistic. Particularly as I encourage people to specify the business rules by example.
The customer liked the idea. I run a short workshop on Specification by Example for the people leading this initiative on the customer’s side. Gave them a few examples and provided feedback on scenarios they produced.
It might help to give a real example. A traditional spec might have said “The system shall sum all spot values” and left it at that (the context is radio advertising). But that wouldn’t have conveyed enough information. The key problem being solved was that the system was ignoring negative values. So I suggested a scenario to make that clear and ground it in an example.
Scenario: Prepayment monthly total sums all spot values whether positive or negative Given a 1 month campaign has these spots values: | Spot Value | | 100 | | -90 | | 200 | | -180 | When the prepayment report is run Then the total value for this month is 30
Obviously you could automate this scenario. And if we’d started from a green field we would have, but it didn’t justify the cost to wrap a test harness around this legacy code.
After the workshop I left them to it as the project played out.
The feedback from both the customer and the vendor was very positive. The vendor in particular appreciated the clarity these specifications bring to their work. Both parties were keen to continue using Specification by Example.
Caveat: This was an small scale experiment: it was for a small change to a legacy system. It might not work in other situations but then again traditional approaches haven’t been very successful either.
This post is part of a series on Specification by Example.
I agree that Specification By Example is really useful even without the test automation – I previously started using this at my organization and found that the scenarios were well understood by:
1. The business
2. The developers (coders)
3. The QA Team (who were writing/executing manual tests not automated tests).
There is definitely a big benefit for using the same single source which all of these stakeholders can understand and are working off.
Couldn’t agree more.