Agile
in a Flash by Jeff Langr and Tim Ottinger (card #21)
Acceptance tests are used to
verify that the team has built what the customer requested in a story.
> Are defined by the customer
> Define “done done” for
stories
> Are automated
> Document uses of the system
> Don’t just cover happy paths
> Do not replace exploratory
tests
> Run in a near-production
environment
--
Are
defined by the customer Acceptance tests (ATs) are an expression of
customer need. All parties can contribute, but ultimately, a single customer voice
defines their interests as an unambiguous set of tests.
Define
“done done” for stories ATs are written before development as a contract for
completion. Passing ATs tell programmers their work is done and tell customers
that they can accept it.
Are
automated
You can script, and thus automate, all tests that define expected system
capabilities. Manually executed scripts are a form of abuse.
Document
uses of the system
Design readable tests so they demonstrate, by example, valid uses of the
system. Such documentation never becomes stale!
Don’t
just cover happy paths It’s hard to capture all alternate and exceptional conditions.
Inevitably you’ll miss one. Add it to your AT suite.
Do
not replace exploratory tests Exploratory testing highlights the more
creative aspects of how a user might choose to interact with a new feature. It
also helps teach testers how to improve their test design skills.
Run
in a near-production environment ATs execute in an environment that emulates
production as closely as possible. They hit a real database and external API
calls as much as possible. ATs are slow by definition.
