O que Teste de Aceitação do Usuário (UAT) faz?
Framework de UAT ponta a ponta cobrindo geração de plano, execução, aprovação das partes interessadas e gates de liberação go/no-go. UAT é o último gate de qualidade antes da produção — trate-o como tal. Nenhum recurso é lançado sem a aprovação explícita das partes interessadas com base nos critérios de aceitação.
Pré-Processamento (Contexto Automático)
Antes de começar, colete o contexto do projeto silenciosamente:
- Leia
PORTFOLIO.mdse existir na raiz do projeto ou em diretórios pai para contexto do produto/equipe - Execute:
cat package.json 2>/dev/null || cat build.gradle.kts 2>/dev/null || cat Podfile 2>/dev/nullpara detectar a stack - Execute:
git log --oneline -5 2>/dev/nullpara alterações recentes - Execute:
ls src/ app/ lib/ functions/ 2>/dev/nullpara entender a estrutura do projeto - Use este contexto para adaptar toda a saída ao projeto real
Etapa 1: Classificar a Necessidade de UAT
Determine o tipo de UAT antes de construir o plano. O tipo define escopo, profundidade, envolvimento das partes interessadas e cronograma.
| Tipo de UAT | Gatilho | Escopo | Duração Típica |
|---|---|---|---|
| UAT de Novo Recurso | Desenvolvimento do recurso concluído, mesclado em staging | Todos os critérios de aceitação do PRD/histórias, caminho feliz completo + casos de borda | 2-5 dias úteis |
| UAT de Regressão | Refatoração importante, atualização de dependência ou migração de plataforma | Jornadas críticas do usuário reverificadas, sem regressões comportamentais | 1-3 dias úteis |
| UAT de Candidato a Release | Ramo de release cortado, todos os recursos integrados | Escopo completo da release — cada recurso, ponto de integração e comportamento multiplataforma | 3-5 dias úteis |
| Validação de Hotfix | Bug de produção corrigido, patch implantado em staging | Escopo restrito — verificar correção, confirmar sem efeitos colaterais em fluxos adjacentes | 2-4 horas |
Se o tipo de UAT não estiver claro, pergunte antes de prosseguir. Uma validação de hotfix e um UAT de candidato a release exigem planos fundamentalmente diferentes.
Coleta de Contexto Automatizada
Antes de criar o plano de UAT:
- Faça glob para especificações de teste existentes, arquivos PRD, documentos de critérios de aceitação
- Leia quaisquer especificações encontradas para extrair requisitos testáveis
- Faça grep para flags de recursos que controlam os recursos em teste
Geração de Artefatos (Obrigatório)
Gere usando Write:
- Plano de UAT:
docs/uat/uat-plan.md— usando estilo de saída de plano de teste - Casos de teste:
docs/uat/test-cases.md— casos de teste detalhados com etapas e resultados esperados - Formulário de aprovação:
docs/uat/sign-off.md— modelo de aprovação das partes interessadas - Modelo de triagem de bugs:
docs/uat/bug-triage.md— guia de classificação de gravidade
Etapa 2: Coletar Contexto
Colete todas as entradas antes de escrever o plano de UAT. Contexto ausente produz planos incompletos.
| Entrada | Obrigatório | Fonte | Notas |
|---|---|---|---|
| Nome do recurso / versão da release | Sim | PM/Líder Técnico | Identificador curto para rastreamento |
| Critérios de aceitação | Sim | PRD, histórias de usuário, tickets Jira/Linear | Use a saída da habilidade /sdlc se disponível |
| Lista de partes interessadas | Sim | PM/Product Owner | Quem testa, quem aprova, quem tem poder de veto |
| Ambiente alvo | Sim | Engenharia | URL de staging, número do build, flags de recurso |
| Plataforma(s) | Sim | Engenharia | Android, iOS, Web ou combinação |
| Requisitos de conformidade | Opcional | Jurídico/Segurança | Restrições de HIPAA, SOC 2, PCI-DSS, GDPR sobre dados de teste |
| Riscos ou limitações conhecidos | Opcional | Engenharia | Dívida técnica, problemas conhecidos, integrações incompletas |
| Resultados de UAT anteriores | Opcional | QA/PM | Linha de base para comparação de regressão |
| Prazo da release | Sim | PM | Data fixa vs. flexível — direciona a pressão do go/no-go |
Se os critérios de aceitação não existirem, pare e crie-os primeiro usando a habilidade /sdlc. UAT sem critérios de aceitação é teste baseado em opinião — não prova nada.
Etapa 3: Geração do Plano de UAT
3.1 Extração de Critérios de Aceitação
Extraia os critérios de aceitação de todas as fontes e normalize-os em declarações testáveis.
Formato: Dado [pré-condição], Quando [ação], Então [resultado esperado]
Prioridade da fonte:
1. Critérios de aceitação do PRD (autoritativos)
2. Critérios de aceitação da história de usuário (detalhados)
3. Especificações de design / protótipos (comportamento visual e de interação)
4. Contratos de API (formatos de resposta, códigos de erro)
5. Casos de borda identificados durante revisão de código ou /feature-audit
Cada critério de aceitação se torna um ou mais cenários de teste. Se um critério não puder ser testado manualmente, sinalize-o e especifique o método de verificação automatizada.
3.2 Matriz de Cenários de Teste
Construa a matriz completa de cenários. Cada cenário tem exatamente um resultado esperado.
| ID | Categoria | Cenário | Pré-condição | Etapas | Resultado Esperado | Plataforma | Prioridade |
|---|---|---|---|---|---|---|---|
| UAT-001 | Caminho Feliz | [Fluxo de sucesso primário] | [Estado de configuração] | [1. 2. 3.] | [Resultado esperado] | Todas | P0 |
| UAT-002 | Caminho Feliz | [Fluxo de sucesso secundário] | [Estado de configuração] | [1. 2. 3.] | [Resultado esperado] | Todas | P0 |
| UAT-003 | Caso de Borda | [Condição de limite] | [Estado de configuração] | [1. 2. 3.] | [Resultado esperado] | Todas | P1 |
| UAT-004 | Estado de Erro | [Entrada inválida / falha] | [Estado de configuração] | [1. 2. 3.] | [Tratamento de erro] | Todas | P1 |
| UAT-005 | Multiplataforma | [Comportamento específico da plataforma] | [Estado de configuração] | [1. 2. 3.] | [Expectativa da plataforma] | Específica | P1 |
| UAT-006 | Acessibilidade | [Leitor de tela / navegação por teclado] | [Tecnologia assistiva habilitada] | [1. 2. 3.] | [Resultado acessível] | Todas | P1 |
| UAT-007 | Performance | [Tempo de carregamento / responsividade] | [Condições padrão] | [1. 2. 3.] | [Dentro do orçamento] | Todas | P2 |
| UAT-008 | Offline/Degradado | [Sem conectividade / sinal ruim] | [Modo avião / limitado] | [1. 2. 3.] | [Tratamento gracioso] | Mobile | P1 |
Definições de prioridade:
- P0 — Funcionalidade principal. Se falhar, o recurso não funciona. Bloqueia a release.
- P1 — Comportamento importante. Se falhar, o recurso funciona, mas com lacunas significativas. Deve ser corrigido antes da release.
- P2 — Verificação interessante de se ter. Se falhar, pode ser lançado com o problema conhecido documentado.
3.3 Lista de Verificação do Ambiente
Verifique o ambiente de teste antes do UAT começar. Um ambiente quebrado desperdiça o tempo das partes interessadas e corrói a confiança.
LISTA DE VERIFICAÇÃO PRÉ-UAT DO AMBIENTE
[ ] Ambiente de staging implantado com o build/versão corretos
[ ] Versão do build documentada: _______________
[ ] Flags de recurso habilitadas para o escopo do UAT:
[ ] Flag: _____________ = LIGADO/DESLIGADO
[ ] Flag: _____________ = LIGADO/DESLIGADO
[ ] Dados de teste semeados (contas, conteúdo, transações)
[ ] Contas de teste criadas com funções/permissões necessárias
(veja a habilidade /test-accounts para provisionamento de contas)
[ ] Integrações de terceiros em modo teste/sandbox:
[ ] Stripe: modo de teste com chaves de API de teste
[ ] Processador de pagamento: ambiente sandbox
[ ] E-mail/SMS: interceptados ou usando destinatários de teste
[ ] Analytics: propriedade de dev/staging (não produção)
[ ] Backend/API apontando para staging (não produção)
[ ] Banco de dados semeado com volume de dados representativo
[ ] Notificações push configuradas para staging
[ ] Deep links / Universal Links configurados para o domínio de staging
[ ] Certificados SSL válidos em staging
[ ] Acesso VPN/rede configurado para todos os testadores
3.4 Tabela de Funções das Partes Interessadas
Defina quem faz o quê. Ambiguidade em funções significa lacunas na cobertura.
| Função | Pessoa | Responsabilidades | Autoridade de Aprovação |
|---|---|---|---|
| Líder de UAT | [Nome] | Possui o plano de UAT, coordena sessões, tria bugs, produz relatório | Recomendação final go/no-go |
| Product Owner | [Nome] | Valida se os critérios de aceitação foram atendidos, testa cenários de lógica de negócios | Sim — aprovação de negócios |
| Líder de Design | [Nome] | Valida fidelidade visual, padrões de interação, consistência da marca | Sim — aprovação de design |
| Líder de Engenharia | [Nome] | Disponível para investigação de bugs, correções de ambiente, explica restrições técnicas | Sim — aprovação técnica |
| Testador de QA | [Nome] | Executa cenários de teste sistematicamente, documenta descobertas com evidências | Não — reporta ao Líder de UAT |
| Especialista de Domínio | [Nome] | Testa fluxos de trabalho específicos do domínio (finanças, saúde, jurídico) | Sim — aprovação de domínio |
| Testador de Acessibilidade | [Nome] | Teste de leitor de tela, navegação por teclado, verificação WCAG AA | Consultivo — escalona para o Líder de UAT |
A aprovação mínima viável requer: Product Owner + Líder de Engenharia. Todas as outras aprovações são recomendadas, mas dependentes do escopo.
Etapa 4: Estrutura de Execução do UAT
Consulte reference/details.md (seção “Step 4: UAT Execution Framework”) para obter detalhes completos.
Etapa 5: Aprovação e Gate Go/No-Go
5.1 Matriz de Decisão Go/No-Go
A decisão go/no-go é baseada em dados, não em opinião. Pontue cada critério e calcule o resultado ponderado.
MATRIZ DE DECISÃO GO / NO-GO
Recurso/Release: _______________
Data: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────────────┬────────┬────────┬───────┬───────┐
│ Critério │ Peso │ Status │ Pontuação │ Notas │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ Todos os cenários P0 passam │ 30% │ GO/NOGO│ X/30 │ │
│ Todos os cenários P1 passam │ 25% │ GO/NOGO│ X/25 │ │
│ Nenhum bug P0 aberto │ 20% │ GO/NOGO│ X/20 │ │
│ Nenhum bug P1 aberto (ou risco aceito)│ 10% │ GO/NOGO│ X/10 │ │
│ Aprovação de acessibilidade (WCAG AA)│ 5% │ GO/NOGO│ X/5 │ │
│ Performance dentro do orçamento │ 5% │ GO/NOGO│ X/5 │ │
│ Paridade multiplataforma verificada│ 5% │ GO/NOGO│ X/5 │ │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ TOTAL │ 100% │ │ X/100 │ │
└──────────────────────────────────┴────────┴────────┴───────┴───────┘
Limiares de decisão:
GO >= 90/100 Todos os critérios P0 devem ser GO.
CONDICIONAL 70-89/100 Lançar com condições documentadas e cronograma para resolução.
NO-GO < 70/100 Não liberar. Corrigir e testar novamente.
Bloqueadores rígidos (NO-GO automático independentemente da pontuação):
- Qualquer bug P0 aberto
- Cenário de perda ou corrupção de dados
- Vulnerabilidade de segurança (bypass de autenticação, exposição de dados)
- Crash em jornada crítica do usuário
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 Modelo de Aprovação
APROVAÇÃO DAS PARTES INTERESSADAS
Recurso/Release: _______________
Build/Versão: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────┬──────────────┬──────────┬────────────┬─────────┐
│ Parte Interessada│ Função │ Decisão │ Condições │ Data │
├──────────────────┼──────────────┼──────────┼────────────┼─────────┤
│ [Nome] │ Product Owner│ GO/NOGO │ [se houver]│ [data] │
│ [Nome] │ Líder de Eng.│ GO/NOGO │ [se houver]│ [data] │
│ [Nome] │ Líder de Design│ GO/NOGO │ [se houver]│ [data] │
│ [Nome] │ Especialista │ GO/NOGO │ [se houver]│ [data] │
│ [Nome] │ Líder de UAT │ GO/NOGO │ [se houver]│ [data] │
└──────────────────┴──────────────┴──────────┴────────────┴─────────┘
Aprovação condicional significa: "GO, desde que o seguinte seja resolvido até [data]:"
1. [Condição]
2. [Condição]
Se QUALQUER parte interessada assinar NO-GO, a release fica bloqueada até que sua preocupação seja resolvida.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.3 Plano de Rollback
Toda release deve ter um plano de rollback documentado antes da decisão go/no-go. Sem plano de rollback = NO-GO automático.
PLANO DE ROLLBACK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Gatilho: [Condições que acionam o rollback — ex.: taxa de crash > 2%, bug P0 em produção]
Responsável:[Quem inicia o rollback]
Etapas:
1. [Desabilitar flag do recurso / reverter implantação]
2. [Verificar se o rollback foi bem-sucedido]
3. [Notificar partes interessadas]
4. [Monitorar por 30 minutos após o rollback]
Dados: [Alguma migração de dados precisa ser revertida? Versionamento de documentos Firestore?]
Comunicação:[Quem comunica aos usuários, se necessário — equipe de suporte, página de status]
Pós-mortem: [Agendar dentro de 48 horas após o rollback]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 Rascunho de Notas de Release
Gere notas de release a partir das descobertas do UAT. Os testadores de UAT conhecem o recurso melhor do que qualquer um neste ponto.
NOTAS DE RELEASE (a partir das descobertas do UAT)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Versão: _______________
Data: _______________
NOVO
- [Recurso/capacidade adicionada — linguagem voltada ao usuário]
MELHORADO
- [Melhoria em recurso existente — o que está melhor para o usuário]
CORRIGIDO
- [Bug corrigido durante o UAT — o que estava quebrado e agora está resolvido]
PROBLEMAS CONHECIDOS
- [Bugs P2 sendo lançados com esta release — solução alternativa, se disponível]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Etapa 6: Relatório de UAT
Produza o relatório completo de UAT após todas as sessões serem concluídas e a aprovação coletada.
═══════════════════════════════════════════════════════════════
RELATÓRIO DE UAT
Recurso/Release: [NOME]
Versão/Build: [VERSÃO]
Data: [HOJE]
Líder de UAT: [NOME]
═══════════════════════════════════════════════════════════════
SUMÁRIO EXECUTIVO
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Decisão: GO / CONDICIONAL / NO-GO
Total de Cenários: [N]
Aprovados: [N] ([X]%)
Falhos: [N] ([X]%)
Bloqueados: [N] ([X]%)
Não Executados:[N] ([X]%)
Bloqueadores Abertos: [N] P0 / [N] P1 / [N] P2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TAXA DE APROVAÇÃO POR CATEGORIA
┌──────────────────────┬──────────┬────────┬─────────┬────────┐
│ Categoria │ Total │ Aprovados│ Falhos │ Taxa │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
│ Caminho Feliz │ [N] │ [N] │ [N] │ [X]% │
│ Casos de Borda │ [N] │ [N] │ [N] │ [X]% │
│ Estados de Erro │ [N] │ [N] │ [N] │ [X]% │
│ Multiplataforma │ [N] │ [N] │ [N] │ [X]% │
│ Acessibilidade │ [N] │ [N] │ [N] │ [X]% │
│ Performance │ [N] │ [N] │ [N] │ [X]% │
│ Offline/Conectividade│ [N] │ [N] │ [N] │ [X]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
[truncado para tradução]