Critérios de Aceitação: Como Escrevê-los (Com Exemplos)

Os critérios de aceitação são as condições que uma história de usuário precisa satisfazer antes que a equipe a considere pronta para entrega. Defina-os corretamente e você reduz retrabalho, discussões e bugs inesperados na revisão.

O que são critérios de aceitação?

Critérios de aceitação são um conjunto de condições específicas e verificáveis associadas a uma única história de usuário. Eles definem o que a funcionalidade deve fazer (e o que não deve) do ponto de vista do usuário. Quando todas as condições são atendidas, a história é aceita. Quando ao menos uma falha, o trabalho continua.

Pense neles como o contrato entre quem solicitou a funcionalidade e a equipe que vai construí-la. Sem adivinhações. Sem "achei que você queria dizer outra coisa." Apenas uma lista clara de condições de aprovação ou rejeição, escrita antes de o desenvolvimento começar.

Os critérios de aceitação existem no nível da história. Eles respondem à pergunta: "Como saberemos que esta história está pronta?" Essa é uma pergunta diferente de "Como saberemos que o Sprint está concluído?", que é o que o definition of done responde.

Fatos Principais

• O formato Given-When-Then para critérios de aceitação foi introduzido por Dan North como parte do desenvolvimento guiado por comportamento (BDD) por volta de 2006, oferecendo às equipes uma forma estruturada e verificável de expressar o comportamento esperado. (Fonte: Dan North, "Introducing BDD," dannorth.net, 2006.)
• A Agile Alliance observa que critérios de aceitação ambíguos ou ausentes estão entre as causas mais comuns de retrabalho em projetos Agile. (Fonte: Agile Alliance Glossary, agilealliance.org.)
• Equipes que escrevem critérios de aceitação antes de codificar relatam transferências mais rápidas do desenvolvimento para o QA, pois os testadores já sabem o que verificar.

Formatos para escrever critérios de aceitação

Há dois formatos que as equipes mais utilizam. Nenhum é universalmente superior. Escolha o que melhor se encaixa na forma como sua equipe trabalha.

Given-When-Then (baseado em cenário)

Também chamado de formato Gherkin, esse formato vem do desenvolvimento guiado por comportamento (BDD). Ele estrutura cada condição como um cenário com três partes:

• Given (Dado) -- o estado inicial ou contexto
• When (Quando) -- a ação que o usuário realiza
• Then (Então) -- o resultado esperado

Exemplo -- login do usuário:

Given um usuário cadastrado está na página de login
When ele insere um e-mail válido e a senha correta e clica em "Entrar"
Then ele é redirecionado para o painel e vê uma mensagem de boas-vindas

Given um usuário cadastrado está na página de login
When ele insere um e-mail válido e uma senha incorreta
Then ele vê uma mensagem de erro: "E-mail ou senha incorretos" e permanece na página de login

Esse formato funciona bem quando o comportamento é sequencial e você pode escrever múltiplos cenários de falha ao lado dos caminhos bem-sucedidos. Os engenheiros de QA podem transformar cada cenário diretamente em um caso de teste.

Baseado em regras (lista de verificação)

Algumas equipes preferem uma lista de regras mais simples. Esse formato é adequado para histórias em que as condições são independentes, não sequenciais.

Exemplo -- busca de produto:

- Os resultados da busca aparecem em até 2 segundos para qualquer consulta
- Os resultados são ordenados por relevância por padrão
- Os usuários podem filtrar os resultados por categoria, faixa de preço e avaliação
- Se nenhum resultado for encontrado, a página exibe: "Nenhum resultado para [consulta]. Tente palavras-chave diferentes."
- A barra de busca mantém a consulta do usuário após o carregamento dos resultados

Critérios de aceitação baseados em regras são mais rápidos de escrever e mais fáceis de verificar. Funcionam melhor para restrições de interface, requisitos de desempenho e casos extremos que não se encaixam bem em uma sequência de ações do usuário.

Critérios de aceitação vs definition of done

Esses dois conceitos costumam ser confundidos. Eles resolvem problemas diferentes.

Uma história pode passar em todos os seus critérios de aceitação e ainda assim reprovar no definition of done, por exemplo, se não tiver testes unitários ou não passou por revisão de pares. Ambas as listas precisam ser aprovadas antes que o trabalho seja considerado realmente completo.

Veja a análise completa no artigo sobre definition of done.

Características de bons critérios de aceitação

Nem toda lista de condições se qualifica como bons critérios de aceitação. Veja o que separa o útil do vago:

Verificável. Cada condição deve ter uma aprovação ou rejeição clara. "A interface parece bonita" não é verificável. "O botão atinge uma proporção de contraste de 4,5:1" é.

Escrito do ponto de vista do usuário. Os critérios de aceitação descrevem o que o usuário experimenta, não como o código é estruturado. Evite detalhes de implementação como "a API retorna status 200." Prefira: "o usuário vê seu perfil atualizado imediatamente."

Específico. Números, estados e rótulos importam. "Resposta rápida" vira "resposta em menos de 1,5 segundo." "Uma mensagem de erro" vira "o texto exato: 'A senha deve ter pelo menos 8 caracteres.'"

Acordado antes do início do desenvolvimento. Critérios escritos após a funcionalidade ser construída tendem a racionalizar o que foi feito, em vez de descrever o que era necessário. Escreva-os durante o backlog refinement.

Não em excesso. De três a oito condições é uma quantidade saudável. Uma história com quinze critérios de aceitação provavelmente esconde duas ou três histórias dentro de uma só.

Como escrever critérios de aceitação

Passo 1: Comece com a história de usuário

Você não pode escrever critérios de aceitação sem uma história de usuário clara. Confirme que você tem uma neste formato:

Como um [persona], quero [objetivo], para que [razão].

Se a história for vaga, refine-a antes de escrever as condições.

Passo 2: Pergunte "o que precisa ser verdade para que isso funcione?"

Liste os comportamentos e resultados que a funcionalidade deve produzir. Cubra primeiro o caminho bem-sucedido, depois os casos extremos e os estados de falha.

Passo 3: Escolha um formato

Opte por Given-When-Then se o comportamento for sequencial e o QA for responsável pela criação dos testes. Opte pelo baseado em regras se as condições forem independentes ou se você estiver sob pressão de tempo.

Passo 4: Escreva em linguagem verificável

Substitua palavras vagas. "Rapidamente" vira um número. "Formatado corretamente" vira o formato exato. "Deve funcionar no celular" vira "o layout é responsivo na largura de 375px."

Passo 5: Revise com a equipe antes do início do desenvolvimento

Compartilhe o rascunho com desenvolvedores, QA e partes interessadas. Os desenvolvedores identificarão condições tecnicamente impossíveis. O QA detectará casos extremos ausentes. As partes interessadas corrigirão erros de lógica de negócio. Faça isso durante o backlog refinement ou o planejamento do sprint para que todos se alinhem antes de uma linha de código ser escrita.

Passo 6: Anexe à história

Adicione os critérios finalizados à história no seu product backlog. Eles permanecem anexados durante todo o desenvolvimento e constituem a lista de verificação que a equipe usa durante a revisão do sprint.

Exemplos de critérios de aceitação

Aqui estão três exemplos práticos de diferentes tipos de história.

Exemplo 1: Login do usuário

História: Como usuário recorrente, quero entrar com meu e-mail e senha para acessar minha conta.

Given o usuário está na página de login
When ele insere um e-mail cadastrado e a senha correta e clica em "Entrar"
Then ele é redirecionado para o painel em até 2 segundos

Given o usuário insere uma senha incorreta três vezes
When ele tenta um quarto login
Then a conta é bloqueada por 30 minutos e o usuário vê:
"Muitas tentativas falhas. Tente novamente em 30 minutos."

Given o usuário está autenticado
When ele clica em "Sair"
Then sua sessão é encerrada e ele é redirecionado para a página inicial

Exemplo 2: Total do pedido

História: Como comprador, quero ver o total do meu pedido antes de pagar, para saber exatamente o quanto devo.

Exemplo 3: Busca sem resultados

História: Como usuário, quero saber quando minha busca não retorna nada, para tentar palavras-chave diferentes.

- Quando uma busca retorna zero resultados, a página exibe: "Nenhum resultado para '[consulta]'. Tente palavras-chave diferentes."
- A barra de busca mantém a consulta original do usuário
- Sugestões de categorias relacionadas aparecem abaixo da mensagem, quando disponíveis
- O título da página é atualizado para refletir o estado de busca vazia

Erros comuns a evitar

Escrever depois do fato. Critérios de aceitação escritos após o desenvolvimento descrevem o que foi construído, não o que era necessário. Escreva-os primeiro.

Ser vago sobre estados de erro. Critérios que cobrem apenas o caminho bem-sucedido deixam os desenvolvedores sem orientação sobre como lidar com falhas. Sempre inclua ao menos um cenário de falha.

Misturar detalhes técnicos de implementação. "O serviço chama a API de pagamento com uma requisição POST" não é um critério de aceitação. "O usuário vê uma confirmação de pagamento em até 3 segundos" é.

Torná-los grandes demais. Se os seus critérios de aceitação cobrem várias funcionalidades distintas, divida a história. Uma boa história com bons critérios cabe em um cartão de índice.

Pular a revisão da equipe. Critérios escritos de forma isolada (geralmente pelo Product Owner) ignoram restrições técnicas e casos extremos do QA. Revise-os juntos antes de o sprint começar. Use as agile ceremonies como o refinement para fazer isso de forma consistente.

Perguntas frequentes

O que são critérios de aceitação?

Critérios de aceitação são as condições específicas e verificáveis que uma história de usuário precisa satisfazer antes que a equipe a aceite como concluída. Eles definem o que a funcionalidade deve fazer do ponto de vista do usuário e são escritos antes do início do desenvolvimento.

Quem escreve os critérios de aceitação?

O Product Owner normalmente elabora os critérios de aceitação, mas toda a equipe, incluindo desenvolvedores, QA e, às vezes, partes interessadas, os revisa e refina antes do início do desenvolvimento. Escrever critérios de forma isolada resulta em casos extremos ignorados e retrabalho.

Qual é a diferença entre critérios de aceitação e o definition of done?

Critérios de aceitação são por história: descrevem o que uma funcionalidade específica deve fazer. O definition of done é global: uma lista de verificação que se aplica a todas as histórias do sprint (revisão de pares, cobertura de testes, documentação, etc.). A história precisa passar nas duas antes de ser entregue.

O que é Given-When-Then?

Given-When-Then é um formato estruturado para escrever critérios de aceitação como cenários verificáveis. "Given" define o contexto, "When" descreve a ação do usuário e "Then" indica o resultado esperado. Foi introduzido por Dan North como parte do desenvolvimento guiado por comportamento (BDD) por volta de 2006 e é amplamente utilizado em equipes Agile hoje.

Quantos critérios de aceitação uma história de usuário deve ter?

Mire em três a oito. Menos de três geralmente indica que a história está subespecificada. Mais de oito costuma significar que a história é grande demais e deve ser dividida em histórias menores.

---

Bons critérios de aceitação não garantem um produto excelente, mas evitam uma categoria específica de falha: construir algo que ninguém pretendia construir. Escreva-os cedo, revise-os juntos e você verá que as revisões de sprint deixam de ser debates sobre o que "pronto" significa e se tornam demonstrações diretas de software funcionando.