Specification by Example
How Successful Teams Deliver the Right Software
Gojko Adzic
  • June 2011
  • ISBN 9781617290084
  • 296 pages
  • printed in black & white

Unique, distilled knowledge from extensive industry research.

Mike Stockdale, Syterra Software

In this emerging software development practice, teams bridge the communication gap between business stakeholders and dev teams. From the experience of leading teams worldwide, author Gojko Adzic distills seven key patterns and many practical rules for effective ways to specify, test, and deliver software in short, iterative delivery cycles.

Table of Contents show full



About the author

About the cover illustration

Appendix A Resources


PART 1 Getting Started

1. Chapter 1 Key benefits

1.1. Implementing changes more efficiently

1.2. Higher product quality

1.3. Less rework

1.4. Better work alignment

1.5. Remember

2. Chapter 2 Key process patterns

2.1. Deriving scope from goals

2.2. Specifying collaboratively

2.3. Illustrating using examples

2.4. Refining the specification

2.5. Automating validation without changing specifications

2.6. Validating frequently

2.7. Evolving a documentation system

2.8. A practical example

2.9. Remember

3. Chapter 3 Living documentation

3.1. Why we need authoritative documentation

3.2. Tests can be good documentation

3.3. Creating documentation from executable specifications

3.4. Benefits of the documentation-centric model

3.5. Remember

4. Chapter 4 Initiating the changes

4.1. How to begin changing the process

4.2. How to begin changing the team culture

4.3. How teams integrated collaboration into flows and iterations

4.4. Dealing with sign-off and traceability

4.5. Warning signs

4.6. Remember

PART 2 Key process patterns

5. Chapter 5 Deriving scope from goals

5.1. Building the right scope

5.2. Collaborating on scope without high-level control

5.3. Further information

5.4. Remember

6. Chapter 6 Specifying collaboratively

6.1. Why do we need to collaborate on specifications?

6.3. Preparing for collaboration

6.4. Choosing a collaboration model

6.5. Remember

7. Chapter 7 Illustrating using examples

7.1. Illustrating using examples: an example

7.2. Examples should be precise

7.3. Examples should be complete

7.4. Examples should be realistic

7.5. Examples should be easy to understand

7.6. Illustrating nonfunctional requirements

7.7. Remember

8. Chapter 8 Refining the specification

8.1. An example of a good specification

8.2. An example of a bad specification

8.3. What to focus on when refining specifications

8.4. Refining in practice

8.5. Remember

9. Chapter 9 Automating validation without changing specifications

9.1. Is automation required at all?

9.2. Starting with automation

9.3. Managing the automation layer

9.4. Automating user interfaces

9.5. Test data management

9.6. Remember

10. Chapter 10 Validating frequently

10.1. Reducing unreliability

10.2. Getting feedback faster

10.3. Managing failing tests

10.4. Remember

11. Chapter 11 Evolving a documentation system

11.1. Living documentation should be easy to understand

11.2. Living documentation should be consistent

11.3. Living documentation should be organized for easy access

11.4. Listen to your living documentation

11.5. Remember

PART 3 Case studies

12. Chapter 12 uSwitch

12.1. Starting to change the process

12.2. Optimizing the process

12.3. The current process

12.4. The result

12.5. Key lessons

13. Chapter 13 RainStor

13.1. Changing the process

13.2. The current process

13.3. Key lessons

14. Chapter 14 Iowa Student Loan

14.1. Changing the process

14.2. Optimizing the process

14.3. Living documentation as competitive advantage

14.4. Key lessons

15. Chapter 15 Sabre Airline Solutions

15.1. Changing the process

15.2. Improving collaboration

15.3. The result

15.4. Key lessons

16. Chapter 16 ePlan Services

16.1. Changing the process

16.2. Living documentation

16.3. Current process

16.4. Key lessons

17. Chapter 17 Songkick

17.1. Changing the process

17.2. Current process

17.3. Key lessons

18. Chapter 18 Concluding thoughts

18.1. Collaboration on requirements builds trust between stakeholders and delivery team members

18.2. Collaboration requires preparation

18.3. There are many different ways to collaborate

18.4. Looking at the end goal as business process documentation is a useful model

18.5. Long-term value comes from living documentation

© 2014 Manning Publications Co.

About the Technology

Specification by Example is a collaborative method for specifying requirements and tests. Seven patterns, fully explored in this book, are key to making the method effective. The method has four main benefits: it produces living, reliable documentation; it defines expectations clearly and makes validation efficient; it reduces rework; and, above all, it assures delivery teams and business stakeholders that the software that's built is right for its purpose.

About the book

This book distills from the experience of leading teams worldwide effective ways to specify, test, and deliver software in short, iterative delivery cycles. Case studies in this book range from small web startups to large financial institutions, working in many processes including XP, Scrum, and Kanban.

What's inside

  • Common process patterns
  • How to avoid bad practices
  • Fitting SBE in your process
  • 50+ case studies

About the reader

This book is written for developers, testers, analysts, and business people working together to build great software.

About the author

A UK based consultant, Gojko Adzic helps teams worldwide implement Specification by Example and agile testing practices.

For additional resources go to specificationbyexample.com.

combo USD49.99 pBook + eBook
eBook USD35.99 pdf + ePub + kindle

FREE domestic shipping on three or more pBooks

I love this book. This is testing done right.

Craig Smith, Suncorp

It will change the way we talk and think about testing.

David Evans, ThinkAlike Consulting

The best book on requirement collection and maintenance.

Oleksandr Alesinskyy, NAVTEQ

Best book I have read in ages.

John Stevenson, Lean Agile Machine

Based on the experience of many teams, it will double the value of your test automation.

Rick Mugridge, Rimu Research