6 min leitura • Guide 294 of 877
Escrevendo Critérios de Aceitação Claros
Critérios de aceitação definem quando uma user story está completa. Critérios claros previnem conversas de "Eu pensei que significava...", reduzem retrabalho e ajudam testadores a saber o que verificar. Bons critérios de aceitação são específicos, testáveis e acordados antes do desenvolvimento começar.
Formatos de Critérios
| Formato | Melhor Para | Exemplo |
|---|---|---|
| Dado-Quando-Então | Cenários de comportamento | Fluxos de login |
| Checklist | Features simples | Campos de formulário |
| Regras | Restrições | Validação |
Dado-Quando-Então
Formato de Cenário
FORMATO DADO-QUANDO-ENTÃO
═════════════════════════
ESTRUTURA:
─────────────────────────────────────
DADO: Estado inicial/contexto
QUANDO: Ação tomada
ENTÃO: Resultado esperado
EXEMPLO - LOGIN:
─────────────────────────────────────
Story: Como usuário, quero fazer login
para acessar minha conta.
Critérios:
DADO um usuário registrado
QUANDO ele insere email e senha válidos
ENTÃO ele está logado e vê o dashboard
DADO um usuário registrado
QUANDO ele insere senha errada
ENTÃO ele vê erro "Credenciais inválidas"
E permanece na página de login
DADO um usuário registrado
QUANDO ele insere senha errada 5 vezes
ENTÃO sua conta é bloqueada por 15 minutos
E ele vê mensagem de bloqueio
DADO um usuário na página de login
QUANDO ele clica "Esqueci senha"
ENTÃO ele vê formulário de reset de senha
BENEFÍCIOS:
─────────────────────────────────────
├── Focado em comportamento
├── Fácil converter para testes
├── Cobre happy e sad paths
├── Causa e efeito claros
├── Reduz ambiguidade
└── QA pode automatizar diretamente
Escrevendo Bons Cenários
MELHORES PRÁTICAS DE CENÁRIO
════════════════════════════
RESULTADOS ESPECÍFICOS:
─────────────────────────────────────
❌ Vago:
ENTÃO o usuário é notificado
✅ Específico:
ENTÃO usuário vê toast: "Pagamento bem-sucedido"
E email de confirmação é enviado
E pedido aparece no histórico de pedidos
COBRINDO EDGE CASES:
─────────────────────────────────────
Não escreva apenas happy path.
Pergunte: O que pode dar errado?
├── Input inválido
├── Estado vazio
├── Erro de rede
├── Permissão negada
├── Acesso concorrente
├── Valores limite
└── Cada um merece cenário
EXEMPLO - UPLOAD DE ARQUIVO:
─────────────────────────────────────
Happy path:
DADO usuário na página de upload
QUANDO ele seleciona PDF válido menor que 10MB
ENTÃO arquivo faz upload com sucesso
E nome aparece na lista
Edge cases:
DADO usuário seleciona arquivo maior que 10MB
QUANDO clica upload
ENTÃO vê erro "Arquivo muito grande"
E upload não prossegue
DADO usuário seleciona arquivo .exe
QUANDO clica upload
ENTÃO vê erro "Tipo de arquivo inválido"
DADO upload está em progresso
QUANDO rede desconecta
ENTÃO vê "Upload falhou. Tentar novamente?"
E pode tentar sem reselecionar arquivo
Formato Checklist
Quando Usar Checklist
CRITÉRIOS COMO CHECKLIST
════════════════════════
MELHOR PARA:
─────────────────────────────────────
├── Features simples
├── Requisitos UI
├── Campos de formulário
├── Validações básicas
└── Quando cenários são overkill
EXEMPLO - FORMULÁRIO DE CONTATO:
─────────────────────────────────────
Story: Formulário de contato na landing page
Critérios:
☐ Formulário tem campos: Nome, Email, Mensagem
☐ Todos campos são obrigatórios
☐ Email deve ser formato válido
☐ Mensagem tem mínimo 10 caracteres
☐ Botão "Enviar" envia dados
☐ Após envio, mostra "Mensagem enviada"
☐ Dados vão para email@empresa.com
☐ Formulário limpa após envio
SIMPLES E CLARO:
─────────────────────────────────────
├── Fácil de verificar ✓/✗
├── Rápido de escrever
├── Não prescreve implementação
├── Testável item por item
└── Útil para aceite
QUANDO MIGRAR PARA DADO-QUANDO-ENTÃO:
─────────────────────────────────────
├── Comportamento condicional
├── Múltiplos fluxos
├── Lógica complexa
├── Estados dependentes
└── Quando checklist fica longa demais
Combinando Formatos
USANDO AMBOS FORMATOS
═════════════════════
STORY COMPLEXA - MIX:
─────────────────────────────────────
Story: Sistema de pagamento
CHECKLIST (requisitos básicos):
☐ Aceita Visa, Mastercard, Amex
☐ Mostra ícones de cartões aceitos
☐ Campo CVV mascara input
☐ Botão desabilitado até form válido
CENÁRIOS (comportamentos):
DADO carrinho com R$100
QUANDO pagamento é aprovado
ENTÃO pedido é criado
E email de confirmação é enviado
E estoque é decrementado
DADO cartão com saldo insuficiente
QUANDO pagamento é tentado
ENTÃO mostra "Pagamento recusado"
E pedido não é criado
E usuário pode tentar outro cartão
REGRAS (restrições de negócio):
├── Parcelas: 2x-12x sem juros
├── Valor mínimo por parcela: R$50
├── Timeout de transação: 30 segundos
└── Retry automático: 1 vez
Anti-Patterns
Critérios Ruins
O QUE EVITAR
════════════
MUITO VAGOS:
─────────────────────────────────────
❌ "Sistema deve ser rápido"
❌ "Interface deve ser bonita"
❌ "Usuário consegue fazer X"
❌ "Funciona corretamente"
↓ Não é possível testar
MUITO TÉCNICOS:
─────────────────────────────────────
❌ "Usar React Query para cache"
❌ "Implementar com padrão Repository"
❌ "Banco deve ser PostgreSQL"
↓ Prescreve implementação
MUITO DETALHADOS:
─────────────────────────────────────
❌ Lista de 50 itens
❌ Especifica pixel por pixel
❌ Dita cada mensagem de erro
↓ Tira flexibilidade do time
FALTANDO EDGE CASES:
─────────────────────────────────────
❌ Só happy path
❌ Ignora erros
❌ Não considera estados vazios
↓ Surpresas na produção
Critérios Corrigidos
ANTES E DEPOIS
══════════════
ANTES (ruim):
─────────────────────────────────────
"Usuário pode pesquisar"
DEPOIS (bom):
─────────────────────────────────────
DADO usuário na página de produtos
QUANDO digita "sapato" na busca
ENTÃO vê lista de produtos com "sapato"
E resultados mostram foto, nome, preço
E ordenados por relevância
DADO nenhum produto encontrado
QUANDO busca por "xyz123"
ENTÃO vê mensagem "Nenhum resultado"
E sugestões de busca aparecem
DADO busca com menos de 3 caracteres
QUANDO usuário digita "sa"
ENTÃO busca não é executada
E tooltip mostra "Digite ao menos 3 letras"
ANTES (ruim):
─────────────────────────────────────
"Performance deve ser boa"
DEPOIS (bom):
─────────────────────────────────────
├── Página carrega em < 2s (3G)
├── Busca retorna em < 500ms
├── Paginação em < 300ms
├── LCP < 2.5s
└── Métricas em 90th percentile
Processo de Escrita
FLUXO DE CRIAÇÃO DE CRITÉRIOS
═════════════════════════════
PASSO 1: PO RASCUNHA
─────────────────────────────────────
├── Baseado em requisitos
├── Happy path primeiro
├── Linguagem de negócio
└── Não precisa ser perfeito
PASSO 2: REFINAMENTO COM TIME
─────────────────────────────────────
├── Dev pergunta edge cases
├── QA pergunta testabilidade
├── Designer confirma UX
├── Todos entendem igual?
└── Adiciona cenários faltantes
PASSO 3: FINALIZAÇÃO
─────────────────────────────────────
├── Critérios no GitScrum
├── Aceitos por todos
├── Prontos para desenvolvimento
└── QA já pode planejar testes
PASSO 4: DURANTE DEV
─────────────────────────────────────
├── Descobriu edge case novo?
├── Adiciona critério
├── Comunica PO
└── Critérios evoluem
PASSO 5: ACEITE
─────────────────────────────────────
├── QA verifica cada critério
├── PO confirma comportamento
├── Critérios = Definition of Done
└── Story completa ✅