Funcionou na UAT. Por Que Falhou em Produção?

“Mas a gente testou” é o começo da investigação, não o fim

Segunda de manhã.

Uma mensagem aparece no grupo do projeto:

“Clientes não conseguem cancelar alguns pedidos. Isso funcionava na UAT. O que mudou?”

O QA diz:

“A gente testou o cancelamento. Passou.”

O Desenvolvimento diz:

“O mesmo código foi para produção.”

A Operação diz:

“Clientes reais ainda estão sendo afetados.”

Todo mundo pode estar dizendo a verdade.

É isso que torna esse tipo de incidente confuso.

A funcionalidade pode passar na UAT e ainda assim falhar em produção — não porque a UAT foi inútil, mas porque a produção raramente é só a UAT com mais usuários.

Ela tem dado, integrações, permissões, configuração, timing e volume diferentes.

Mesmo código não significa o mesmo sistema.

Vamos investigar um incidente juntos.

Aqui está o requisito

Uma empresa indiana de e-commerce introduz o cancelamento de pedido self-service.

O requisito diz:

Um cliente pode cancelar um pedido até ele ter sido despachado.

O time constrói a funcionalidade.

Na UAT, o QA testa pedidos com esses status:

• PLACED → cancelamento permitido
• READY_TO_PACK → cancelamento permitido
• DISPATCHED → cancelamento bloqueado

Tudo passa.

A funcionalidade vai ao ar.

Depois um cliente tenta cancelar um pedido de tênis de ₹2.499. O pedido não foi despachado, mas o botão Cancelar pedido está faltando.

Então o que aconteceu?

Primeiro, entenda o que a UAT realmente provou

A UAT provou que a funcionalidade se comportou como esperado:

• com o dado usado na UAT
• contra as integrações da UAT
• sob a configuração da UAT
• com os papéis de usuário testados
• para os cenários que o time sabia testar

Isso importa.

Mas não provou que a produção enviaria o mesmo dado pelo mesmo caminho sob as mesmas condições.

A UAT testa o comportamento esperado num mundo controlado. A produção introduz o mundo que você não controlou totalmente.

Isso não torna isso automaticamente uma falha de teste.

Significa que a investigação deveria começar pelas diferenças, não pela culpa.

Antes da investigação: proteja o cliente

Se a falha está causando perda financeira, expondo dado, bloqueando trabalho crítico ou afetando muitos usuários, a contenção vem primeiro.

O time pode precisar desativar a funcionalidade, pausar o processamento, fazer rollback da release ou oferecer um workaround temporário.

O BA pode ajudar a estabelecer:

• quem é afetado
• quais produtos, regiões e canais estão envolvidos
• se dinheiro, dado, compliance ou compromissos com o cliente estão em risco
• que comportamento é seguro até a causa ser entendida

Preserve a evidência, mas não mantenha uma funcionalidade prejudicial rodando só para facilitar a investigação.

Passo 1: Preserve o exemplo com falha

Antes que alguém atualize dado, tente de novo a transação ou mude a configuração, capture uma falha real.

Para o nosso pedido, registre:

• ID do pedido
• cliente e tipo de conta
• data e hora exata
• canal: web, Android, iOS ou API
• status mostrado ao cliente
• status recebido do sistema de armazém
• comportamento esperado
• comportamento real
• screenshot ou mensagem de erro
• versão da release e configuração

Não comece com:

“O cancelamento está quebrado.”

Comece com:

“Para o pedido IN-48217, às 10:42 no horário da Índia, o cliente não conseguiu cancelar pelo app Android mesmo com o pedido ainda não despachado.”

Agora o time tem algo que consegue rastrear.

Sem um exemplo específico, cada time investiga um problema ligeiramente diferente.

Passo 2: Siga a transação — não as opiniões

O cliente não vê nenhum botão de cancelamento.

Isso não significa que a tela é o problema.

O botão pode depender de uma decisão tomada vários sistemas antes.

Para o pedido IN-48217, o time rastreia o caminho:

1. O app pede os detalhes mais recentes do pedido.
2. O serviço de pedidos recupera o status de atendimento.
3. O sistema de armazém retorna ALLOCATED.
4. A regra de cancelamento checa se esse status é cancelável.
5. ALLOCATED não está na lista de status permitidos.
6. O serviço retorna canCancel: false.
7. O app esconde o botão.

A tela se comportou corretamente com base na resposta que recebeu.

A primeira diferença significativa apareceu antes: o armazém de produção retornou um status que ninguém tinha usado na UAT.

Não pergunte só onde a falha ficou visível. Pergunte onde o comportamento primeiro ficou diferente.

Passo 3: Compare a UAT e a produção lado a lado

“Os ambientes são iguais” não é evidência.

Construa uma pequena tabela de comparação.

Isso muda a conversa.

O time não está mais debatendo se “o mesmo código” foi implantado.

Está olhando as condições ao redor desse código — porque o código é só uma parte do comportamento.

Passo 4: Cheque os sete lugares onde a produção costuma diferir

Você não precisa inspecionar tudo aleatoriamente. Percorra sete áreas.

1. Dado

Procure valores que nunca apareceram na UAT, campos faltando, registros históricos, duplicatas e formatos inesperados. No nosso exemplo, ALLOCATED existia em produção, mas não no conjunto de teste da UAT.

2. Integrações

A UAT pode usar um stub, simulador ou sistema downstream simplificado. Compare versões de API, campos, mapeamentos, autenticação, timeouts e retries. Aqui, o stub retornava três status limpos; o armazém real retornava mais.

3. Configuração e feature flags

O código pode ser idêntico enquanto as configurações mudam seu comportamento. Compare valores de regra de negócio, limites, configurações de país ou produto, feature flags e regras de roteamento.

4. Papéis e permissões de usuário

Uma funcionalidade testada com uma conta de administrador pode se comportar de forma diferente para um cliente real, usuário de operações ou funcionário de agência.

Cheque tanto o que o usuário consegue ver quanto o que a conta de serviço consegue acessar.

5. Timing

Algumas falhas só existem num momento específico: uma rodada de batch, cache desatualizado, horário de corte, conversão de fuso horário, problema de ordem de eventos ou atualização concorrente.

Um pagamento indiano processado às 23:58 no horário da Índia e um pagamento internacional processado perto de uma mudança de horário de verão podem expor suposições de timing que a UAT comum durante o dia nunca tocou.

6. Volume e concorrência

Uma transação de teste limpa não é o mesmo que milhares de clientes agindo juntos.

A produção pode introduzir filas, travamento, mensagens atrasadas, eventos duplicados ou timeouts.

7. Deploy

Confirme a versão da aplicação, scripts de banco de dados, configuração, dado de referência, jobs agendados e releases dependentes que realmente chegaram em produção.

“Foi incluído na release” e “está ativo em produção” nem sempre são a mesma afirmação.

Passo 5: Volte para o requisito

Agora releia a frase original:

Um cliente pode cancelar um pedido até ele ter sido despachado.

Parece claro.

Mas o sistema não implementou a palavra despachado. Implementou uma lista de status considerados como “não despachado.”

Essa lista não incluía ALLOCATED.

Essa é a lacuna escondida:

Essas afirmações pareciam equivalentes na UAT.

A produção revelou que não eram.

A pergunta que faltou foi:

“Quais são todos os status que um pedido pode ter antes do despacho — incluindo status retornados só pelo armazém real?”

Às vezes a produção não invalida o requisito.

Ela revela uma suposição escondida dentro dele.

Passo 6: Classifique o problema corretamente

Nem toda divergência de produção é simplesmente “um bug.”

Classifique para que a ação certa venha a seguir.

Para o nosso incidente, a falha imediata é um mapeamento de status faltando.

Mas o problema mais profundo é compartilhado:

• o requisito não enumerou os estados de atendimento
• o stub da UAT não representava o conjunto real de status
• o pacote de teste não incluía ALLOCATED

Chamar isso de só um “bug de UI” corrigiria o sintoma e preservaria as condições que o criaram.

Um incidente pode ter várias causas contribuintes. A classificação existe para melhorar a correção, não para atribuir a culpa a um time só.

Passo 7: Corrija a regra, o teste e o ambiente

O time decide que ALLOCATED ainda significa “não despachado.”

Então ele:

1. adiciona ALLOCATED ao mapeamento de cancelável
2. confirma a decisão com os donos de atendimento e atendimento ao cliente
3. atualiza a documentação da regra de negócio
4. adiciona o status ao dado de teste da UAT
5. substitui o conjunto de respostas do stub simplificado pela lista completa de status de produção
6. adiciona monitoramento para status de atendimento desconhecidos
7. reteste o cancelamento nos canais web, Android, iOS e API

Agora a correção faz mais do que restaurar um botão faltando.

Ela torna essa classe de falha mais fácil de prevenir e detectar.

O mesmo padrão aparece em toda indústria

Os substantivos mudam. A investigação não.

• Bancos: a UAT testa contas ACTIVE e BLOCKED. A produção envia PENDING_REVIEW.
• Seguros: a UAT contém uma apólice por cliente. A produção contém clientes migrados com apólices sobrepostas.
• Saúde: a UAT usa IDs de prestador atuais. A produção ainda contém registros referenciando IDs aposentados.
• E-commerce internacional: a UAT testa uma moeda e um armazém. A produção adiciona moedas, regras fiscais, parceiros de atendimento e fusos horários.
• Capital markets: a UAT testa operações limpas no horário de mercado. A produção introduz eventos tardios, emendas, múltiplas praças e confirmações assíncronas.

Em cada caso, a pergunta útil não é:

“Quem deixou passar isso?”

É:

“Que condição de produção o nosso modelo de UAT falhou em representar?”

O que o BA deveria realmente fazer?

O BA não precisa ler cada log ou diagnosticar o código sozinho.

O trabalho do BA é manter a investigação conectada ao comportamento de negócio.

Isso significa:

• transformar “está quebrado” num exemplo rastreável
• declarar claramente o comportamento esperado e real
• comparar as condições de UAT e produção
• identificar o primeiro ponto de divergência
• reunir os donos certos de negócio e técnicos
• expor regras e suposições faltando
• registrar a decisão
• garantir que o requisito e os testes de regressão sejam atualizados

O Desenvolvimento pode localizar a falha técnica.

O QA pode reproduzir.

A Operação pode fornecer a evidência de produção.

O BA ajuda o time a concordar sobre o que o sistema deveria ter feito — e garante que a resposta sobreviva além da chamada de incidente.

Oito perguntas para fazer durante o incidente

1. Qual transação exata falhou?
2. O que o usuário esperava, e o que aconteceu em vez disso?
3. O problema está limitado a certos usuários, produtos, regiões ou canais?
4. Esse cenário exato foi testado na UAT?
5. A UAT usou os mesmos valores, mapeamentos e integrações?
6. Onde a transação primeiro se comportou de forma diferente?
7. Isso é um defeito, uma regra faltando ou um cenário novo?
8. O que mais depende da mesma regra ou valor de dado?

Checklist de Investigação de UAT para Produção

Copie isso para o Jira, Confluence ou suas notas de incidente.

Antes da próxima release

Você não consegue tornar a UAT idêntica à produção.

Você consegue torná-la mais representativa.

Isso não significa copiar dado sensível de cliente, paciente ou financeiro para a UAT. Use dado mascarado ou sintético que preserve os status, formatos, relacionamentos e casos extremos importantes.

Antes da release, pergunte:

1. Quais valores de produção não existem na UAT?
2. Quais integrações ou configurações diferem?
3. Quais papéis, canais, regiões e casos extremos continuam sem teste?
4. Como o sistema vai sinalizar um valor desconhecido em vez de tratá-lo mal silenciosamente?

Essa última pergunta é especialmente útil.

Se o serviço de cancelamento tivesse sinalizado ALLOCATED como um status desconhecido, o time poderia ter encontrado a lacuna antes de um cliente encontrar.

O que fica

Quando algo funciona na UAT e falha em produção, resista às explicações mais rápidas:

“O QA deixou passar.”

“O Desenvolvimento implantou o código errado.”

“O dado de produção está ruim.”

Qualquer uma dessas pode eventualmente ser verdade.

Mas comece pela evidência.

Preserve uma falha. Rastreie a transação. Compare os ambientes. Encontre a primeira diferença. Volte para a regra de negócio.

Porque a UAT e a produção geralmente discordam por um motivo.

Encontre o primeiro lugar onde as histórias delas pararam de ser as mesmas.

A UAT não mentiu. Ela respondeu a pergunta que você fez. A produção expôs a pergunta que você esqueceu de fazer.