O Que Exatamente um BA Deveria Checar Antes da UAT Começar?

UAT agendada não é a mesma coisa que UAT pronta

O calendário diz que a UAT começa amanhã.

Os casos de teste estão escritos.

Os usuários de negócio bloquearam a agenda.

Todo mundo diz:

“A gente está pronto.”

Segunda de manhã chega.

O primeiro testador faz login. A conta dele não funciona.

Outro testador descobre que o cliente de teste não existe.

A API aponta para o serviço errado.

Uma feature flag ainda está desligada.

Na hora do almoço, ninguém está testando o requisito.

Estão testando se a configuração de teste funciona.

Essa é a diferença entre:

UAT agendada

e

UAT pronta.

Primeiro: o que a UAT realmente prova?

User Acceptance Testing não é mais uma rodada de teste do desenvolvedor.

Ela responde uma pergunta de negócio:

“Essa solução sustenta a necessidade de negócio real o suficiente para a gente aceitá-la?”

Isso precisa de mais do que um build funcionando.

Você precisa do escopo certo, dos cenários certos, do dado certo, do ambiente certo, dos usuários certos, das integrações certas e da configuração certa.

Se um desses estiver errado, a UAT pode te contar a história errada.

Aqui está a situação

Imagine um banco lançando um novo fluxo de verificação de beneficiário.

O requisito diz:

Transferências acima de ₹2 lakh para um beneficiário novo exigem verificação adicional.

O desenvolvimento está completo. O teste de sistema passou. A UAT começa amanhã.

Antes de dizer “pode ir,” o que o BA deveria checar?

1. Escopo & Build — estamos testando a coisa certa?

Comece pelo requisito. Pergunte:

• O que exatamente está no escopo da UAT e o que está explicitamente fora?
• Quais stories ou requisitos estão incluídos?
• Mudanças tardias estão refletidas e o build implantado realmente as contém?
• As limitações conhecidas estão documentadas?

Imagine que o QA testou a versão 4.8, mas a UAT recebe a 4.7 por acidente. Toda falha depois disso cria ruído.

Antes da UAT: confirme que o escopo do requisito e o build implantado batem.

2. Casos de Teste — estamos testando o negócio, não só o fluxo principal?

Bons cenários de UAT representam como as pessoas realmente usam o sistema.

No nosso exemplo de transferência, não teste só:

Beneficiário novo + ₹3 lakh → verificação aparece.

Teste também:

• Fronteira: exatamente ₹2 lakh.
• Abaixo do limite: ₹1,99,999.
• Beneficiário existente: a verificação deveria se aplicar?
• Falha: serviço de verificação indisponível.
• Retry: o usuário falha na verificação e tenta de novo.
• Permissões: o usuário certo consegue realizar a ação?
• Ponta a ponta: a transferência continua corretamente depois?

Uma pergunta útil de BA:

“O que faria o negócio recusar aceitar essa funcionalidade?”

Transforme esses riscos em cenários.

3. Dado de Teste — esses cenários realmente conseguem ser executados?

Esse é um dos maiores assassinos de UAT. O cenário existe. O dado não.

Mapeie os cenários importantes para o dado que eles exigem:

• Beneficiário novo → cliente sem beneficiário anterior
• Acima do limite → conta com saldo suficiente
• Beneficiário existente → cliente com um beneficiário salvo
• Verificação falhada → identidade de teste que dispara falha
• Checagem de permissão → usuário com papel restrito

E verifique se o dado realmente funciona. Não:

“Alguém disse que estava carregado.”

Valide de verdade. Use dado mascarado ou sintético aprovado onde for exigido.

4. Ambiente — está estável o suficiente para confiar no resultado?

Um ambiente ruim pode fazer uma boa funcionalidade parecer quebrada.

Para o fluxo de verificação de beneficiário, isso significa confirmar que o build da UAT realmente bate com a release que o QA aprovou — não um build dois commits atrás dela. Significa checar que o endpoint de UAT do serviço de verificação chama o motor de regras de verdade, não um stub que sempre retorna “verificado” independente do valor. E significa confirmar que a atualização de dado de ontem à noite não apagou silenciosamente as contas de cliente das quais os casos de teste dependem.

De forma mais geral, verifique:

• Build correto implantado, ambiente acessível, banco de dados disponível
• Serviços necessários rodando, nenhuma queda bloqueante conhecida
• Dado de teste atualizado corretamente, URLs e endpoints corretos
• Nenhuma mudança não coordenada acontecendo durante os testes críticos

O ambiente não precisa ser perfeito. Precisa ser estável o suficiente para que:

a falha signifique alguma coisa — não que a transferência de ₹2 lakh falhou porque o ambiente resetou durante a noite.

5. Acesso & Papéis — os testadores realmente conseguem testar?

Os testadores desse fluxo são gerentes de relacionamento de agência e equipe de operações — não desenvolvedores. Nunca presuma:

“Eles tinham acesso da última vez.”

Antes do Dia 1, verifique se as contas de UAT deles realmente conseguem originar uma transferência acima de ₹2 lakh — não só visualizar uma — se o fluxo de maker-checker está configurado para esse valor e se o papel deles inclui a permissão específica ligada a esse passo novo. De forma mais geral:

• Os usuários estão criados e conseguem fazer login?
• Os papéis e permissões estão corretos?
• Eles conseguem acessar os sistemas dependentes?
• O MFA/VPN está funcionando e as regras de segregação de funções são respeitadas?

Oito gerentes de relacionamento descobrindo que o login deles não consegue originar uma transferência durante a chamada de UAT não é teste.

É troubleshooting.

6. Integrações — a jornada inteira consegue terminar?

Sua funcionalidade pode funcionar perfeitamente. Mas a UAT geralmente testa uma jornada.

Para o fluxo de verificação de beneficiário, essa jornada é assim:

Início da Transferência → API de Verificação → Ledger do Core Bancário → Triagem de Fraude/Risco → Gateway de SMS/Notificação

Se o gateway de SMS na UAT for um mock que nunca dispara de verdade, um testador pode “passar” num cenário que deixaria um cliente real esperando por um OTP que nunca chega.

Pergunte:

“Que outro sistema precisa funcionar para esse cenário terminar?”

Verifique as dependências upstream e downstream críticas antes de os testadores chegarem.

7. Configuração — a UAT reflete a configuração de negócio pretendida?

A configuração pode invalidar silenciosamente um teste que, de resto, seria perfeito.

Suponha que o requisito diga verificação acima de ₹2 lakh, mas a UAT esteja configurada para ₹5 lakh. O código pode estar perfeito. O teste ainda vai contar a história errada. O mesmo vale para uma feature flag ainda desligada, um limite de retry de OTP configurado diferente da produção ou um limite de conta NRI que nunca foi atualizado para bater com a regra nova.

De forma mais geral, verifique:

• Feature flags, limites, regras de negócio
• Configuração de produto, dado de referência, roteamento
• Moedas/países, datas/calendários, direitos do usuário

8. Stakeholders — todo mundo sabe como a UAT vai funcionar?

A Tecnologia pode estar pronta enquanto a UAT ainda falha operacionalmente.

Para esse fluxo especificamente, o líder de operações de agência, o responsável por fraude e risco, o release manager e o BA todos precisam concordar, antes do Dia 1, sobre como é um cenário aprovado, quem levanta um defeito se uma transferência real de ₹2 lakh pular a verificação por engano e quem tem autoridade para chamar um No-Go se o serviço de verificação não se mostrar confiável o suficiente. De forma mais geral, todo mundo deveria saber:

• O que estamos testando e quem está testando o quê?
• Onde os resultados são registrados e como os defeitos são levantados?
• Quem os triagem e o que conta como bloqueador?
• Quem decide a aceitação?

Identifique também o caminho de suporte: engenharia, QA, BA, suporte de ambiente, suporte de dados e times de integração.

Você não precisa de todo mundo em toda reunião.

Você precisa saber para quem ligar quando algo quebrar.

Não pergunte se está pronto. Pergunte o que prova isso.

É aqui que o BA consegue fazer uma diferença grande.

Em vez de:

“O ambiente está pronto?”

procure evidência:

• Login testado.
• Build verificado.
• Endpoint checado.
• Dado de teste validado.
• Cenário crítico executado.

“Alguém confirmou” é garantia. “Alguém demonstrou” é evidência.

Um hábito útil de BA:

Não pergunte se algo está pronto. Pergunte o que prova que está pronto.

Defina a saída antes de entrar

Uma pergunta que os times costumam deixar tarde demais:

“Como é uma UAT bem-sucedida?”

Combine isso antes de o teste começar. Os critérios de saída podem incluir:

• Cenários críticos de negócio executados
• Nenhum defeito de Severidade 1 em aberto
• Tratamento acordado para os defeitos restantes
• Aprovação de negócio necessária obtida
• Evidência armazenada, limitações conhecidas aceitas

As regras exatas variam por organização. Mas se ninguém sabe o que “UAT completa” significa, a aprovação final vira uma discussão no final.

O que o BA deveria assumir pessoalmente?

O BA não deveria virar:

engenheiro de ambiente + engenheiro de dado de teste + administrador de acesso + líder de QA + release manager

Esse não é o trabalho. O papel do BA é tornar a prontidão visível.

Você pode não provisionar o ambiente. Mas deveria saber se ele está pronto.

Você pode não criar contas de usuário. Mas deveria saber se os testadores conseguem fazer login.

Você pode não configurar a API. Mas deveria saber se a jornada de negócio consegue rodar.

Pense:

coordenar, verificar, expor lacunas.

Não:

fazer tudo pessoalmente.

Rode uma checagem de prontidão para UAT

Antes da UAT, reúna as pessoas-chave para uma revisão de prontidão curta. Percorra Escopo & Build, Cenários, Dado, Ambiente, Acesso, Integrações, Configuração, Usuários de negócio, Caminho de suporte e Critérios de saída.

Não transforme isso numa reunião de status de duas horas.

Você está tentando responder uma pergunta:

“O que poderia impedir um teste significativo amanhã?”

Encontre isso hoje.

Go / Conditional Go / No-Go

A prontidão não precisa sempre ser binária.

Adiar a UAT em um dia pode sair mais barato do que desperdiçar o dia de dez pessoas fingindo testar.

Antes de dizer “Começar a UAT”

Se várias respostas forem:

“A gente acha que sim.”

vocês provavelmente não estão prontos.

O que fica

Uma boa UAT não começa porque o calendário diz:

Dia 1

Ela começa quando os usuários de negócio conseguem executar cenários significativos e confiar no que os resultados estão dizendo.

Então, antes de perguntar:

“Os usuários de negócio estão prontos para testar?”

pergunte:

“A gente tornou possível para eles testarem direito?”

Esse é o trabalho do BA aqui.

Não consertar pessoalmente todo ambiente, conta, API ou dataset.

Tornar a prontidão visível antes de essas lacunas desperdiçarem o tempo de todo mundo.

A UAT não está pronta porque o plano de teste existe. Ela está pronta quando o negócio consegue testar a coisa certa, com o dado certo, nas condições certas — e o time tem evidência para provar isso.