Unique, distilled knowledge from extensive industry research.
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.
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
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
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
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
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
6. Chapter 6 Specifying collaboratively
6.1. Why do we need to collaborate on specifications?
6.2. The most popular collaborative models
6.3. Preparing for collaboration
6.4. Choosing a collaboration model
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
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
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
10. Chapter 10 Validating frequently
10.1. Reducing unreliability
10.2. Getting feedback faster
10.3. Managing failing tests
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
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.
- 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.
I love this book. This is testing done right.
It will change the way we talk and think about testing.
The best book on requirement collection and maintenance.
Best book I have read in ages.
Based on the experience of many teams, it will double the value of your test automation.