Critérios de aceitação por item de trabalho que podem virar testes

Objetivo

Tornar o "pronto" de um único item de trabalho decidível antes de o trabalho começar, para que quem desenvolve, quem revisa e quem fez o pedido concordem com os mesmos exemplos.

Pré-requisitos

Um item de trabalho com finalidade declarada (quem precisa de quê e por quê), acesso à pessoa que pode responder a dúvidas de domínio e um lugar onde os critérios fiquem junto ao item.

Passos

1. Escreva a regra em uma frase e depois os exemplos. A referência do Gherkin descreve este formato: um contexto inicial (Given), um evento (When) e um resultado esperado (Then), e recomenda de 3 a 5 passos por exemplo para que ele continue legível como especificação.
2. Cubra o caso principal, cada limite e os caminhos de falha. Um conjunto de critérios para "limitar uploads a 10 MB" tem no mínimo: exatamente 10 MB é aceito, 10 MB mais um byte é rejeitado com a mensagem especificada, e a rejeição não deixa nenhum arquivo parcial.
3. Use valores concretos, não adjetivos: "o saldo mostra £430" em vez de "o saldo está correto". Os próprios exemplos do Gherkin contrastam "there is money in my account" com "my account has a balance of £430".
4. Mantenha a interação do usuário fora do Given e os detalhes de implementação fora de tudo: os critérios descrevem o comportamento visível na fronteira que o usuário ou o cliente enxerga.
5. Leia cada critério e pergunte: um testador que nunca viu o código conseguiria decidir entre aprovado e reprovado só com este texto? Se não, reescreva.
6. Marque o que está deliberadamente fora do escopo deste item, para que um "você esqueceu X" seja respondido pelo item, e não pela memória.
7. Antes da implementação, quem desenvolve propõe os exemplos que faltam e quem solicitou confirma. Divergências encontradas aqui custam menos do que na revisão.
8. Transforme os exemplos em testes automatizados onde a fronteira permitir (API, lógica de domínio) e em uma checklist manual onde não permitir (layout visual). Vincule o teste ou a checklist ao item.

Resultado esperado

Revisão e aceitação passam a ser uma comparação com exemplos listados; o aumento de escopo aparece como um novo exemplo que precisa ser negociado, e não como algo presumido.

Limites e base de verificação

Exemplos não conseguem enumerar tudo; requisitos não funcionais (latência, acessibilidade) precisam de uma meta mensurável, e não de um cenário. As ferramentas do Gherkin são opcionais; a disciplina está nos exemplos, não no executor. Método sintetizado a partir da referência citada e da prática comum; não se afirma nenhum efeito sobre a taxa de defeitos.