I was fortunate to attend Gojko Adzic’s Specification By Example training. Although I was familiar with the topic and the content of his book Specification By Example, I learn a lot. In this post, I will share insights around:
- How to build software right the first time.
- How to facilitate a specification workshop
- The secrets of great test automation
By the way you may have heard of Specification By Example through it’s other pseudonyms: Acceptance Test Driven Development, Story Testing, Feature Testing.
How to Build it Right the First Time (Zero Defects)
As illustrated in the diagram below, Gojko argues that the key problem in software development is a lack of shared understanding about what needs to be built. Language is imprecise and different assumptions lead to errors.
A powerful way to justify spending time developing specifications is that it takes much less time to specify the behaviour of something than to build it. If something takes a long time to specify, this is a clue that it will also likely take a long time to implement it. The secret is to ask good questions and keep the examples rather than trying to create a written specification. It turns out these simple, small steps save a lot of time.
When everyone – domain experts, developers and testers – all have the same shared understanding, software will be built right the first time. This is the most essential property of Specification by Example – having a shared understanding.
Whether or not you create automated tests is somewhat of a secondary concern. It’s a good idea for sustainable development, but not required to deliver correct software.
And best of all is that everything here will work with a waterfall team as well as an Agile one.
How to Facilitate a Specification Workshop
A big part of the training (which I recommend) was participating in a simulated specification workshop so that we could see how they work and learn how to facilitate such them.
The most important thing is to call it a “Specification Workshop” and not talk about tests or test cases or automation so that it is easy for busy business people to attend.
The diagram below illustrates the key points:
- Cycle between large group and smaller groups
- Look for differences in language, models as well as where there was lot’s of discussion and conflict
- Seek to converge on a shared model using a ubiquitous language
- Conflict is a sign that there is a business decision to be made.
Secrets of Good Test Automation
The final bits of wisdom came from reviewing real examples of test automation to determine how valuable they were.
Great specifications:
- Have a concise description
- Have a clear model
- Use business language
- Show a clear connection between inputs and outputs.
This is true whether or not we automate them. Automated specs need to be readable for business folks.
See diagram:
The other key point is that the automation layer needs to be kept very simple – just wiring of the specification to the system under test (SUT).
How to Evaluate the Quality of Your Specification/Examples
There is a really simple test to see if you specification/examples are any good. But it’s scary.
Here is what you do:
- Hand the specification to someone and have them read it.
- Don’t say anything.
- Don’t say anything. (This is the most important step, so I am repeating it).
- Write down questions they ask – these are clues of how the spec can be improved.
- Looks for the “ah-ha” moment when they understand. If you don’t see this, then there’s something missing.
Acknowledgements
I am deeply grateful to Gojko Adzic for delivering such an interesting and engaging training. He is a master storyteller and has an immense collection of real-world examples. If you get the chance, I highly recommend this training.
I would also like to thank the Toronto Agile Community for brining Gojko Adzic here as part of Agile Tour Toronto.
Thanks also to my classmates who made our time together challenging and fun. And especially to Paul Carvalho for reminding me what testing expertise really looks like.
