intechnica

Specification by example has a history that is closely linked to Ruby. The main software tools and development methods came from work on Ruby projects. As the method has started to attract a wider audience development tools and links to Microsoft .Net platforms have begun to appear.

At Intechnica our approach has been from two directions. An important aspect of the methodology is the use of continuous integration and code build, and that unit tests and inter-module testing is built into the software framework. This will prove that the code providing the functionality for the stories is working properly. So the development teams are looking to build continuous integration and unit tests into their software development processes. At the same time we don’t want to be tied to a specific and expensive development platform. Current processes are predicated on using Team Foundation Server – if the testing components are added to this it becomes an expensive solution.

The area that the solution assurance team are working in is the setting out the scope of the project and ensuring that the requirements reflect customer business requirements. Most importantly, it is then taking that living documentation and collaborating with the development team, PM’s and the customer to refine the details and identify the key business flows. Initially the outline ideas are put together using whiteboard sessions. These are then recorded into a mind-map software solution. There are many different products out there – many of which are open source. An important part of the selection criteria is that they are collaborative and that they have flexible import and export capabilities. It is no good having meetings and having working groups and then finding that they can only print output and can’t have shared input. The solution we have chosen is Mindmeister. Like many tools used for business analysis, testing and development, Mindmeister is a Software as a Service (SaaS) solution. This provides great flexibility and reduces the need to have software installed onto closed PCs or to use licensing dongles and allows easier upgrades. The software is free to use with limited number of mindmaps in the basic version; the personal version with greater number of maps and export formats is £4.99 a month, and the pro version is £9.99.

Once the project has a satisfactory outline and the scope has been captured with a rough outline of the solution we then use the Speclog solution to start to write the user stories. Speclog is a tool that is designed to look at business requirements and allow them to be described fully. For the story based process of specification by example this allows us to breakdown an application into its constituent actor goals, business goals and user stories. Each core feature is broken out into different user stories. Again it has strong collaboration characteristics. We have chosen a server version that allows a number of people to work on the same project. Linking back to specification by example, the output produced is in Gherkin language.

As part of this process, this is the time when the requirements traceability and the summary of requirements documentation is written. This is so there is an agreed understanding of the scope of the project. The tools are put in place for later test phases that will validate the delivery of the business capability.

This takes us back to our initial introduction to specification by example where we worked on user stories and used a Ruby tool called Cucumber that allowed the project to be detailed. Cucumber also produced and validated Gherkin code. It is a descriptive language that allows requirements to be described in the Given When Then format.

Given that I am a user of the system
I want to enter a valid order
So that products can be dispatched

In this example a number of characteristic scenarios would be used when describing the order entry feature. An order should have a valid product, reject certain types of product, have correct dispatch details, have a correct order scheme, contain shipping details, reject incorrect quantity amount and produce an order summary. From this the Gherkin user stories would then be produced and the developer would start to work on the features that provide this software capability.

And this brings us to our last software tool. In order that user stories can be discussed with the users and reviewed internally during development and testing, we need a tool that can bring together the Gherkin output in a Wiki style web site. This is key to the specification by example method where the output needs to be the living documentation and reflect the improvements and changes that are made to the requirements and how they are met through the project. Most importantly, both the SpecLog description (connected to the development cycle) and the tool used to monitor the progress of the requirements and display their maturing needed to be closely aligned. In theory this can be done by putting the Gherkin files into a version control system where the software that provides the capability will be developed, but because we don’t have the right connectivity and the development processes are not yet in place, we have put in a simpler solution. The user stories are being published into a file share and then put out into a Wiki style display tool called Relish. This can be used in two ways, directly by writing Gherkin feature files using simple editors such as Notepad++ or Sublime – plugins to these two products allow them to validate Gherkin code.

The linking together of the solution assurance and development processes are the next area for examination. When developing features there won’t necessarily be a direct one-to-one relationship between developed code modules and the stories. Some modules could be used across a number of stories – but in different functional capabilities. There will also be a much larger number of software modules and the relationship between the stories and the underlying code needs to be monitored. This area will require a lot of detailing work.

The final step will be to put the agreed user stories into our test management software tool (we use Practitest) as requirements and the write the core end-to-end process flows as test scenarios – with the test cases described within reflecting the different functional capabilities.

Conclusion

There are a lot of good quality software tools to help work with Specification by Example. Collaboration and flexibility are key – as is basic reliability. A time can be seen when there is a end-to-end link up to take requirements and produce testable artefacts. The next step in the process will be to work out how the development tools will hook into this process and more importantly, if we can follow the process fully, is it possible to produce a hybrid approach that combines traditional methods with this much leaner approach? The biggest challenge with this process is that it works from a top-down perspective – where traditional software methods use a combination of top-down and bottom-up to ensure that no gaps are inadvertently produced. It is addressing this issue that will be the most pressing challenge for specification by example.

See the other posts in this series by visiting David’s profile page.