Real-world data prove that Agile, BDD & co. work - lecture by G. Adzic
I've attended a very inspirational lecture by Gojko Adzic, organized by the Oslo XP Meetup. Many people including some respectable persons claim that Lean, Agile, and high-level testing based on specifications (whether you call it Agile acceptance testing, Acceptance-test driven development, Example-driven development, Story-testing, Behavior-driven development, or otherwise - let's call them all Specification by example) do not work.
To prove the contrary, Gojko has collected over 50 case studies of projects that were very successful thanks to using these methods. In his soon-to-be-published book, Specification by Example (download ch1, a review), he investigates what these projects and teams had in common, which was missing in the failed ones. So it's great for two reasons: It documents how great success you can achieve with Specification by Example and it shows you how to implement it successfully.
In the case you've never heard about Specification by Example before, the idea is (as I understand it with my limited knowledge) that the business users can express their requirements in such a way that it can be directly used for verifying that the system satisfies them. A popular tool in this area is FitNesse, where tests are created as wiki pages with tables containing inputs and expected outputs.
According to Gojko, you can achieve great software quality - sometimes up to the point that you can abandon your issue tracking software - thanks to Specification by Example. However you must implement it properly. Some of the key points that he mentioned were (beware: most of the text is what I understand under what he said, it doesn't necessarily mean what he actually meant :-) ):
Already for a long time I'm attracted by the concept of specification by example, but I was never sure whether it can really work. Thanks to Gojko and his book I know it can work and I also have guidance for avoiding the pitfalls and attaining a success. I'm therefore very much thankful to him and looking forward to reading his book.
PS: To be fair, I should mention that also the other lecture of the evening, "Lead better - Essential Skills for Software Team Leadership" by Roy Osherove was excellent and has brought me new insights into the role of a team leader. I've never before thought that team leader should so much care for the personal/professional development of his team members and that helping them grow is his main responsibility (provided that the team isn't anymore in chaos, having enough problems striving to survive). He shares his ideas about leadership in software teams via 5Whys.com, which I'd recommend.
To prove the contrary, Gojko has collected over 50 case studies of projects that were very successful thanks to using these methods. In his soon-to-be-published book, Specification by Example (download ch1, a review), he investigates what these projects and teams had in common, which was missing in the failed ones. So it's great for two reasons: It documents how great success you can achieve with Specification by Example and it shows you how to implement it successfully.
In the case you've never heard about Specification by Example before, the idea is (as I understand it with my limited knowledge) that the business users can express their requirements in such a way that it can be directly used for verifying that the system satisfies them. A popular tool in this area is FitNesse, where tests are created as wiki pages with tables containing inputs and expected outputs.
According to Gojko, you can achieve great software quality - sometimes up to the point that you can abandon your issue tracking software - thanks to Specification by Example. However you must implement it properly. Some of the key points that he mentioned were (beware: most of the text is what I understand under what he said, it doesn't necessarily mean what he actually meant :-) ):
- Don't start with user stories but understand the business goal - the desired effect - first because user stories may already imply a solution. This is, I'd say, rather known but perhaps too often forgotten wisdom.
- Specify collaboratively - it's essential that business users, developers, and testers work together (ideally face to face) on creating the specification for thus a common understanding can arise (we all know that most projects fail due to wrong or misunderstood requirements) and each of them can contribute to increase the quality of the specifications thanks to his unique point of view.
- Specification with examples - the user acceptance testing tools such as FitNesse are not intended for integration and full regression testing, it's nonsense to create tables with hundreds of rows. The "test" should first contain the specification itself in few sentences and then a table with few key examples so that anybody reading it - now or in one year - can easily understand the point. Such testable specification is maintainable and can serve its primary purpose of being means of communication between all involved parties and between their current and future selves)
- Best specifications/tests are aligned with the business domain, using the same language, concepts, relationships, models as the business people. Thus they can understand them and use them as the primary source of documentation and, more importantly, - if you've really managed to preserve the models and relationships - a small change in requirements will require only a small change in the software and the tests and vice versa so the business people can directly estimate the impact of changes. One of the key enablers is that tests are not expressed in the terms of clics, CSS classes, and XPaths, because then it could easily happen that a small change to a webpage header would break hundreds of tests. (And many teams certainly fall into this trap.)
- Living documentation - such tests become very valuable and easily accessible documentation of what the system does. Of course you must keep it alive, meaning that it must be updated as the system evolves, and the system itself must evolve as the business needs change (including removal of business functionality which is not anymore needed - something often neglected). Because the specifications are so close to the system, it's actually very easy to keep them synchronized, something that is a huge problem with standard documentation.
Already for a long time I'm attracted by the concept of specification by example, but I was never sure whether it can really work. Thanks to Gojko and his book I know it can work and I also have guidance for avoiding the pitfalls and attaining a success. I'm therefore very much thankful to him and looking forward to reading his book.
PS: To be fair, I should mention that also the other lecture of the evening, "Lead better - Essential Skills for Software Team Leadership" by Roy Osherove was excellent and has brought me new insights into the role of a team leader. I've never before thought that team leader should so much care for the personal/professional development of his team members and that helping them grow is his main responsibility (provided that the team isn't anymore in chaos, having enough problems striving to survive). He shares his ideas about leadership in software teams via 5Whys.com, which I'd recommend.