Agile in a Flash 22

Acceptance Test Design Principles – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #22)

Well- designed acceptance tests are

> Abstract

> Bona fide

> Cohesive

> Decoupled

> Expressive

> Free of duplication

> Green--

Acceptance tests (ATs) are as enduring and important an artifact as your code. Their proper design will minimize maintenance efforts.

Abstract A test is readable as a document describing system behavior. Amplify your test’s essential elements, and bury its irrelevant details so that nontechnical staff can understand why it should pass.

Bona fide To ensure continual customer trust, a test must always truly exercise the system in an environment as close to production as possible.

Cohesive A test expresses one goal accomplished by interacting with the system. Don’t prematurely optimize by combining multiple cases into one test.

Decoupled Each test stands on its own, not impacted by or dependent upon results of other tests.

Expressive A test is highly readable as documentation, requiring no research or analysis from its readers. Name it according to the goal it achieves.

Free of duplication Duplication increases risk and cost, particularly when changes to frequently copied behavior ripple through dozens or more tests.

Green Once a story is complete, its associated ATs must always pass. A failing production AT should trigger a stop-the-production-line mentality.

Agile in a Flash 21

Acceptable Acceptance Tests– The Plan

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.