Testar grátis

Critérios de Aceitação

Critérios de aceitação definem as condições que devem ser cumpridas para uma user story ser considerada completa. Transformam requisitos vagos em especificações testáveis, eliminando ambiguidade e prevenindo scope creep.


Propósito

Critérios de aceitação servem múltiplos papéis:

Para developers: Requisitos claros antes de começar a codificar Para testers: Condições exatas a verificar Para stakeholders: Definição transparente de entregáveis Para product owners: Enforcement de fronteiras de scope

Sem critérios de aceitação, "pronto" torna-se subjetivo. Com eles, conclusão é binária—todos critérios passam ou trabalho continua.


Aceder ao Editor

Abra critérios de aceitação a partir dos detalhes da user story:

  1. Navegue para qualquer user story
  2. Clique no separador Detalhes
  3. Encontre a secção Critérios de Aceitação
  4. Clique no botão Editar (ícone de lápis)

O editor abre numa modal com opções de formatação de texto rico.


Funcionalidades do Editor

Barra de Formatação

O editor de critérios de aceitação suporta:

FerramentaPropósitoExemplo de Uso
NegritoEnfatizar termos chaveObrigatório: Utilizador deve estar autenticado
ItálicoTermos técnicos, notasDados guardados assincronamente
SublinhadoAvisos críticosNão deve eliminar sem confirmação
Cabeçalho 1Secções principais# Requisitos Funcionais
Cabeçalho 2Subsecções## Validação de Input
Lista ordenadaPassos sequenciais1. Clicar Submeter 2. Ver confirmação
Lista com bulletsItens não-sequenciais• Chrome • Firefox • Safari
Bloco de códigoSpecs técnicasstatus: 200
Linha horizontalSeparadores de secção---

Suporte de Texto Rico

O editor preserva formatação ao colar de:

  • Google Docs
  • Confluence
  • Notion
  • Microsoft Word

Cole conteúdo formatado diretamente—estrutura transfere automaticamente.


Escrever Critérios Eficazes

Formato Given-When-Then

Esta estrutura cria condições não-ambíguas e testáveis:

Dado [pré-condição]
Quando [ação]
Então [resultado esperado]

Exemplo:

Dado que estou logado como administrador
Quando clico "Eliminar Utilizador" e confirmo o diálogo
Então o utilizador é removido do sistema
E vejo uma notificação de sucesso
E o utilizador deixa de aparecer na lista de utilizadores

Formato de Checklist

Para validações mais simples, use checkboxes:

- [ ] Formulário valida formato de email
- [ ] Password requer 8+ caracteres
- [ ] Botão submeter desativado até formulário válido
- [ ] Mensagens de erro aparecem abaixo dos campos inválidos
- [ ] Sucesso redireciona para dashboard

Especificação por Exemplo

Mostre comportamento exato esperado:

Input: "joao@exemplo.com"
Esperado: Válido, proceder para próximo passo

Input: "joao@"
Esperado: Erro "Formato de email inválido"

Input: ""
Esperado: Erro "Email é obrigatório"

Categorias de Critérios

Critérios Funcionais

O que a funcionalidade deve fazer:

Dado um utilizador com itens no carrinho
Quando clica "Checkout"
Então vê o formulário de pagamento
E total do carrinho exibe corretamente
E opções de envio são calculadas

Critérios Não-Funcionais

Como a funcionalidade deve desempenhar:

Performance:
- Página carrega em menos de 2 segundos
- Pesquisa retorna resultados em menos de 500ms
- Suporta 100 utilizadores simultâneos

Acessibilidade:
- Todos campos de formulário têm labels
- Navegação por tab funciona corretamente
- Compatível com leitores de ecrã

Edge Cases

Condições de fronteira e estados de erro:

Edge cases tratados:
- Pesquisa vazia retorna mensagem útil
- Timeout de rede mostra opção de retry
- Expiração de sessão redireciona para login
- Dados inválidos mostram erros específicos

Critérios de Segurança

Requisitos de proteção:

Requisitos de segurança:
- Passwords hasheadas antes de armazenamento
- Sessão expira após 30 min de inatividade
- Logins falhados limitados a 5 tentativas
- Dados sensíveis não registados em logs

Anti-Padrões a Evitar

Demasiado Vago

Mau:

- Deve funcionar corretamente
- Deve ser rápido
- Precisa tratar erros

Bom:

- Retorna status 200 em input válido
- Responde em menos de 500ms em carga normal
- Mostra "Erro de rede, por favor retry" em timeout

Demasiado Técnico

Mau (a menos que equipa seja toda de developers):

- Usa Redis pub/sub para updates em tempo real
- Implementa optimistic locking com ETag
- Deploy via Kubernetes rolling update

Bom:

- Alterações aparecem para todos utilizadores em 3 segundos
- Edições simultâneas mostram aviso de conflito
- Deployment causa zero downtime

Testar a Implementação

Mau:

- Usa React hooks corretamente
- Queries de base de dados são otimizadas
- Código segue style guide

Bom:

- Componente re-renderiza apenas quando dados mudam
- Lista carrega em menos de 1 segundo para 10.000 itens
- Consistente com padrões de UI existentes

Scope Creep

Mau (adiciona trabalho não incluído na story):

- Também adicionar suporte dark mode
- Incluir exportação para PDF
- Adicionar atalhos de teclado

Bom (manter scope da story):

- Dashboard exibe todos widgets
- Widgets carregam configuração guardada do utilizador
- Layout persiste entre sessões

Integração com Workflow

Durante Planeamento

  1. Criação de story: Rascunhar critérios iniciais
  2. Refinement: Equipa discute, adiciona edge cases
  3. Estimativa: Critérios informam atribuição de story points
  4. Planeamento de sprint: Critérios verificam que story está pronta

Durante Desenvolvimento

  1. Referência: Developer verifica critérios enquanto codifica
  2. Auto-teste: Developer verifica cada critério antes de PR
  3. Code review: Revisor verifica cobertura de critérios

Durante Testes

  1. Criação de test case: Cada critério torna-se test case
  2. Verificação: Tester valida todos critérios
  3. Bug reports: Referenciam critérios específicos que falharam

Durante Demo

  1. Walkthrough: Mostrar cada critério sendo cumprido
  2. Sign-off: Stakeholder confirma aceitação

Atalhos de Teclado

No editor de critérios de aceitação:

AçãoAtalho
NegritoCmd/Ctrl + B
ItálicoCmd/Ctrl + I
SublinhadoCmd/Ctrl + U
GuardarCmd/Ctrl + Enter
CancelarEscape

Melhores Práticas

1. Escrever Critérios Antes do Desenvolvimento

Critérios escritos após codificação tendem a corresponder à implementação ao invés dos requisitos. Escreva primeiro, codifique depois.

2. Envolver a Equipa

Developers identificam gaps técnicos. Testers encontram edge cases. Inclua ambas perspetivas ao escrever critérios.

3. Manter Critérios Atómicos

Cada critério testa uma coisa:

Combinado:

Utilizador pode fazer login com credenciais corretas e vê dashboard com os seus dados

Atómico:

- Credenciais válidas concedem acesso
- Credenciais inválidas mostram erro
- Dashboard exibe após login
- Dashboard mostra apenas dados do utilizador

4. Usar Linguagem Consistente

Estabeleça convenções de equipa:

  • "Utilizador" vs "Cliente" vs "Membro"
  • "Clicar" vs "Selecionar" vs "Escolher"
  • "Exibir" vs "Mostrar" vs "Renderizar"

5. Incluir Casos Negativos

O que NÃO deve acontecer também importa:

- Password nunca é exibida em logs
- Dados eliminados não podem ser recuperados
- Sessão expirada não pode aceder rotas protegidas

6. Versionar Critérios

Quando requisitos mudam, atualize critérios e note porquê:

Atualizado 2024-01-15: Adicionado requisito 2FA por auditoria de segurança
Anterior: Login requer email + password
Atual: Login requer email + password + código 2FA

Templates Comuns

Operações CRUD

Create:
- Input válido cria registo
- Input inválido mostra erros específicos
- Prevenção de duplicados funciona

Read:
- Utilizadores autorizados veem dados
- Utilizadores não-autorizados veem erro
- Estado vazio mostra mensagem útil

Update:
- Alterações guardam corretamente
- Validação aplica-se a updates
- Tratamento de edição simultânea funciona

Delete:
- Confirmação obrigatória
- Soft delete preserva dados
- Hard delete remove completamente

Validação de Formulário

Campo: Email
- Obrigatório (mostra erro quando vazio)
- Validação de formato (utilizador@dominio.com)
- Comprimento máximo: 254 caracteres
- Verificação de unicidade (mostra erro se existe)

Campo: Password
- Obrigatório
- Mínimo 8 caracteres
- Pelo menos um número
- Pelo menos um caractere especial
- Indicador de força exibe

Endpoint de API

Endpoint: GET /api/users/{id}

Sucesso (200):
- Retorna objeto utilizador
- Exclui campos sensíveis (password, tokens)
- Tempo de resposta < 200ms

Não Encontrado (404):
- Retorna formato de erro standard
- Mensagem: "Utilizador não encontrado"

Não Autorizado (401):
- Token em falta retorna erro
- Token expirado retorna erro
- Token inválido retorna erro

Resolução de Problemas

Formatação não guarda:

  • Verifique consola do browser para erros
  • Tente limpar cache do browser
  • Garanta conexão de rede estável

Editor não abre:

  • Verifique permissão edituserstories
  • Verifique se story não está arquivada
  • Atualize página e tente novamente

Conteúdo colado perde formato:

  • Tente Colar e Igualar Estilo (Cmd/Ctrl + Shift + V)
  • Use formato Markdown para conteúdo complexo
  • Divida em operações de colagem menores

Alterações não visíveis para equipa:

  • Verifique que guardar completou (modal fechou)
  • Verifique erros de sincronização no feed de atividade
  • Membros de equipa podem precisar atualizar