Teste de Aceitação

Não confunda aceitação e teste de aceitação do usuário

Na situação ideal, o teste de aceitação e o teste de aceitação do usuário são os mesmos, mas … a literatura de desenvolvimento Ágil usa o termo “testes de aceitação”, onde usamos o termo “testes voltados para o cliente”. No entanto, no desenvolvimento tradicional, “testes de aceitação” geralmente significam “testes de aceitação do usuário”, que pode ser diferente. Evite mal-entendidos.

acceptance_vs_uat.png
UAT is a subset of acceptance tests

A figura acima expressa a relação em um diagrama. O teste de aceitação do usuário (UAT) é parte dos testes de aceitação no desenvolvimento ágil. Mas o teste de aceitação também pode incluir testes não-UAT, como teste funcional tradicional ou teste de sistemas criado pela equipe.

Idealmente, todos os testes de aceitação - inclusive UAT - são feitos dentro da iteração. No entanto, obter o UAT na iteração pode ser difícil, porque exige um envolvimento ativo do usuário final e nem todos os clientes estão disponíveis para isso. Nesse caso, a UAT é excluída da Definição de Pronto até que o grupo de produtos melhore seu relacionamento com o cliente para que eles possam expandir sua Definição de Pronto.

Mostre testes na Sprint Review

Na Revisão da Sprint, a equipe demonstra o progresso visível para o Product Owner, mostrando o resultado da iteração.

Trabalhamos com alguns grupos que definiram os passos de demonstração durante o planejamento da Sprint. A equipe gastaria uma quantidade excessiva de tempo na preparação de demonstração. Um desperdício completo.

Durante o Planejamento da Sprint, uma alternativa é definir os exemplos que precisam passar e mostrar o progresso usando esses testes na revisão da Sprint.

Use desenvolvimento orientado a testes de aceitação

Desenvolvimento Orientado a Testes de Aceitação (A-TDD) or Especificação por exemplo é uma abordagem colaborativa de descoberta de requisitos onde exemplos e testes automatizados são usados ​​para especificar requisitos, criando especificações executáveis. Eles são criados com a equipe, o Product Owner e outras partes interessadas nas oficinas de requisitos.