Certa vez, uma equipe entrega um sistema de despesas que passa em todos os testes técnicos. No primeiro dia, a equipa financeira descobre que não consegue lidar com reclamações em várias moedas, que constituem uma grande parte do seu trabalho. Nada estava “quebrado”, mas não era utilizável. Os testes de aceitação do usuário existem para detectar exatamente esse tipo de lacuna antes do lançamento.

Este guia aborda como o UAT difere de outros testes, como executá-lo passo a passo e como decidir quando você está pronto para o lançamento. O cenário acima e os exemplos abaixo são ilustrativos e o processo deve ser dimensionado para se adequar ao seu projeto.

O que é UAT?

O UAT geralmente é a fase final de testes antes do lançamento, onde os usuários pretendidos confirmam que o software pode fazer seu trabalho em condições realistas. Também é chamado de teste de usuário final ou teste de aceitação. Ele ocorre após o desenvolvimento e testes do sistema, quando se espera que o produto esteja estável.

Seu objetivo não é encontrar todos os bugs. Nesta fase, a maioria deles já deve ter desaparecido. O objetivo é a validação: construímos a coisa certa? Os testadores verificam se o produto corresponde às especificações. O UAT valida se a especificação e o produto realmente atendem à necessidade.

Teste UAT vs controle de qualidade

O UAT não substitui outros testes. Se os usuários continuarem encontrando bugs básicos, a compilação não estava pronta e você está desperdiçando seu tempo limitado. Esses problemas pertencem aos níveis de teste anteriores e aos testes de regressão.

Quem dirige o UAT?

Escolha testadores que realmente façam o trabalho hoje. Um manipulador de sinistros experiente identificará problemas que um gerente ou procurador nunca detectaria. Inclua uma gama de experiências, porque um novo funcionário muitas vezes revela etapas confusas que um especialista contorna sem perceber. E certifique-se de que seus gerentes liberem tempo para isso, pois o UAT não terá sucesso mesmo com uma carga de trabalho completa.

Tipos de UAT

O processo UAT de sete etapas

1. Defina escopo e metas

Decida o que está sendo aceito, o que está fora do escopo e quais resultados de negócios são importantes. Por exemplo: “A equipe financeira pode enviar, aprovar e pagar um relatório de despesas em qualquer moeda suportada.”

2. Combine os critérios de aceitação

Escreva em linguagem simples como é o sucesso, de preferência no início do projeto, e não na semana anterior ao lançamento. Critérios vagos levam a discussões mais tarde.

3. Escolha e informe os testadores

Selecione usuários reais, explique o propósito, mostre-lhes como registrar feedback e deixe claro que eles estão testando o software em vez de serem eles próprios testados. Muitas pessoas se preocupam em fazer algo errado.

4. Prepare o ambiente e os dados

O ambiente UAT deve assemelhar-se tanto quanto possível à produção. Use dados realistas, configure as funções de usuário corretas e verifique integrações como e-mail. Se você copiar dados de produção, primeiro oculte as informações pessoais. Execute um smoke test rápido, para que os testadores não cheguem e encontrem uma compilação quebrada.

5. Escreva cenários

Baseie-os em fluxos de trabalho reais, em vez de botões individuais. Eles deveriam ser lidos como o trabalho, não como o software. Nosso guia para caso de teste versus cenário de teste explica quantos detalhes você precisa.

6. Execute os testes e colete feedback

Faça sessões com alguém disponível para ajudar. Reúna os problemas em um só lugar, com capturas de tela. Reserve também algum tempo para exploração livre, já que as pessoas tentam coisas que os scripts nunca antecipam. Testes exploratórios oferecem técnicas úteis para isso.

7. Corrija, teste novamente e aprove

Faça a triagem do feedback, corrija o que for importante e peça aos mesmos usuários que confirmem as correções. Em seguida, registre uma decisão formal.

Um caso de teste UAT

Um caso de teste UAT deve ser fácil de ser seguido por alguém não técnico. Aqui está um exemplo de sistema de despesas:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Observe que ele descreve uma tarefa real, não detalhes técnicos, e deixa espaço para comentários. Esses comentários frequentemente acabam sendo a parte mais valiosa, como “isso funciona, mas eu nunca encontraria aquele botão”.

Critérios de entrada e saída

Eles se enquadram no ciclo de vida de teste de software mais amplo. Defina os números com antecedência com suas partes interessadas. “Decidiremos quando parecer certo” tende a levar a um sim apressado, motivado pelo prazo.

Lidando com feedback

O feedback do UAT é uma mistura de coisas e nem tudo é um bug. Classifique-o em categorias:

Use regras claras sobre o que bloqueia uma liberação, conforme descrito em gravidade versus prioridade. E responda a cada item, incluindo aqueles que você recusa. As pessoas param de dar feedback se ele parece desaparecer. Nosso guia sobre como escrever um relatório de bug pode ajudar os testadores a descrever os problemas com clareza.

Lista de verificação do UAT

Antes do UAT

• O escopo e os critérios de aceitação são acordados por escrito
• Os testes de sistema e de regressão foram concluídos
• Os testadores são escolhidos, informados e recebem tempo
• Ambiente, contas e dados realistas estão prontos
• Os dados pessoais em cópias foram mascarados
• Os cenários são revisados pela empresa
• Um local para registrar problemas está configurado
• O proprietário da assinatura é nomeado

Durante o UAT

• Um contato de suporte está disponível
• Os problemas são triados todos os dias
• O progresso é compartilhado com as partes interessadas
• As correções são implantadas e testadas novamente de maneira controlada

Depois do UAT

• Os critérios de saída foram verificados
• Os problemas conhecidos são documentados, com os proprietários
• A aprovação formal é registrada
• As notas de treinamento e lançamento foram atualizadas
• Uma breve retrospectiva foi realizada

UAT em equipes ágeis

O UAT tradicional surge como uma grande fase no final, onde uma surpresa custa caro. As equipes ágeis encurtam esse ciclo. Os proprietários do produto analisam cada história em relação aos seus critérios de aceitação durante o sprint, e os usuários veem o software funcionando nas revisões do sprint. Muitas equipes ainda executam um UAT focado antes de um lançamento principal, principalmente quando vários recursos são combinados em um único fluxo de trabalho.

Com lançamentos frequentes, técnicas como sinalizadores de recursos e implantações canário permitem que usuários reais experimentem novos trabalhos gradualmente. Observe que estes complementam os testes de aceitação, mas não os substituem automaticamente, especialmente em setores regulamentados que precisam de um registro formal.

Erros comuns

• Tratar isso como uma formalidade. Uma aprovação sem uso real não protege ninguém.
• Usando testadores errados. Os desenvolvedores e o controle de qualidade têm muito conhecimento do sistema para representar os usuários.
• Começando com uma compilação instável. Os testadores perdem a confiança e o interesse rapidamente.
• Deixando para o último minuto. Assim, não há tempo para consertar o que você aprendeu.
• Uso de dados irrealistas. Os dados de teste raramente apresentam os casos complicados que o trabalho real apresenta.
• Deixar o escopo crescer. Trate novas ideias como solicitações de mudança, a menos que sejam verdadeiros bloqueadores.

Considerações finais

O UAT é sua última chance de saber, antes do lançamento, se o software realmente ajuda as pessoas que irão utilizá-lo. Planeje desde o início de um projeto, recrute usuários reais e chegue a um acordo sobre como será o sucesso. Para seu próximo lançamento, tente uma mudança simples: sente-se com um usuário durante um cenário real e não diga nada enquanto ele trabalha.

Perguntas frequentes

Continue aprendendo