Specification by example

I attended a course on ”Specification by Example“ by Gojko Adzic, and he challenged everyone attending to write a summary of what we learned. Feel free to comment or give feedback if you have attended his course and have other perspectives of this, or if you see that I have misunderstood something. For those of you who are not familiar with Gojko’s work, I strongly recommend it. Check his site http://gojko.net.

Summary of Specification by example course

As I understand it, Specification by example is the process of creating requirement specifications using key examples from the business point of view to validate that the software is working as the business intended. The specifications are used as automatically run tests against the system and thus hold the Single version of truth. After deployment of the system these tests will also serve as Living Documentation of the system. As a developer I like to think of this as following TDD from the business point of view. (You might know it under other names as well.)

Setting up functional tests with tools like FitNess is not new to me. But a key point I got from the course is how to specify these tests in order to describe what the system should do and not how the system will do it. The latter is sadly the most usual mistake according to Gojko, and I realize I am one of those who have thoroughly misunderstood this. To see if you have captured what in your examples/tests you can use these criteria: 

1. You are using keywords from the examples to summarize them
2. You can’t summarize the examples in more simple terms.

Many of the guidelines for making good unit tests also apply to good specifications with examples, i.e. Keep them simple, Self explanatory, Easy to read for intended audience (business people in this case). An important lesson from the course is to push complexity into the gluecode layer. In other words, everything you need to setup and start test, such as inserting data into database should be handled by gluecode. If I understand this correctly this means that the speed of the tests are important, but not as important as keeping your tests clean and simple!

Achieving Living documentation is not something most organizations do in a flash. Gojko presents some process patterns one can implement to gradually get to Living documentation. These patterns are

·         identifying Desired business effect

·         Deriving scope from the business goals when the team is ready to implement more functionality. 

·         Identify Scope using User stories or Use Case

·         Collaborate to find Key examples

·         Refine into Specification with examples

·         Automate to get Executable specification

·         Validate frequently and evolve into Living Documentation