Book Review: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

The main takeaway for me is that everyone becomes more in sync with each other when requirements and specs are written as examples. They can be verified more easily (to the point of being able to automate the verification), and it is easier to spot inconsistency and edge cases.

This level of collaboration helps teams build quality in from early stages, rather than trying to control quality later.

• Business analysts help the team understand the product domain.
• Developers help spot inconsistencies in business rules.
• Testers help spot ways to break or cheat the system.

The book goes on to describe how to write good examples, when to describe business rules using a table and when to use Given-When-Then workflows.

Second takeaway is executable specifications and living documents are tools for communication and collaboration first, and for test automation second. Therefore, to use it effectively these specs must be written collaboratively by the team, and owned by business analyst or product owner.

If developers or testers attempt to do acceptance testing on their own without involvement from business analyst or product owner, they are better off just writing developer-centric tests. (The book even calls out acceptance tests written by developers/testers as worse than nothing.)

This book is written in 2009, so it provides good historical context about the “specification by example” movement and how it relates to agile methodology. However it is written before more modern tools like Cucumber and Gauge existed. For a more recent comparison of more modern tools, check out this 2017 article: Jean-Pierre Lambert, “Comparing Executable Specification tools”