O que são testes de aceitação do utilizador? A última verificação antes de alguém depender deles

Os testes de aceitação do utilizador são o momento em que as pessoas que vão mesmo usar o software decidem se ele faz o trabalho delas. Não se funciona - isso já foi testado - mas se faz aquilo que pediram, de uma forma com que consigam viver.

É a única fase de testes cujo propósito é uma decisão e não uma lista de defeitos. A aceitação acaba com alguém a dizer sim ou não a uma entrega.

O que os distingue de qualquer outro teste

Todas as fases anteriores perguntam se o software corresponde à sua especificação. A aceitação pergunta se a especificação estava certa.

Essa distinção parece académica até a vermos acontecer. Uma funcionalidade pode passar todos os testes funcionais, cumprir cada critério de aceitação tal como está escrito, e ainda assim ser recusada na aceitação porque a pessoa que faz aquele trabalho trezentas vezes por semana vê que lhe vai custar quatro cliques onde a forma antiga pedia um. Não há nada partido. O requisito é que estava errado, e este é o último momento barato para o descobrir.

Testes de QA

O software faz o que dissemos que faria? Executados por testers, contra a especificação

Testes de aceitação do utilizador

Faz o que o negócio precisa? Executados por quem tem esse trabalho, contra a realidade

Quem os faz, e quem não devia

As pessoas que o vão usar. Nem a equipa de desenvolvimento, nem o QA, nem um responsável a substituí-las.

Isso é mais difícil do que parece. As pessoas que quer estão ocupadas a fazer o trabalho para o qual o software existe, e o tempo delas é a parte mais cara de todo o exercício. É por isso que uma aceitação planeada em cima da hora acaba entregue a quem estiver livre, e uma entrega passa a ser aprovada por alguém que nunca fez o trabalho que ela serve.

Dois papéis que vale a pena nomear: alguém a quem pertence a decisão e que pode dizer que não, e alguém que recolhe o que os testers encontram e o transforma em algo sobre o qual um programador possa agir. Sem o primeiro, a aceitação produz opiniões e nenhum desfecho. Sem o segundo, produz uma folha de cálculo com que ninguém consegue trabalhar.

O que se deve dar aos testers

Não uma lista de funcionalidades. Uma lista das coisas que costumam fazer.

1. Levar um cliente novo do pedido de informação até à primeira fatura
2. Processar um reembolso de uma encomenda paga com cartão
3. Fechar o mês com duas filiais a reportar em separado
4. Corrigir uma morada numa encomenda que já foi expedida

Isto são processos de negócio, e cada um atravessa várias funcionalidades. Um tester a quem se diz “verifique o ecrã das faturas” vai verificar o ecrã das faturas; um tester a quem se diz “leve um cliente novo até à primeira fatura” encontra os dois sítios onde o processo parte entre ecrãs, e é aí que vivem os problemas a sério.

Dê-lhes dados reais, ou a cópia segura mais próxima disso. Uma aceitação sobre uma base de dados com Cliente de Teste 1 a 20 não encontra nenhum dos problemas que um cliente chamado “O’Brien & Sons (anteriormente Smith)” encontra logo.

Quando é que estão terminados

Antes de começarem, combinem o que quer dizer “sim”. Por escrito, e em termos que alguém possa verificar.

• Que processos têm de funcionar, e quais podem ser incómodos
• O que conta como bloqueante, por oposição ao que se corrige na entrega seguinte
• Quem assina, e o que está a assinar
• Quanto tempo dura. Uma aceitação sem data de fim não acaba; esbate-se

A falha mais comum não é um teste mau, é um fim pouco claro. Uma fase que dura até as pessoas pararem de reportar coisas acaba quando elas se fartam, e uma entrega que sai por cansaço é uma entrega com que ninguém concordou.

Os relatos que a aceitação produz

Esta é a parte para que as equipas de desenvolvimento se preparam, e a razão é estrutural em vez de culpa de alguém.

Os seus testers não são testers. São contabilistas, despachantes, enfermeiros, comerciais - e descrevem o que aconteceu na linguagem do seu ofício em vez da linguagem do software. “A fatura foi para a filial errada” é uma frase perfeitamente clara e não é reproduzível. Falta-lhe qual fatura, qual filial, o que estava no ecrã e o que esperavam em vez disso.

Duas coisas ajudam mais do que tudo o resto:

Peça o processo, não o diagnóstico. “O que estava a fazer, e o que esperava que acontecesse?” leva-o mais longe do que qualquer formulário, porque o palpite de um utilizador de negócio sobre a causa costuma estar errado e costuma substituir os factos.

Tire-lhes a parte técnica das mãos. A ninguém numa aceitação se devia pedir uma versão de navegador, um registo da consola, ou passos escritos para um programador. Acertar nisso é para o que servem as ferramentas, e quanto menos pedir a um tester mais ele reporta.

Quem recolhe os relatos ainda tem de transformar cada um em algo sobre o qual um programador possa agir, e o guia de relatórios de erro é a forma que isso toma. Se uma descoberta da aceitação não puder ser reproduzida, será fechada por resolver por muito real que fosse.

A versão curta

A aceitação pergunta se o software faz o trabalho, e quem decide são as pessoas de quem é esse trabalho. Dê-lhes processos em vez de ecrãs, dados reais em vez de linhas de teste, uma definição combinada de sim, e os menos trabalhos de casa técnicos que conseguir. O que voltar vai estar dito na linguagem deles, e transformar isso em algo reproduzível é o trabalho, não um sinal de que testaram mal.