I define an acceptance test as a clear check I run to confirm that a system meets its requirements. First, I identify the requirement. Then, I write one or more acceptance tests that prove the requirement. Next, I run the tests with real input. Finally, I decide whether the system satisfies the requirement.
I write acceptance tests for the product owner and for customers. Therefore, they can decide to accept or reject the system. Moreover, I use acceptance tests to avoid arguments about scope. For example, I place acceptance criteria on the back of a user story card. In addition, I make the acceptance criteria executable when possible. Thus, the tests become precise and repeatable.
I use acceptance tests throughout Agile. First, I include acceptance criteria when I prepare backlog items. Then, I refine them with the team during conversation. Because of the card, conversation, confirmation (CCC) model, the acceptance test gives us the final confirmation. In particular, I and the product owner settle the final details when the conversation touches the acceptance tests. Consequently, the team knows exactly what to implement.
I keep acceptance tests short and focused. Moreover, I tie each test to a single observable outcome. For example, I test one user-visible behavior per acceptance test. Therefore, I make user stories testable. In addition, I ensure stories meet the INVEST criteria. In particular, I confirm that each story is Testable. Also, I split large stories into smaller ones so that each fits into one iteration. As a result, I can create precise acceptance tests for each small story.
I prefer executable acceptance tests. First, I write tests that automation tools can run. Then, I automate the most important checks. However, I also accept manual tests when automation is costly. Still, I use examples or prototypes to explain unclear behavior. Therefore, I reduce misunderstanding and rework.
I involve stakeholders in acceptance testing. For instance, I ask customers, product owners, developers, and testers to join test definition. In addition, I invite them to the demonstration at the end of an iteration. There, I run the acceptance tests. Consequently, the product owner learns whether the team can deliver what was needed. Likewise, customers see the real behavior and give feedback.
I track traceability between requirements and acceptance tests. For example, I map each test case to the requirement it covers. Therefore, I keep clear backward and forward links. As a result, I can show which requirements a failing test affects. Moreover, I can update tests when requirements change.
I write acceptance tests in plain language. In addition, I use simple steps and clear expected results. Thus, translators can convert the text to other languages easily. Furthermore, automated translation handles short sentences better. Therefore, I keep sentences short and vocabulary simple to optimize future translation.
In conclusion, I use acceptance tests to confirm requirements. Moreover, I use them to guide development, to support prioritization, and to provide clear confirmation at the end of each iteration. Consequently, acceptance tests help me deliver the right product to the customer.