Essential Acceptance Testing
Essential Acceptance Testing
Discussing agile acceptance testing techniques
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 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
