User acceptance testing: o guia do fundador não-técnico

Como decidir se o software que seu fornecedor entregou está mesmo pronto, o que testar quando você não lê código, e como definir “pronto” antes da primeira linha ser escrita.

Um fundador com quem trabalhamos certa vez nos encaminhou um e-mail de uma linha do desenvolvedor dele: “Todas as features prontas, pode lançar.” Ele tinha pagado por um portal de clientes ao longo de quatro meses. Antes de transferir a última parcela, ele nos fez uma pergunta simples: como eu sei que isso é verdade?

Ele não lia código. Não sabia distinguir uma suíte de testes passando de um print de uma. O que ele tinha era a sensação de que “pode lançar” era a opinião do desenvolvedor, não um fato que ele pudesse checar. Essa distância, entre alguém te dizer que o trabalho está pronto e você saber que está, é exatamente a distância que o user acceptance testing fecha.

User acceptance testing (UAT) é a checagem final antes do software entrar no ar, em que usuários reais confirmam que o produto faz o que o negócio de fato precisa, em condições reais. Não é sobre achar bugs no código. É sobre responder uma pergunta: essa coisa faz o trabalho pelo qual a gente pagou? Para um fundador não-técnico, o UAT é a hora mais importante que você vai gastar num projeto, porque é a única parte do processo que você está qualificado a conduzir sem saber programar.

O que é user acceptance testing de verdade

A maioria das definições que você encontra na internet é escrita para engenheiros de QA, então elas enterram a parte que importa para você. Tirando o excesso, o UAT é isto: uma pessoa que representa o negócio usa o software do jeito que um cliente ou funcionário real usaria, contra uma lista escrita do que ele deveria fazer, e dá o aceite só quando cada item funciona.

O “user” em user acceptance testing é o ponto central. O órgão de padrões da própria indústria de software, o ISTQB, define teste de aceitação como o teste que estabelece se um sistema deve ser aceito, o que é um jeito educado de dizer que ele existe para responder uma pergunta de negócio do tipo sim ou não. Os testes anteriores checam se o código se comporta como os engenheiros pretendiam. O UAT checa se o que os engenheiros pretendiam é o que o negócio precisava. São perguntas diferentes, e a segunda é sua. Um desenvolvedor pode construir um fluxo de checkout impecável que cobra a alíquota errada de imposto para o seu mercado. O código está correto. O produto está errado. Só quem entende do negócio pega isso, e essa pessoa costuma ser você.

É por isso que o UAT é trabalho do fundador, não do fornecedor. Quando você terceiriza o build para uma software house ou um freelancer, dá para terceirizar a engenharia, a arquitetura, até a gestão do projeto. O que não dá para terceirizar é o julgamento de se o resultado serve ao seu negócio. Isso fica com quem é dono do resultado de negócio.

UAT versus QA: quem testa o quê

Fundadores confundem os dois o tempo todo, e a confusão custa dinheiro. Aqui vai a divisão limpa.

Quality assurance (QA) é responsabilidade do desenvolvedor. É o teste interno, feito por gente do time de build, conferindo que o software funciona como especificado: os botões clicam, os dados salvam, a API retorna o que deveria, nada quebra sob carga. Bons fornecedores fazem isso antes de te mostrar o produto. Se uma tela dá erro no momento em que você abre, o QA falhou, e isso é com eles.

User acceptance testing é responsabilidade sua. Acontece depois que o QA passa, e checa algo que o QA não consegue: se “funciona como especificado” bate com “funciona para o negócio”. O QA do fornecedor confirma que o gerador de notas produz um PDF. Só você confirma que o PDF tem a razão social da sua empresa, as condições de pagamento certas e a discriminação de impostos que seu contador precisa.

A regra prática que damos aos fundadores: se a falha é “o software está quebrado”, isso é QA, devolva sem cerimônia. Se a falha é “o software funciona mas não é o que a gente precisa”, isso é UAT, e é uma conversa sobre escopo, não um report de bug. Saber em qual balde um problema cai te diz se você tem direito a um conserto grátis ou se está pedindo trabalho novo. Escrevemos mais sobre como o escopo se expande sem ninguém perceber no nosso texto sobre feature creep, e o UAT é onde essa tensão vem à tona.

O erro que transforma o UAT numa briga

Aqui está a armadilha. A maioria dos fundadores não-técnicos ouve as palavras “user acceptance testing” pela primeira vez no fim do projeto, quando o fornecedor diz “estamos prontos para o seu aceite”. A essa altura já é tarde para fazer bem feito, porque o UAT não tem sentido sem critérios de aceite, e critérios de aceite precisam existir antes do build começar.

Critérios de aceite são as condições escritas, específicas e testáveis que definem “pronto” para cada feature. Não “construir um sistema de login”. Em vez disso: “um usuário consegue se cadastrar com e-mail e senha, recebe um e-mail de confirmação em até dois minutos, consegue redefinir uma senha esquecida e é bloqueado após cinco tentativas falhas”. Isso é algo que você pode testar. “Um sistema de login” é algo sobre o que dá para discutir.

A razão de isso importar tanto para fundadores que não escreveram a especificação eles mesmos: se “pronto” nunca foi definido por escrito, então no fim do projeto “pronto” vira o que o fornecedor disser que é, e você não tem como discordar. Já vimos fundadores perderem esse argumento em tempo real. O desenvolvedor diz que a feature está completa. O fundador sente que não está. Nenhum dos dois consegue apontar para um documento. O fundador paga, porque a alternativa é uma briga com quem está com o código dele na mão.

Defina os critérios no começo e a dinâmica se inverte. Agora “pronto” é uma checklist que os dois lados concordaram, e o UAT é só percorrer a checklist. É por isso que critérios de aceite pertencem a dois documentos antes de alguém escrever código: o seu documento de requisitos, onde cada feature ganha suas condições testáveis, e o seu contrato de desenvolvimento de software, onde o aceite é amarrado ao pagamento final. Se o seu contrato libera a última parcela na “entrega” em vez de no “aceite”, corrija isso antes de assinar. A palavra carrega muito peso.

Um playbook de UAT que você roda sem escrever código

Você não precisa saber como o software é construído para rodar um teste de aceite rigoroso. Precisa ser organizado e um pouco teimoso. Aqui está a sequência que entregamos aos fundadores.

1. Teste contra os critérios, não contra o seu humor. Abra os critérios de aceite que você escreveu antes. Vá feature por feature, condição por condição. Para cada uma, a resposta é binária: faz isso, ou não faz. Resista à vontade de testar “como parece”. Sensações são reais, mas são uma conversa à parte; agora você está checando fatos contra uma lista.

2. Use dados reais e cenários reais. É aqui que os fundadores encontram os problemas que importam. Não teste a ferramenta de notas com “Empresa Teste” e uma cobrança de R$ 1,00. Rode os números reais do seu maior cliente de verdade. Rode o caso extremo que você sabe que é confuso: o estorno, o pagamento parcial, o cliente em outro estado. Um exemplo concreto de um build que revisamos: o software lidava com novas assinaturas perfeitamente e quebrava por completo nos cancelamentos, porque ninguém testou um cancelamento. O critério dizia “gerenciar assinaturas”. Cancelar é gerenciar uma assinatura. Foi para o ar quebrado porque o UAT só testou o caminho feliz.

3. Teste nos dispositivos que seus usuários realmente usam. Se metade dos seus clientes está no celular, teste no celular, não só no notebook em que o desenvolvedor fez a demo. “Funciona no desktop” não é “funciona”.

4. Anote cada falha com precisão. “A coisa tá bugada” não ajuda ninguém. “Quando clico em Enviar no formulário de contato com um e-mail do Gmail, nada acontece, e a página não mostra erro” é um report em cima do qual o desenvolvedor age no mesmo dia. Especificidade é a diferença entre um conserto nesta semana e um vai-e-volta que leva três.

5. Separe “quebrado” de “não é o que eu queria”. Classifique cada falha nos dois baldes anteriores. Quebrado volta como defeito, consertado sem custo. “Não é o que eu queria mas bate com o critério” é uma solicitação de mudança, o que significa escopo novo e possivelmente dinheiro novo. Ser honesto sobre o que é o quê impede a relação com o fornecedor de virar adversarial.

6. Dê o aceite por escrito, critério por critério. Quando uma feature passa, registre. Quando a lista inteira passa, isso é o seu aceite, e isso é o gatilho do pagamento final que o seu contrato deveria amarrar. Não dê o aceite no pacote inteiro num e-mail só para se livrar da tarefa. A checklist é a sua margem de manobra e o seu registro.

Rode esses seis passos e você fez algo que a maioria dos fundadores nunca faz: trocou “acho que tá bom” por “aqui está o que eu verifiquei”. Isso vale mais do que qualquer conhecimento técnico que você não tem.

Quando o UAT te diz que algo está errado

Às vezes o teste falha e o fornecedor empurra de volta. Ele vai dizer que o item que falhou não estava no escopo, ou que é um caso extremo, ou que consertar é extra. De vez em quando ele tem razão. Muitas vezes a discordância é exatamente por isso que você escreveu critérios com antecedência, então volte ao documento e veja o que ele diz. Se os critérios cobriam aquilo, é um defeito. Se não cobriam, você aprendeu algo sobre a sua própria especificação, e agora está negociando mudança, não litigando opinião.

Se o UAT trouxer à tona problemas fundos o suficiente para você começar a duvidar do build inteiro, esse é um sinal diferente e mais sério. Uma única feature quebrada é um conserto. Um padrão de features que tecnicamente rodam mas erram de forma consistente a necessidade do negócio normalmente significa que a especificação e o builder nunca estiveram de fato alinhados, e nenhuma dose de teste de aceite remenda isso. Esse é o momento de trazer uma leitura independente do código antes de despejar mais dinheiro. Cobrimos como fazer isso no nosso guia de technical due diligence.

A versão saudável dessa relação não é um fornecedor que passa em todo teste de primeira. É um fornecedor que fez o QA dele a sério o bastante para o seu UAT encontrar lacunas de fit com o negócio, não quedas, e que trata a sua checklist como o contrato que ela é. Os bons querem os critérios no começo tanto quanto você deveria. Protege eles também.

Perguntas frequentes

O que é user acceptance testing em termos simples?
É a checagem final, feita por alguém que representa o negócio, confirmando que o software terminado faz o que a empresa de fato precisa antes de entrar no ar. Testa adequação ao propósito, não qualidade de código.

Qual a diferença entre QA e UAT?
QA é o time de build confirmando que o software funciona como especificado. UAT é você confirmando que a especificação estava certa para o negócio. QA pega “está quebrado”. UAT pega “funciona mas está errado”.

Qual é um exemplo de user acceptance testing?
Rodar os números reais do seu maior cliente numa ferramenta nova de notas, incluindo um estorno e um pagamento parcial, e confirmar que cada nota mostra a razão social, as condições de pagamento e os impostos corretos. Se cada condição da sua lista escrita passa, a feature é aceita.

Quem deve conduzir o UAT numa startup?
Quem é dono do resultado de negócio, normalmente o fundador ou quem escreveu os requisitos, possivelmente com um ou dois usuários reais. Não deve ser conduzido pelo fornecedor que construiu o produto; isso anula o propósito.

Quanto ganha um testador de UAT?
Essa pergunta vem de quem pesquisa carreiras de QA, não de fundadores comprando software. Para o seu caso, o UAT não é um cargo assalariado num build pequeno; é uma responsabilidade que você carrega como comprador. Em produtos maiores existem testadores dedicados, mas o aceite de negócio continua sendo do negócio.

Quando os critérios de aceite devem ser escritos?
Antes do build começar, dentro do seu documento de requisitos, e referenciados no seu contrato. Critérios escritos depois da entrega são quase inúteis, porque a essa altura “pronto” é o que o fornecedor disser que é.