Criando critérios de aceitação claros

Requisitos vagos levam a mal-entendidos, retrabalho e frustração. Critérios de aceitação claros definem exatamente o que precisa ser verdadeiro para uma tarefa estar completa. Tarefas GitScrum com critérios de aceitação bem definidos são completadas corretamente na primeira vez.

Por que critérios de aceitação importam

Formatos de critérios de aceitação

Formato Given-When-Then

GIVEN-WHEN-THEN (Sintaxe Gherkin)
═════════════════════════════════

FORMATO:
GIVEN [pré-condição/contexto]
WHEN [ação/gatilho]
THEN [resultado esperado]

EXEMPLO: Login de usuário
─────────────────────────────────────
GIVEN um usuário registrado na página de login
WHEN eles inserem credenciais válidas
THEN são redirecionados para o dashboard
AND veem uma mensagem de boas-vindas com seu nome

GIVEN um usuário na página de login
WHEN inserem uma senha inválida
THEN veem uma mensagem de erro "Credenciais inválidas"
AND o campo de senha é limpo
AND a tentativa de login é logada

GIVEN um usuário que já está logado
WHEN navegam para a página de login
THEN são redirecionados para o dashboard
─────────────────────────────────────

Formato checklist

FORMATO CHECKLIST
═════════════════

EXEMPLO: Feature de busca

Critérios de aceitação:
- [ ] Usuário pode inserir termos de busca na caixa de busca
- [ ] Busca executa quando usuário pressiona Enter ou clica Buscar
- [ ] Resultados exibem em 2 segundos
- [ ] Resultados mostram título, trecho e data para cada match
- [ ] Mensagem "Nenhum resultado encontrado" exibe quando sem matches
- [ ] Mínimo 2 caracteres requeridos para buscar
- [ ] Termos de busca são destacados nos resultados
- [ ] Usuário pode limpar busca e retornar à visualização padrão
- [ ] Busca funciona no mobile (responsiva)
- [ ] Histórico de busca não é salvo (privacidade)

Formato baseado em regras

FORMATO BASEADO EM REGRAS
═════════════════════════

EXEMPLO: Requisitos de senha

Regras:
1. Senha deve ter 8-64 caracteres
2. Deve conter pelo menos uma letra maiúscula
3. Deve conter pelo menos uma letra minúscula
4. Deve conter pelo menos um número
5. Deve conter pelo menos um caractere especial (!@#$%^&*)
6. Não pode conter espaços
7. Não pode corresponder a nenhuma das últimas 5 senhas
8. Não pode conter o nome de usuário
9. Medidor de força atualiza em tempo real
10. Mensagens de erro explicam qual regra falha

Escrevendo critérios de qualidade

Exemplos bons vs ruins

QUALIDADE DE CRITÉRIOS DE ACEITAÇÃO
══════════════════════════════════

RUIM (vago):
✗ "Usuário pode buscar"
✗ "Tornar rápido"
✗ "Lidar com erros adequadamente"
✗ "Deve funcionar no mobile"
✗ "Validar input"

BOM (específico e testável):
✓ "Usuário pode buscar inserindo texto e pressionando Enter"
✓ "Resultados de busca exibem em 2 segundos para até 10.000 registros"
✓ "Email inválido mostra erro: 'Por favor insira um email válido'"
✓ "Formulário é totalmente funcional em viewport de 320px"
✓ "Campo email aceita apenas formato válido (usuario@dominio.ext)"

Áreas de cobertura

O QUE COBRIR NOS CRITÉRIOS DE ACEITAÇÃO
══════════════════════════════════════

CAMINHO FELIZ:
├── Fluxo normal de sucesso
├── Comportamento esperado do usuário
└── Caso de uso principal

CASOS DE BORDA:
├── Estados vazios
├── Valores de limite
├── Inputs incomuns mas válidos
└── Ações concorrentes

CENÁRIOS DE ERRO:
├── Input inválido
├── Falhas de rede
├── Permissão negada
├── Tratamento de timeout
└── Erros de sistema

NÃO FUNCIONAL:
├── Requisitos de performance
├── Acessibilidade (nível WCAG)
├── Suporte navegador/dispositivo
├── Requisitos de segurança
└── Necessidades de localização

Template para histórias de usuário

HISTÓRIA DE USUÁRIO COM CRITÉRIOS DE ACEITAÇÃO
══════════════════════════════════════════════

HISTÓRIA:
Como [tipo de usuário]
Quero [ação/meta]
Para que [benefício/valor]

CRITÉRIOS DE ACEITAÇÃO:

Caminho Feliz:
- [ ] [Cenário principal de sucesso 1]
- [ ] [Cenário principal de sucesso 2]

Casos de Borda:
- [ ] [Caso de borda 1]
- [ ] [Caso de borda 2]

Tratamento de Erro:
- [ ] [Cenário de erro 1]
- [ ] [Cenário de erro 2]

Não Funcional:
- [ ] [Requisito de performance]
- [ ] [Requisito de acessibilidade]

Fora do Escopo:
- [Explicitamente o que NÃO está incluído]
- [Para prevenir aumento de escopo]

Exemplos do mundo real

Exemplo carrinho e-commerce

TAREFA: Funcionalidade adicionar ao carrinho

CRITÉRIOS DE ACEITAÇÃO:

Adicionando Itens:
- [ ] Usuário pode adicionar produto ao carrinho da página do produto
- [ ] Usuário pode especificar quantidade antes de adicionar (1-99)
- [ ] Ícone do carrinho mostra contagem atualizada imediatamente
- [ ] Confirmação "Adicionado ao carrinho" mostra por 3 segundos
- [ ] Produto com opções selecionadas (tamanho, cor) é adicionado

Comportamento do Carrinho:
- [ ] Adicionando mesmo produto aumenta quantidade (não duplica)
- [ ] Carrinho persiste entre sessões (usuários logados)
- [ ] Carrinho persiste por 30 dias (usuários convidados via cookie)

Casos de Borda:
- [ ] Adicionando mais que inventário disponível mostra mensagem de estoque
- [ ] Produtos fora de estoque mostram "Notifique-me" ao invés de "Adicionar"
- [ ] Tamanho máximo do carrinho é 50 itens únicos

Erros:
- [ ] Erro de rede mostra "Não foi possível adicionar. Tente novamente."
- [ ] Produto não mais disponível mostra mensagem apropriada

Performance:
- [ ] Adicionar ao carrinho completa em <500ms
- [ ] Carrinho atualiza sem reload de página

FORA DO ESCOPO:
- Funcionalidade wishlist (tarefa separada)
- Checkout de convidado (tratado na tarefa checkout)

Exemplo endpoint API

TAREFA: Criar endpoint de registro de usuário

CRITÉRIOS DE ACEITAÇÃO:

Request:
- [ ] POST /api/v1/users/register
- [ ] Aceita body JSON: email, password, name
- [ ] Content-Type: application/json

Validação:
- [ ] Email: formato válido, único no sistema
- [ ] Password: 8+ chars, maiúscula, minúscula, número
- [ ] Name: 2-100 caracteres, alfanumérico + espaços

Sucesso (201):
- [ ] Retorna user ID, email, name
- [ ] NÃO retorna password
- [ ] Cria usuário no banco com senha hashed
- [ ] Envia email de verificação
- [ ] Loga evento de registro

Erros:
- [ ] 400: Input inválido (com erros em nível de campo)
- [ ] 409: Email já existe
- [ ] 422: Validação falhou
- [ ] 429: Rate limited (5 tentativas por IP por minuto)

Segurança:
- [ ] Password nunca logada
- [ ] Usa bcrypt com cost factor 12
- [ ] HTTPS apenas
- [ ] CORS configurado para origens permitidas

Melhores práticas

Para escrever critérios

1. Seja específico — Números, mensagens exatas, comportamento preciso
2. Seja testável — Pode verificar passar/falhar objetivamente
3. Foque no quê, não no como — Requisitos, não implementação
4. Inclua casos negativos — O que NÃO deve acontecer
5. Defina "pronto" — Sem ambiguidade sobre conclusão

Refinamento colaborativo

PROCESSO DE REFINAMENTO
══════════════════════

1. RASCUNHO: Product owner escreve critérios iniciais
2. REVIEW: Equipe revisa na reunião de refinamento
3. CLARIFICAR: Desenvolvedores fazem perguntas esclarecedoras
4. EXPANDIR: Adicionar casos de borda e cenários de erro
5. CONFIRMAR: QA valida critérios são testáveis
6. FINALIZAR: Todos concordam critérios estão completos

PERGUNTAS A FAZER:
├── "O que acontece se...?"
├── "Há um máximo/mínimo?"
├── "Como lidamos com erros?"
├── "O que está explicitamente fora do escopo?"
└── "Como QA verificará isso?"

Anti-padrões

ERROS DE CRITÉRIOS DE ACEITAÇÃO:
✗ Muito vago ("deve funcionar bem")
✗ Muito detalhado (específicos de implementação)
✗ Faltando casos de erro
✗ Sem critérios de performance
✗ Não revisado por desenvolvedores
✗ Não revisado por QA
✗ Mudado no meio do sprint sem discussão
✗ Sem seção fora do escopo

Soluções relacionadas

• Criando definição de pronto efetiva
• Quebrando épicos em tarefas gerenciáveis
• Melhorando precisão de estimativa