Bridging the Communication Gap
Specification by Example and Agile Acceptance Testing
By Gojko Adzic
Buy the paperback | Buy the PDF | 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
Reviews
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, www.markhneedham.com/blog/
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, www.rimuresearch.com, 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, ericlefevre.net/
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, www.agiletester.net
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, www.testdriven.com
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 Guild.com 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… — ComputerWorldUK.com 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 stickyminds.com
Sample chapters
- Introduction
- Chapter 1: The next bottleneck in software projects
- Chapter 2: Finding ways to communicate better
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 |