Por que a UAT Falha Mesmo Quando Parece Bem-Sucedida
Em muitas rodadas de UAT (User Acceptance Testing), todos os cenários são marcados como aprovados e, duas semanas após o lançamento, dezenas de chamados são abertos. Isso não é um paradoxo. É um resultado direto de testes construídos em torno de telas.
Um teste focado em telas pergunta "É possível criar um registro?". Um teste focado em processos pergunta "Um agente pode receber um chamado, identificar que o cliente existe sob outro nome, verificar sua elegibilidade no sistema principal, abrir um caso, encaminhá-lo a outra parte e fechá-lo — mesmo com o cliente duplicado no sistema?". O segundo cenário encontra o que o primeiro perde.
Este guia apresenta a estrutura de UAT que visa a segunda pergunta. A relação com outras fases do projeto é detalhada no Guia de Implementação do Salesforce.
O Que Deve Estar Pronto Antes de Começar
- Um ambiente estável que não receba implantações no meio da rodada, exceto para correções de bloqueadores aprovadas.
- Dados de teste com escopo e complexidade semelhantes aos de produção.
- Usuários com permissões reais — não Admin para todos. Metade das falhas de permissão são descobertas apenas quando o testador possui o perfil correto.
- Critérios de aceitação definidos para cada processo central.
- Um mecanismo de relatório único para bugs, com campos obrigatórios mínimos.
O item mais frequentemente ignorado é o terceiro, e é ele que gera os bugs mais embaraçosos no dia do lançamento.
Como Construir um Cenário que Encontra Problemas
Um bom cenário começa com uma persona e um estado inicial, não com um clique. Uma estrutura eficaz:
- Quem — Função e permissão exatas.
- Estado inicial — Quais informações existem no sistema antes do início do cenário.
- O que acontece — O evento de negócio que aciona o processo.
- O que o testador faz — Em nível de ação de negócio, não em nível de clique.
- Resultado esperado — Incluindo o que aconteceu em outros sistemas.
- O que não deveria acontecer — O registro não é exposto a quem não deveria, a notificação não é enviada duas vezes.
O sexto item é o que separa uma lista de verificação de um teste profissional.
Seis Famílias de Cenários Que Devem Ser Incluídas
| Família | Exemplo de Cenário | O Que Ela Revela |
|---|---|---|
| Fluxo Padrão | Um processo completo de ponta a ponta | Se o processo é sequer executável |
| Exceção de Negócio | Cancelamento, crédito, retorno a uma etapa anterior | Lógica construída apenas em uma direção |
| Dados Problemáticos | Cliente duplicado, nome em hebraico e inglês, campo vazio | Mapeamento e limpeza insuficientes |
| Permissões | Usuário tentando acessar registro de outra unidade | Falhas no modelo de exposição |
| Falha de Integração | Sistema de destino indisponível | Tratamento de erros, loops, duplicação |
| Volume | Ação em massa em grande número de registros | Limitações de desempenho e automação |
A ausência de uma família inteira na lista é um sinal de que o teste fornecerá uma segurança enganosa.
Classificação de Gravidade — A Condição Para Gerenciar a Rodada
Sem uma classificação acordada, todo bug parece urgente e a decisão de ir ao ar se torna uma discussão. Um modelo de quatro níveis é suficiente:
| Nível | Definição | Impacto no Lançamento |
|---|---|---|
| Bloqueador | Processo central não pode ser concluído, sem workaround | Bloqueia |
| Grave | O processo é possível com um workaround pesado ou dados incorretos são salvos | Bloqueia, a menos que aprovado explicitamente |
| Médio | Inconveniente significativo, workaround razoável | Não bloqueia, entra no plano de correção |
| Baixo | Texto, ordem de campos, melhoria | Coletado para a próxima onda |
A regra importante: a classificação é definida pelo proprietário do processo junto com a equipe técnica, e não por quem relatou o bug.
Condições para o Go-Live
Elas são definidas antes do início da rodada, e não no final:
- Zero bugs bloqueadores abertos.
- Todo bug grave foi fechado ou aprovado por escrito com workaround e tempo de correção.
- Todos os processos centrais foram executados na segunda rodada sem novas falhas.
- Os proprietários do processo aprovaram por escrito.
- Existe um plano de contingência testado, não apenas escrito.
Exemplo Ilustrativo: Fundo de Pensão
O cenário é hipotético e serve para ilustração. Um fundo de pensão testou o processo de tratamento de chamados de participantes. A primeira rodada de UAT foi quase totalmente aprovada. A equipe notou que todos os testadores usaram um perfil ampliado, pois a atribuição dos perfis exatos estava atrasada.
Na segunda rodada, com os perfis reais, foram encontrados onze bugs: agentes não viam registros de participantes transferidos entre planos, um botão de aprovação de exceção aparecia para quem não era qualificado, e um relatório de carga retornou resultados parciais para líderes de equipe. Nenhum dos bugs estava relacionado à funcionalidade testada na primeira rodada — todos estavam no modelo de exposição.
A conclusão prática adotada lá: não se inicia uma rodada de UAT antes que todos os participantes estejam com o perfil que usarão em produção.
Erros Gerenciais Que Encarecem a Rodada
- Implantação de versões no meio da rodada, o que invalida os testes já realizados.
- Testadores que relatam via WhatsApp e e-mail em paralelo ao sistema de rastreamento.
- Cenários escritos no nível do clique, o que transforma cada mudança na interface em uma atualização de documentação.
- Encurtar a segunda rodada devido à pressão do cronograma — esta é a rodada que descobre regressões.
Esses padrões aparecem ao lado de outras falhas no Guia de Erros Comuns de Implementação de CRM, e a responsabilidade por cada um deles é definida no Guia de Funções da Equipe de Projeto Salesforce.
Ao Substituir um Sistema Existente
Em um projeto de substituição, o UAT assume uma segunda função: comparação. Os mesmos dez cenários são executados em ambos os sistemas, e os resultados são comparados campo por campo. Esta é a ferramenta mais eficaz para descobrir lacunas de mapeamento antes que se tornem lacunas de confiança. A ordem das operações em tal transição é detalhada no Guia de Substituição de CRM pelo Salesforce.
O Que Resta Após a Rodada
Os cenários de UAT não são um documento único. Eles são a base para os testes de regressão em cada lançamento futuro e a melhor fonte para materiais de treinamento — pois são escritos na linguagem do processo, e não na linguagem do sistema. Mantê-los em um formato que possa ser executado novamente é o investimento mais barato que se pode fazer para o próximo ano.