9 min leitura • Guide 801 of 877
Escrever Critérios de Aceitação
Critérios de aceitação claros alinham expectativas. O GitScrum ajuda a rastrear a conclusão dos critérios e garante que nada seja perdido antes de uma história ser marcada como concluída.
Conceitos Básicos dos Critérios de Aceitação
Propósito
POR QUE OS CRITÉRIOS DE ACEITAÇÃO IMPORTAM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEM CRITÉRIOS CLAROS: │
│ ───────────────────── │
│ Desenvolvedor: "Acho que está pronto" │
│ PO: "Não é isso que eu quis dizer" │
│ Desenvolvedor: "De volta à prancheta..." │
│ → Retrabalho, frustração, atrasos │
│ │
│ COM CRITÉRIOS CLAROS: │
│ ───────────────────── │
│ Desenvolvedor: "Todos os critérios atendidos e verificados"│
│ PO: "Ótimo, vamos lançar" │
│ → Primeiro acerto, todos alinhados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CRITÉRIOS DE ACEITAÇÃO DEFINEM: │
│ ───────────────────────────────── │
│ │
│ LIMITES: │
│ O que está no escopo, o que não está │
│ "Redefinição de senha apenas por email (não SMS)" │
│ │
│ COMPORTAMENTO: │
│ Como a funcionalidade deve funcionar │
│ "Mostra erro se email não encontrado" │
│ │
│ CONDIÇÕES: │
│ Casos extremos e cenários especiais │
│ "Link expira após 24 horas" │
│ │
│ RESULTADOS MENSURÁVEIS: │
│ Performance, acessibilidade │
│ "Página carrega em menos de 2 segundos" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CRITÉRIOS BONS SÃO: │
│ ─────────────────── │
│ ✅ Testáveis (pode verificar sim/não) │
│ ✅ Claros (sem ambiguidades) │
│ ✅ Concisos (não um romance) │
│ ✅ Independentes (pode testar cada um) │
│ ✅ Focados no resultado (não na implementação) │
└─────────────────────────────────────────────────────────────┘
Formatos de Escrita
Dado-Quando-Então
FORMATO DADO-QUANDO-ENTÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUTURA: │
│ ─────────── │
│ DADO [pré-condição/contexto] │
│ QUANDO [ação/gatilho] │
│ ENTÃO [resultado esperado] │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLO: Redefinição de Senha │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HISTÓRIA: Como usuário, quero redefinir minha senha ││
│ │ ││
│ │ CRITÉRIOS DE ACEITAÇÃO: ││
│ │ ││
│ │ 1. DADO que estou na página de login ││
│ │ QUANDO clico em "Esqueci a senha" ││
│ │ ENTÃO vejo o formulário de redefinição de senha ││
│ │ ││
│ │ 2. DADO que inseri um email registrado ││
│ │ QUANDO envio a solicitação de redefinição ││
│ │ ENTÃO recebo um email de redefinição em 1 minuto ││
│ │ ││
│ │ 3. DADO que inseri um email não registrado ││
│ │ QUANDO envio a solicitação de redefinição ││
│ │ ENTÃO vejo "Nenhuma conta com este email" ││
│ │ ││
│ │ 4. DADO que clico no link de redefinição no email ││
│ │ QUANDO defino uma nova senha ││
│ │ ENTÃO posso fazer login com a nova senha ││
│ │ ││
│ │ 5. DADO que o link de redefinição tem mais de 24h ││
│ │ QUANDO clico no link ││
│ │ ENTÃO vejo "Link expirado, solicite nova redefinição"││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFÍCIOS: │
│ • Estruturado e consistente │
│ • Fácil converter para testes automatizados │
│ • Pré-condições claras │
└─────────────────────────────────────────────────────────────┘
Formato de Lista de Verificação
FORMATO DE LISTA DE VERIFICAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUTURA: │
│ ─────────── │
│ Lista simples de condições que devem ser verdadeiras │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLO: Página de Perfil do Usuário │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HISTÓRIA: Como usuário, quero ver meu perfil ││
│ │ ││
│ │ CRITÉRIOS DE ACEITAÇÃO: ││
│ │ ││
│ │ ☐ Perfil mostra nome, email e avatar ││
│ │ ☐ Avatar mostra iniciais se nenhuma imagem carregada ││
│ │ ☐ Botão editar visível apenas para próprio perfil ││
│ │ │ ☐ Data do último login exibida ││
│ │ ☐ Página carrega em menos de 2 segundos ││
│ │ ☐ Funciona em mobile (responsivo) ││
│ │ ☐ Acessível via navegação por teclado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFÍCIOS: │
│ • Rápido de escrever │
│ • Fácil revisar em demos │
│ • Verificação simples de aprovação/reprovação │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUANDO USAR QUAL: │
│ ────────────────── │
│ │
│ DADO-QUANDO-ENTÃO: │
│ • Interações complexas do usuário │
│ • Muitos casos extremos │
│ • Serão testes automatizados │
│ │
│ LISTA DE VERIFICAÇÃO: │
│ • Funcionalidades mais simples │
│ • Requisitos não funcionais │
│ • Verificação rápida necessária │
└─────────────────────────────────────────────────────────────┘
Padrões Comuns
Critérios por Tipo
PADRÕES DE CRITÉRIOS DE ACEITAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAMINHO FELIZ: │
│ ───────────── │
│ O cenário principal de sucesso │
│ "Quando usuário insere dados válidos, registro é criado" │
│ │
│ TRATAMENTO DE ERROS: │
│ ─────────────────── │
│ O que acontece quando as coisas dão errado │
│ "Quando email é inválido, mostra mensagem específica de erro"│
│ │
│ CASOS EXTREMOS: │
│ ────────────── │
│ Condições de limite │
│ "Quando 0 itens no carrinho, mostra mensagem de carrinho vazio"│
│ "Quando 100+ itens, mostra paginação" │
│ │
│ PERMISSÕES: │
│ ─────────── │
│ Quem pode fazer o quê │
│ "Apenas admin pode deletar usuários" │
│ "Usuários podem editar apenas seu próprio perfil" │
│ │
│ PERFORMANCE: │
│ ──────────── │
│ Requisitos de velocidade e escala │
│ "Busca retorna resultados em menos de 500ms" │
│ "Suporta 1000 usuários concorrentes" │
│ │
│ ACESSIBILIDADE: │
│ ────────────── │
│ Requisitos de design inclusivo │
│ "Todos os formulários navegáveis por teclado" │
│ "Imagens têm texto alternativo" │
│ │
│ SEGURANÇA: │
│ ────────── │
│ Requisitos de proteção │
│ "Senhas armazenadas com hash, não em texto puro" │
│ "Sessão expira após 30 min inativa" │
└─────────────────────────────────────────────────────────────┘
Exemplo Completo
HISTÓRIA ABRANGENTE COM AC:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HISTÓRIA-456: Checkout do Carrinho de Compras │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ COMO cliente ││
│ │ QUERO completar o checkout ││
│ │ PARA receber meu pedido ││
│ │ ││
│ │ ═══════════════════════════════════════════════════════ ││
│ │ ││
│ │ CRITÉRIOS DE ACEITAÇÃO: ││
│ │ ││
│ │ REVISÃO DO CARRINHO: ││
│ │ ☐ Mostra todos os itens com nome, preço, quantidade ││
│ │ ☐ Pode modificar quantidades (1-99) ││
│ │ ☐ Pode remover itens ││
│ │ ☐ Mostra subtotal, imposto e total ││
│ │ ││
│ │ ENTREGA: ││
│ │ ☐ Formulário de endereço valida campos obrigatórios ││
│ │ ☐ Código postal valida formato ││
│ │ ☐ Mostra opções de entrega com preços ││
│ │ ☐ Salva endereço para pedidos futuros (opt-in) ││
│ │ ││
│ │ PAGAMENTO: ││
│ │ ☐ Aceita Visa, Mastercard, Amex ││
│ │ ☐ Número do cartão valida com algoritmo Luhn ││
│ │ ☐ CVV obrigatório e oculto ││
│ │ ☐ Mostra ícone do tipo de cartão baseado no número ││
│ │ ││
│ │ CONFIRMAÇÃO: ││
│ │ DADO carrinho, entrega e pagamento válidos ││
│ │ QUANDO cliente clica em "Fazer Pedido" ││
│ │ ENTÃO pedido é criado e confirmação mostrada ││
│ │ E email de confirmação enviado em 1 minuto ││
│ │ ││
│ │ TRATAMENTO DE ERROS: ││
│ │ ☐ Falha no pagamento mostra "Pagamento recusado" ││
│ │ ☐ Pode tentar pagamento novamente sem re-inserir dados││
│ │ ☐ Itens fora de estoque bloqueados com mensagem ││
│ │ ││
│ │ NÃO FUNCIONAIS: ││
│ │ ☐ Fluxo de checkout completa em menos de 3 cliques ││
│ │ ☐ Funciona em dispositivos móveis ││
│ │ ☐ Carregamento da página em menos de 2 segundos ││
│ │ ││
│ │ FORA DO ESCOPO: ││
│ │ • PayPal (história separada) ││
│ │ • Cartões de presente (história separada) ││
│ │ • Múltiplos endereços de entrega ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Erros Comuns
Anti-padrões
ANTI-PADRÕES DE CRITÉRIOS DE ACEITAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MUITO VAGOS: │
│ ──────────── │
│ ❌ "O formulário deve ser amigável ao usuário" │
│ ❌ "Performance deve ser boa" │
│ ❌ "Tratar erros adequadamente" │
│ │
│ ✅ "Formulário tem validação inline" │
│ ✅ "Página carrega em menos de 2 segundos" │
│ ✅ "Email inválido mostra 'Insira email válido'" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DETALHES DE IMPLEMENTAÇÃO: │
│ ─────────────────────────── │
│ ❌ "Usar React para o frontend" │
│ ❌ "Armazenar no banco PostgreSQL" │
│ ❌ "Usar API REST com JSON" │
│ │
│ ✅ "Dados persistem após atualização da página" │
│ ✅ "API retorna resposta em menos de 200ms" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MUITOS: │
│ ────── │
│ ❌ 25 critérios de aceitação para uma história │
│ (história muito grande, divida) │
│ │
│ ✅ 3-8 critérios por história é típico │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MUITO POUCOS: │
│ ──────────── │
│ ❌ Nenhum critério ("vamos descobrir") │
│ ❌ Apenas caminho feliz coberto │
│ │
│ ✅ Cobrir caminho feliz + principais casos de erro │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NÃO TESTÁVEIS: │
│ ────────────── │
│ ❌ "Usuários devem gostar do novo design" │
│ ❌ "Sistema deve ser escalável" │
│ │
│ ✅ "Pesquisa de satisfação dos usuários pontua 4/5+" │
│ ✅ "Sistema lida com 1000 solicitações concorrentes" │
└─────────────────────────────────────────────────────────────┘