The book

Bridging the Communication Gap

Specification by Example and Agile Acceptance Testing

By Gojko Adzic

Buy the paperback | Buy the PDF |
Buy on Kindle Store | Buy on ITunes | Register your copy | Sample chapters | Reviews | Table of contents

Bridging the Communication Gap (ISBN-10: 0955683610, ISBN-13: 978-0955683619, published in January 2009 by Neuri Limited) is a book about improving communication between customers, business analysts, developers and testers on software projects, especially by using specification by example and agile acceptance testing. These two key emerging software development practices can significantly improve the chances of success of a software project. They ensure that all project participants speak the same language, and build a shared and consistent understanding of the domain. This leads to better specifications, flushes out incorrect assumptions and ensures that functional gaps are discovered before the development starts. With these practices in place you can build software that is genuinely fit for purpose.

This book is primarily intended for product owners, business analysts, software developers and testers who want to learn about agile acceptance testing and implement it. It should also prove to be interesting to project managers working on software projects, both within the implementation team and on the customer side. It is intended both for people already working with agile processes and for people who wish to migrate to them.

Read this book to:

  • learn how to improve communication between business people and software implementation teams
  • find out how to build a shared and consistent understanding of the domain in your team
  • learn how to apply agile acceptance testing to produce software genuinely fit for purpose
  • discover how agile acceptance testing affects your work whether you are a programmer, business analyst or a tester
  • learn how to build in quality into software projects from the start, rather than control it later


This book is a must read for anyone involved in creating a product; management, testers and developers. Use it to change the way you think projects should be run and close those communication gaps. — Toby Henderson

I wish that the book had been available a few years ago when the company I was at (and myself) were trying out agile. Could have been a lot easier and more successful if we’d read it. — Philip Kirkham

If you’ve tried agile acceptance testing you’ll know that as well as being a really exciting it’s also incredibly difficult. Luckily we now have a book that helps guide us through the many tricky choices that we face, practical and pragmatic advice that even the most experienced agile developer should be aware of. — Colin Jack, Senior Software Developer, FNZ

Effective software development is all about good communication and this book explains the toolkit that allows us to do this effectively. Worth reading whatever your role is. — Mark Needham,

Whether you’re new to testing, new to agile, or an old pro at one or both, you’ll experience “aha” moments that will inspire your team as you read. This book will challenge some of your preconceived notions and make you think. It paves the way for people in different roles, such as business analysts, QA engineers and developers, to adapt to a more productive agile approach. From practical ways to improve communication with customers, to helpful examples of useful test tools, this book is a major addition to our agile testing knowledge base. — Lisa Crispin, co-author, Agile Testing: A Practical Guide for Testers and Agile Teams

Have you ever wanted a better way to communicate, clarify and satisfy business requirements? Wouldn’t it be great if those requirements evolved along with the software, always consistent and clear? And those requirements helped drive development so that we knew when we were done? With clarity, Gojko describes an elegance and effective way of achieving this with the whole team: Inventing, thinking and communicating with specific, insightful examples that also serve as acceptance tests. — Rick Mugridge,, and lead author of “Fit for Developing Software”, Prentice Hall, 2005.

Gojko addresses an underrated point: that Test-Driven Requirements, or Executable Requirements, are not about tools, automated tests, or even professionalism. They are about communication. I wish each of my colleagues and clients had a copy of his book, and maybe that fact will be made just a little bit clearer to them. — Eric Lefevre-Ardant, Agile Coach and Developer,

As a tester, I welcome any opportunity to increase shared understanding of requirements and expectations – our team will be relying on this book to guide us as we begin our journey with agile acceptance testing. — Marisa Seal

This book will help you to avoid some mistakes in agile acceptance testing. It will also increase your confidence in implementing new process, help to change tester’s view and identify next steps. The most important part, this book is written by a real practitioner with some real-life examples. Believe me, you would be at least 6 months ahead of the game in Agile QA by just reading Gojko’s book. — Gennady Kaganer, QA Manager at Standard and Poor’s

Gojko applies his experience to the practice of producing software that is useful to end users. This is an important work in extending the test-driven specification of software beyond individual units and into the sum of the parts. — Bob Clancy,

Bridging the Communication Gap will not only bring you up-to-date with the latest thinking about agile acceptance testing, but also guide you as you put the ideas into practice. This book is packed with insights from Adzic’s experience in the field. — David Peterson, creator of the Concordion acceptance-testing framework

I’m convinced that the practice of agile acceptance testing, done properly, can make a dramatic improvement to both the communication with the customer and the quality of the final product. This book is a solid introduction to the subject, and represents the first attempt I’ve seen to survey the practice as a whole without focusing on a single tool or technology. — Geoff Bache

Gojko’s book is a worthwhile read for both managers and practitioners. It is both complete in its content and inspirational in its message. David Vydra,

Gojko’s new book deserves a place in every agile team, not just on the bookshelf but within grabbing distance of every team member. This book will show you that agile quality and agile business success is mostly about finding commonalities — between specification and verification, and the language and understanding of customer, developer and tester. Drawing on his deep experience, he covers the dual issues of human interactions and tool support in equal measure, ensuring the team does not lose sight of the forest for the trees. This book is rich in practical advice, every chapter providing valuable insights and guidance to keep your agile project delivering real value. —David Evans, Agile Coach, Software Quality Systems.

Gojko articulated the problems faced in IT industry due to communication in an excellent manner. This book makes you to realise how things are practically different and difficult than teaching theory, which is the truth everyone is going through in the industry. Gojko has found and explained innovative ways of bridging the communication gap in various different ways… — QA review

“Bridging the Communication Gap” is certain to be a ‘must read’ for all those working on agile teams trying to improve the way the technical and non-technical roles interact… — review.

I’ve been dealing with requirements for almost 11 years now from a testing perspective and the approaches and concepts presented in Bridging the Communication Gap are the best I have seen with trying to rein in this beast. I’ve recommended it to two people I’ve taught so far and if you find you are having issues determining or delivering what the customer really wanted, I recommend it to you too. — Adam Goucher.

A must have read for my team as we adopt agile practices in software development. It also has helped me re-skin the role of a tester for a my team — Simon Reekie, Trader Media Group

It is certainly a ‘must read’ for all those working on agile teams trying to deliver what the customer really wanted. — Pascal Mestdach

This book is a much-needed checkpoint in the on-going adventure to discover (and re-discover) how to write software effectively.[…] I will be using with book with clients and recommending it to them for future reference. A boon to the community. — Keith Braithwaite

Adzic’s Bridging the Communication Gap does a brilliant job of focusing on communication within the realm of software testing. […] Bravo to Adzic for writing on a topic that hasn’t been addressed in the way it should. — Clever Tester Web site review

“Bridging the communication gap” by Gojko Adzic is a much needed book on a very important topic that finally is deserving the attention it needs. This will certainly be a book that I will be recommending to other people (and in fact, I already have). Great work Gojko! — Bas Vodde

As a tester, this book has been quite useful to me. It explains where the roles of other people, besides developers, fit in the agile process. I believe this is an important book and is a must-read for anyone contemplating or performing in agile development. — Mark Cole for

Sample chapters

Table of contents

Acknowledgements ix
About the author xi
Introduction xiii
Why should you care? xiv
Who is this book for? xv
What will you get out of this book xvi
What’s inside? xvii
Giving credit where credit is due xix
How this book is organised xx
I. The Communication Gap 1
1. The next bottleneck in software projects 3
The telephone game 5
Imperative requirements are very easy to misunderstand 8
Are obvious things really obvious? 9
A small misunderstanding can cost a lot of money 14
Fulfilling specifications does not guarantee success 15
Requirements are often already a solution 19
Cognitive diversity is very important 20
Breaking The Spirit of Kansas 21
2. Finding ways to communicate better 25
Challenging requirements 25
We really communicate with examples 26
Working together, we find better solutions 28
Communicating intent 29
Agile acceptance testing in a nutshell 31
So what does testing have to do with this? 34
Better names 38
II. Building and Maintaining a Shared Understanding 41
3. Specifying with examples 43
How do you brush your teeth? 43
A practical example 45
Realistic examples make us think harder 48
Identifying important examples 50
Dealing with processing workflows 54
Working with business workflows 57
4. Specification workshops 59
Running a workshop 60
Workshop output 63
Sharing domain knowledge 64
What specification workshops are not 68
How to keep the workshop focused 70
Dealing with open issues 72
5. Choosing acceptance criteria 75
Acceptance tests are the specification 75
Choosing the right set of examples 76
Distilling the specifications 78
Specifying business workflows 80
Converting examples to tests 82
Automating tests 86
Dealing with user interfaces 91
Who should write acceptance tests? 95
What acceptance tests are not 97
6. Focusing development 103
Building software to satisfy acceptance tests 103
Suggesting new features 105
Designing software based on acceptance tests 106
Developing the glue between code and tests 110
Use the project language consistently 111
Unit tests vs acceptance tests 113
Running acceptance tests 115
Running tests that are not fully automated 117
7. Facilitating change 119
A live specification 119
Keeping it live 120
Introducing changes 123
Solving problems 124
Keeping the software flexible 125
Keeping the specification flexible 126
III. Implementing agile acceptance testing 139
8. Starting with agile acceptance testing 141
Agile acceptance testing in the context of the development process 141
Fitting into iterations 144
Igniting the spark 148
Don’t mention testing 150
Adopting in phases 151
Choose a facilitator for the workshops 152
Hire a mentor 154
Avoid the cargo cult mentality 155
9. Planning with user stories 159
User stories in a nutshell 160
How are stories different from more traditional methods? 161
Benefits of user stories 162
Three Cs of user stories 164
Project planning 165
User stories and acceptance tests 169
10. Tools of today 173
FIT 173
Concordion 179
JBehave 181
TextTest 183
Selenium 187
11. Tools of tomorrow 195
Domain-specific languages 195
Different user interfaces for different roles 197
Propagating the effects of changes 198
Direct domain mapping 200
Better editors 201
Better test organisation 202
Visual workflow descriptions 203
IV. Effects on all of us 205
12. Effects on business analysts 207
Benefits for business analysts 208
Challenges for business analysts 211
13. Effects on testers 219
The new role of the tester 219
Benefits for testers 220
Challenges for testers 224
14. Effects on developers 231
New responsibilities for developers 231
Benefits for developers 232
Challenges for developers 234
A. Resources 241
Online resources 243
Talks and videos 243
Presentations 244
Articles 244
Tools 245
Mailing Lists 245
Index 247