Testes de aceitação (UAT): quando quem decide não é o testador

Uma equipe entrega um módulo de faturamento. Os testes unitários passam, a integração passa, o end-to-end passa. Verde por toda parte. Fazem o deploy numa sexta-feira. Na segunda a contadora abre, dá três cliques e diz: "isto não me serve, não é assim que faturamos". Ninguém escreveu uma única linha de código ruim. E mesmo assim o software falhou.

Esse vazio tem nome. Chama-se aceitação. E o teste que o cobre, o UAT (User Acceptance Testing, teste de aceitação do usuário), é o que mais se pula, mais se improvisa e pior se entende de toda a cadeia de qualidade. A resposta curta: o UAT não verifica se o software está bem construído, verifica se é o software correto para quem vai usá-lo. São duas perguntas distintas e quase ninguém as separa.

01 · o que éA aceitação responde a outra pergunta

Há uma frase antiga na qualidade de software que resume tudo: a verificação pergunta "construímos o produto bem?" e a validação pergunta "construímos o produto correto?". O UAT vive do lado da validação. Não lhe importa se o algoritmo é elegante nem se a cobertura chega a noventa por cento. Importa-lhe uma só coisa: se a pessoa que pediu isto consegue fazer o seu trabalho com aquilo que você entregou.

O padrão de testing ISTQB coloca a aceitação como o último dos quatro níveis de teste, depois dos de componente, integração e sistema. E marca uma diferença que na prática é ignorada: os níveis anteriores são executados pela equipe técnica contra especificações técnicas. A aceitação é executada, ou aprovada, por quem vai conviver com o produto. O testador prepara o terreno. Quem decide não é o testador.

Verde em toda a suíte significa que o código faz o que dissemos. Não significa que dissemos o correto.

Isto não é um tecnicismo. É a razão pela qual um software impecável pode ser um fracasso. A contadora do exemplo não encontrou um bug. Encontrou uma funcionalidade que resolve um problema que ela não tem, e que não resolve o que ela de fato tem. Nenhum nível técnico de teste teria capturado isso, porque todos partem da mesma especificação equivocada.

02 · o erro"Eu gosto" não é um critério

Aqui está o pecado original de quase todo UAT. Convoca-se um usuário, senta-se ele diante do sistema e pede-se que "verifique se está bom". O usuário navega um tempo, faz o que lhe ocorre, e ao final emite um veredicto: "gosto" ou "não me convence". Isso não é um teste de aceitação. É uma pesquisa de opinião disfarçada.

O problema de "eu gosto" é que não é repetível, não é discutível e não é responsabilidade de ninguém. Se o usuário tem um bom dia, aprova. Se tem um mau dia, rejeita. E quando em produção aparece um problema, ninguém consegue apontar o que exatamente foi aceito, porque nunca foi escrito. A aceitação virou um estado de ânimo.

A alternativa tem um nome que soa burocrático mas salva projetos: critérios de aceitação. São condições concretas, verificáveis e acordadas antes de construir, que definem o que significa algo estar terminado e ser aceitável. Não "a fatura fica bem", mas "uma fatura com três itens, dois com IVA e um isento, calcula o total correto e o mostra em pesos com duas casas decimais". Isso pode ser testado. Isso passa ou não passa. Isso não depende do humor.

Há um formato que ajuda a não divagar, popularizado pelo desenvolvimento guiado por comportamento: dado um contexto, quando ocorre uma ação, então se espera um resultado. "Dado um cliente sem limite de crédito, quando tenta faturar a crédito, então o sistema o bloqueia e mostra a mensagem X." Não é preciso a cerimônia completa. É preciso a disciplina de escrever o resultado esperado antes, não de improvisá-lo olhando para a tela.

Critério mensurável: passa ou não passa. Gosto pessoal: depende de quem e de quando. Só um dos dois pode ser assinado.

03 · como se fazAceitação que se pode assinar

Um UAT saudável tem três momentos, e nenhum deles é "o usuário brinca um pouco". O primeiro ocorre antes de escrever código: acordam-se os critérios de aceitação com quem vai decidir. Se o negócio não consegue dizer de antemão o que o faria aceitar, a equipe está construindo às cegas e o UAT só vai descobrir o desacordo tarde e caro.

O segundo momento é a execução. O usuário, ou o QA acompanhando o usuário, percorre casos reais de negócio contra esses critérios já escritos. Não casos técnicos de borda: casos que a pessoa vive de verdade. A contadora fatura o tipo de fatura que fatura todos os dias, com os dados estranhos que ela conhece e a equipe não. Esse conhecimento do domínio é justamente o que o UAT aporta e nenhum outro nível de teste tem.

O terceiro momento é o veredicto, e este é o que quase ninguém formaliza. A aceitação termina com uma decisão rastreável: aceita-se, aceita-se com ressalvas listadas, ou rejeita-se com motivos concretos ligados a critérios. Essa decisão tem um dono com nome. Em muitos marcos contratuais isto é literalmente um teste de aceitação de contrato: o que for assinado define se o fornecedor cumpriu. Não é um detalhe de processo. É onde o risco muda de mãos.

04 · onde encaixaO UAT não substitui o QA, o fecha

Um mal-entendido frequente: acreditar que se há UAT, o testing técnico sobra, ou vice-versa. Os dois testam coisas distintas. Os testes unitários, de integração e de sistema garantem que o produto está bem construído. A aceitação garante que é o produto correto. Pular os primeiros leva você a um produto correto cheio de defeitos. Pular o segundo, a um produto impecável que ninguém queria.

Por isso o UAT é a última porta, não a única. Chega quando o técnico já está verde, e mesmo assim pode dizer que não. Esse "não" no final é incômodo, mas é mais barato que o do cliente em produção.

Uma só ideia para levar: a aceitação não se mede em cobertura, mede-se em decisões que alguém pode assinar. No dia em que o seu UAT produzir um documento onde um responsável diz "aceito estes critérios e rejeito estes outros, por estas razões", você deixou de fazer teatro e começou a fazer aceitação. E na segunda de manhã, quando a contadora abrir o módulo, você já saberá a resposta antes de ela falar.