Critérios de aceitação

Critérios de aceitação são as condições que definem quando uma história de usuário está pronta do ponto de vista do negócio. Cada critério é uma afirmação clara e testável, com resultado de aprovado ou reprovado. Eles são combinados durante o refinamento, antes de o desenvolvimento começar, e se tornam o ponto de partida para os cenários de teste e as verificações automatizadas.

Exemplo

História: Como cliente, quero aplicar um cupom de desconto no checkout para pagar o preço promocional.

Formato baseado em regras:

• Um cupom válido e dentro da validade reduz o total do pedido pelo percentual do cupom.
• Um cupom expirado mostra “This code has expired” e não altera o total.
• Só é possível aplicar um cupom por pedido; aplicar um segundo substitui o primeiro.
• Os cupons não diferenciam maiúsculas de minúsculas (SAVE10 e save10 são equivalentes).

O mesmo critério do cupom expirado no formato Given/When/Then (Dado/Quando/Então):

Scenario: Expired discount code is rejected
  Given my cart total is $50.00
  And the code "SPRING10" expired yesterday
  When I apply the code "SPRING10"
  Then I see the message "This code has expired"
  And my cart total is still $50.00

Critérios de aceitação vs Definition of Done

Critérios de aceitação são específicos de uma história: o que esta funcionalidade precisa fazer. A Definition of Done (Definição de Pronto) vale para todas as histórias: código revisado, testes automatizados, documentação atualizada, deploy em staging. Uma história só está concluída quando atende às duas coisas.

Como escrever bons critérios

• Testáveis. “A página carrega rápido” não é testável; “a página de resultados renderiza em até 2 segundos para 1.000 produtos na base de staging” é.
• Comportamento, não implementação. Descreva resultados, não qual tabela do banco de dados muda.
• Inclua casos negativos. Entradas inválidas, permissões e mensagens de erro fazem parte da funcionalidade.
• Combinados pelos three amigos. Produto, desenvolvimento e teste revisam os critérios juntos. É aqui que o tester mais agrega valor, perguntando “o que acontece se…?” antes de o código ser escrito.