Historicamente, como usuário, você só veria um novo produto de software muito depois que a maioria dos desenvolvedores e testadores tivessem passado adiante. Devido a essa longa lacuna, os testes de aceitação foram cruciais para determinar se o software satisfazia as expectativas e era funcional para seus usuários, em outras palavras: se ele era aceitável e apto para entrar em funcionamento. Somente se ele fosse adicionado a um ambiente de produção e utilizado no curso normal dos negócios. No desenvolvimento ágil, os testes de aceitação são parte do processo e não uma reflexão posterior. Entretanto, a intenção ainda é a mesma: verificar se o software atende às expectativas do ponto de vista do cliente e dos usuários finais. Quando você trabalha com uma equipe ágil e madura, você não verá nenhuma diferença entre as especificações e a verificação. Você colabora com a equipe para criar histórias de usuários e seus critérios de aceitação. E você ou eles escrevem esses critérios de aceitação em uma notação que as ferramentas podem se transformar em testes de aceitação automatizados. O tremendo benefício é que o produto em desenvolvimento está sempre em um estado aceitável — sem mais surpresas desagradáveis.