Last week me and my colleague Jorge went to Agilia conference in Brno, Czech Republic. The conference was on average good, but what we really enjoyed was the Specification by Example workshop we attended after the conference.
It was a 2-days course given by the great Gojko Adzic. He went through it with explanations of what Specification by Example is, how we should apply it at work and which are the benefits of it. We alternated that with several team exercises and many coffee breaks :) We also learnt how to write good and bad specs. At the end of it he told us about the real software quality and even gave us an introduction to Impact mapping!
So what's Specification by example?
Specification by example is a technique which brings together the requirements gathering and QA testing processes in the software development cycle. It is also knows as ATDD or even BDD, but I don't really agree with the last terminology..
Basically it is a way of writing specifications collaboratively which are then converted to automated acceptance tests.
How does it work?
Testers, developers and business people will get together in one room and will write specifications for the new features that they want to implement. In order to do that they will get separated into different teams, get a white board each and write examples of how the system should be working after the new features have been implemented. Once all the teams are done they will get together and compare the examples, look for differences and agree in some common ones.
After the team workshop is over, testers will take those examples and automate them with a tool like cucumber or fitness. Developers will implement the features and will know they are finished when these tests pass. These tests will run against the actual system frequently. If tests got automated before the development work starts this is know as Acceptance Test Driven Development, the same as TDD but from a 'higher' point of view :)
It is not really necessary to do the whole team workshop, but it is the most effective way. However, sometimes it won't be easy to get all those people at the same room and just bringing together one tester, one developer and somebody from business will do it - the three amigos way. At other occasions the team will be distributed, one person writing the spec and the another one or two reviewing it may work.
Which are the benefits?
The two main benefits brought by specification by example are having a single source of truth and getting a quicker feedback.
The examples are requirements and also tests. What is written in the requirements is automated as tests and run against the actual system. If a requirement changes the test will change and the system will have to, if we add a new requirement there will be a new test and the system will have to change to make it pass. Basically, what is specified in the requirements it is what the system does! No more requirements document and qa test that differ. The examples are the single source and we know they say the truth because they are automated and run against the system frequently. This is known as the Living documentation.
The good thing of bringing together business people, developers and testers is that we will spot things much earlier in the process. Instead of waiting to solve misunderstandings once the development work has been finished we can bring forward this feedback to the point were requirements are gathered. Handing over documents from Business Analyst to developers and then to testers is not the good way to do it, many times things will get lost and won't be spotted till the testing phase or sometimes even production! Put everybody together before the development work starts and many communication issues will get solved in no time, rather than waiting till the end of the iteration.
Another key benefit of the workshops is that they will bring a better understanding of the actual system to everybody and will help modelling it. When writing the specs collaboratively everybody will get to a common language which then can be used when developing the system, documenting it or at any further discussions later on so there are no terminology misunderstandings - this is known as the Ubiquitous Language.
how to write good automated tests: specs should explain only what is tested, not how. automation should explain how. pic.twitter.com/GkVikNu2qb— Gojko Adzic (@gojkoadzic) 28 March 2014
I kind of knew about specification by example before the course and we were already doing in it a certain way at work with the three amigos way, but not properly. I hadn't heard about the team workshop and I find it quite interesting to be honest. I would like to try it. I just need to convince business people :)
As a feedback about the course I would say it was awesome! It was presented in a quite entertaining way. Challenging and fun team exercises in between engaging talks from Gojko with real life cases from his work as consultant. At the end we got a about 10-page document that summarizes everything. I am planning to get the book and learn more about it.
Maybe the one about Impact mapping too.. sounds quite interesting!