Essential Acceptance Testing
This book is 90% complete
Last updated on 2013-10-30
About the Book
This book discusses the conventional acceptance testing strategies used by many agile teams today and asks if they still hold up. It first describes generally accepted strategies, their motivations, pitfalls and techniques to maximise success. It talks about how testing influences design and how to avoid the common problem of too many tests and specification overload.
After the description of the "norm", the book discusses why some of these techniques are fundamentally flawed and poses some difficult questions.
- Has acceptance testing technique become dogma?
- Can stories really have business "value"? How can we test value?
- Can we run thousands of acceptance tests quickly?
If you want tips applying conventional acceptance testing strategies, this book can help you get started and avoid common mistakes. If you're interested in what's beyond the canon, this book will help open the door. Inspired by real world frustrations and lean principles, this book questions the de facto agile stance on testing.
Lean Publishing
"Publish early. Publish Often. Listen to your readers."
In keeping with lean publishing principles, this is an in-progress subset of the complete book. I hope that readers will debate, ask questions and help steer the direction of the book. If there's no interest, that's great too. Failing fast is always a better than failing slowly.
Also by Toby Weston
About the Author
About the Contributors
Table of Contents
-
- Publishing notes
-
Part 1 - An agile approach to acceptance testing
-
Introduction
- What is an acceptance test?
- What are acceptance criteria?
- What is a story?
- Bringing it all together
-
Typical process overview
- The story delivery lifecycle
- Pick a story
- Agree acceptance criteria
- Develop
- Demonstrate
- Deliver
-
Introduction
-
Part 2 - Discussion and alternatives
-
Problems acceptance testing can fix
- Communication barriers
- Lack of shared memory
- Lack of collective understanding of requirements
- Blurring the “what” with the “how”
- Ambiguous language
- Lack of structure and direction
- Team engagement
-
Problems acceptance testing can cause
- Communication crutch
- Hand off behaviour
- Technical overexposure
- Cargo cult
- Command and control structures
- Construct validity
- Artificial constraints
-
Business value
- Defining “value”
- Measuring “value”
-
Alternatives to acceptance tests
- Don’t write acceptance tests
- Use a ports and adapters architecture
- Don’t specify
- Measure, don’t agree
- Log, don’t specify
-
How design can influence testing
- Sample application
- Coupled architecture
- Decoupled architecture using ports and adapters
- Testing end-to-end (system tests)
- Summary of test coverage
- Benefits using ports and adapters
- Disadvantages using ports and adapters
-
Common pitfalls
- Features hit production that the customer didn’t want
- Users describe solutions not problems
- Users can’t tell how the system is supposed to behave
- Users can’t tell if feature x is already implemented
- Tests repeat themselves.
- The acceptance test suite takes forever to run
- Intermittent failures in tests
-
Q&A
- What do we mean when we say “acceptance testing”
- How do I manage large numbers of acceptance tests?
- How do you map acceptance tests to stories in say JIRA?
- How does applying acceptance testing techniques help us focus on reducing complexity?
- When would you not write stories? Acceptance criteria?
- How does agile acceptance testing differ from conventional UAT?
- What are some other testing strategies? How does acceptance testing fit in?
- How do you layer various types of testing to maximise benefit?
- How does exception testing fit with unit and end-to-end tests?
- Aren’t acceptance tests slow with high maintenance costs?
- What’s the best way to leverage CI servers like TeamCity and Jenkins?
- Where does BDD fit in?
- Can I run acceptance tests in parallel?
- How can I run acceptance tests which exercise business processes than span multiple business days?
- How should I setup and tear down data?
-
Problems acceptance testing can fix
-
Part 3 - Specification testing frameworks
-
- Reading list
-
Other books by this author
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
