Critérios de aceite: o contrato entre negócio e tech
"Não era isso que eu pedi" é sintoma de contrato ausente. Aprenda a escrever critérios de aceite verificáveis com Dado/Quando/Então, cobrir os cenários de borda e usar os três amigos.
"Mas não era isso que eu pedi." Se essa frase circula nas suas demos de sprint, o problema quase nunca é competência: é a ausência de um contrato claro sobre o que significa pronto.
Critério de aceite é exatamente esse contrato. Uma lista curta, escrita antes do desenvolvimento, que define de forma verificável quando uma história está concluída. Não é burocracia ágil: é o documento que faz negócio, desenvolvimento e QA enxergarem a mesma entrega antes de ela custar um sprint.
O que separa um critério bom de um enfeite
Compare:
Enfeite: "O login deve ser seguro e rápido."
Critério: "Após 5 tentativas de senha incorreta, a conta bloqueia por 15 minutos e o usuário recebe e-mail de aviso."
A diferença é uma só: verificabilidade. O segundo pode virar caso de teste sem interpretação; o primeiro vira discussão na demo. A régua prática: se duas pessoas podem ler e imaginar resultados diferentes, ainda não é critério de aceite.
O formato que organiza a conversa: Dado / Quando / Então
O padrão mais usado na indústria é o Gherkin, popularizado pela ferramenta Cucumber (cucumber.io):
- Dado um carrinho com produtos somando R$ 180
- Quando o cliente aplica o cupom PRIMEIRACOMPRA
- Então o desconto de 10% aparece no resumo e o total cai para R$ 162
O valor do formato não está na sintaxe, está no que ele obriga a pensar: o estado inicial (dado), a ação (quando) e o resultado observável (então). E cada cenário assim escrito já nasce sendo um roteiro de teste, manual ou automatizado.
Os cenários que ninguém escreve (e todo bug agradece)
O caminho feliz todo mundo lembra. O contrato fica completo quando cobre também:
- O caminho triste: cupom expirado, cartão recusado, CPF inválido. O que o usuário vê? Mensagem que ajuda ou que culpa?
- As bordas: carrinho zerado, valor exatamente no limite do frete grátis, primeiro acesso sem histórico. É onde moram os bugs que o QA pega.
- Os requisitos invisíveis: funciona no celular? Responde em quanto tempo? E se o usuário não tiver permissão?
Não é preciso prever tudo (ninguém consegue). É preciso cobrir o que, se falhar, dói.
Quem escreve: os três amigos
Critério de aceite escrito por uma pessoa só herda os pontos cegos dela. A prática consagrada é a conversa dos três amigos: negócio (o que precisa acontecer), desenvolvimento (o que é viável e o que quebra) e QA (o que pode dar errado). Quinze minutos dessa conversa por história economizam dias de retrabalho.
É também o elo com o processo que já descrevemos nesta série: histórias que chegam do Discovery com problema validado e prioridade justificada só ficam completas quando o "pronto" está contratado. Sem isso, nem a melhor pirâmide de testes sabe o que verificar.
O anti-padrão: critério como especificação de tela
Critério de aceite bom descreve comportamento, não implementação. "O botão fica no canto direito, azul, 16px" não é critério; é design (que tem seu lugar: o Design System). Quando o critério amarra a implementação, ele trava soluções melhores e envelhece na primeira mudança visual.
Do "não era isso" ao "exatamente isso"
Instalar essa disciplina (formato, três amigos, cenários de borda, ligação direta com os testes) é parte do nosso serviço de Qualidade e Testes. O efeito colateral favorito dos times: demos sem surpresa e sprints sem devolução.
Quer testar agora? Cole uma história do seu backlog na conversa com a IA da Rabelo Digital, aqui no canto da tela, e ela devolve os critérios de aceite que faltam. Sem formulário, sem espera.
Deixe um Comentário