O teste de aceitação do usuário (UAT, a homologação) tem um formato conhecido. Você dá a um grupo de pessoas (funcionários internos, a equipe de um cliente, alguns clientes beta) acesso a um build e uma semana para experimentar. No fim, recebe uma planilha.
A planilha tem sessenta linhas. Talvez quinze permitam agir na hora. Vinte são os mesmos três bugs descritos de cinco jeitos diferentes. Dez são comportamento previsto. Dez precisam de uma pergunta de acompanhamento antes que alguém possa começar. E cinco dizem algo como «tentei salvar e não salvou», sem nenhuma indicação de qual página, qual navegador ou qual dia.
O instinto é culpar o treinamento. Escrever um modelo melhor, fazer uma sessão sobre como reportar bons bugs, exigir passos para reproduzir. Isso ajuda um pouco, e o efeito some em duas semanas.
O motivo é estrutural. Testers de UAT não são analistas de QA, e pedir que se comportem como analistas de QA é pedir algo que esse arranjo não sustenta.
Por que os testers reportam menos do que deveriam
São três restrições, e nenhuma tem a ver com esforço.
Eles não veem as evidências. Um tester de UAT não está com o DevTools aberto. Ele não sabe que uma requisição retornou 500. Ele vê um spinner que nunca parou e anota «travou». A informação que resolveria o bug em noventa segundos estava na tela dele, atrás de um atalho de teclado que ninguém mostrou.
Reportar custa mais do que o bug parece valer. Um tester que precisa trocar para uma planilha, achar as colunas certas, descrever o contexto e tirar uma captura de tela vai fazer isso por um crash. Para o rótulo desalinhado e a mensagem de erro confusa, ele vai guardar na cabeça e seguir em frente. E são justamente essas descobertas que motivaram a rodada de UAT.
Eles estão testando, não documentando. Um tester concentrado está explorando um fluxo. Cada interrupção para escrever um relatório quebra essa concentração, então os relatórios ficam para o fim da sessão, que é quando os detalhes estão mais distantes e a reprodução já foi sobrescrita por vinte ações seguintes.
Cada um desses pontos é uma propriedade do canal de relatório, não da pessoa. Mude o canal e o comportamento muda.
Coloque o relatório dentro do que está sendo testado
A mudança que mais rende é tirar o relatório de uma ferramenta separada e colocá-lo dentro da aplicação em teste.
Um botão de relatório na página derruba as três restrições de uma vez. Não há troca de contexto, então os relatórios são enviados no momento da descoberta, e não acumulados para o fim. O custo cai para um clique, então as descobertas pequenas também são reportadas. E o navegador está ali, então as evidências são anexadas sem que o tester precise saber o que é evidência.
É isso que faz uma ferramenta baseada em widget. O BugDump se instala com uma única tag de script no build de staging:
<script src="https://bugdump.com/sdk/latest.js" data-api-key="your-api-key"></script>O tester clica, digita «tentei salvar e não salvou» e envia. O que chega é essa frase junto com o log do console, incluindo tudo o que foi registrado antes de ele abrir o widget, as requisições de rede com status e tempos, um replay de sessão, os cliques e as entradas dele em ordem, e o navegador, o SO, o viewport e a URL.
O tester não ficou melhor em reportar bugs. O canal parou de jogar fora as evidências.
Configure para uma rodada de UAT
Algumas decisões de configuração importam mais em testes do que em produção.
Identifique os testers. Em produção, talvez você não saiba quem está reportando. No UAT você sempre sabe, e vale a pena configurar isso: chame identify() com o nome e o e-mail do tester e setContext() com o papel atribuído, a conta de teste e o cenário que ele recebeu. Quando chegam quatro relatórios sobre permissões, ver que os quatro vieram de testers com o papel somente leitura já é o diagnóstico.
Anexe o build. Coloque o hash do commit ou o número do build no contexto. Rodadas de UAT costumam atravessar vários deploys, e «isso ainda está quebrado depois da correção de terça?» não tem resposta sem essa informação.
Deixe o botão impossível de ignorar. Em produção, um botão flutuante discreto é o certo. No UAT, não: use o balão de chamada com um texto que diga o que você quer, algo mais perto de «Achou alguma coisa? Conte para a gente» do que de um ícone mudo. Testers que esquecem que a ferramenta existe acabam mandando relatórios por e-mail.
Ligue os corpos de rede, de forma consciente. Os corpos de requisição e de resposta são a coisa mais útil que você pode anexar e também a mais sensível. Num ambiente de staging com dados sintéticos, captureNetworkBodies costuma ser um sim fácil e elimina toda uma classe de perguntas de acompanhamento. Numa rodada de UAT com dados de produção e registros reais de clientes, não é: deixe desligado ou filtre os endpoints que carregam dados pessoais.
Filtre o ruído. Ambientes de staging são barulhentos. Um networkFilter que descarta endpoints de polling e um consoleFilter que descarta as mensagens de nível debug deixam os relatórios muito mais legíveis, e relatórios legíveis passam pela triagem em vez de ficarem para depois.
Peça três coisas, não doze
Com a captura automática, o formulário só deve pedir o que apenas o tester sabe:
O que deu errado — nas palavras dele
O que ele esperava que acontecesse
Com que frequência — primeira vez, às vezes, sempre
Todo o resto (navegador, SO, URL, console, rede, horário) chega sozinho.
Vale defender essa terceira pergunta contra a vontade de cortá-la. «Sempre» contra «às vezes» é a diferença entre um bug determinístico e uma condição de corrida, e muda o lugar onde o desenvolvedor vai olhar antes mesmo de ele olhar qualquer coisa. É também a única informação sobre frequência que nenhuma instrumentação fornece, porque ela está na memória do tester sobre os últimos vinte minutos.
Resista a acrescentar um menu de severidade. Todo tester escolhe «Alta», porque de dentro de um cenário de teste travado tudo parece grave. A frequência, somada ao número de pessoas que reportam, faz o mesmo trabalho com dados melhores.
Os duplicados são o que interessa
O reflexo padrão numa rodada de UAT é achar que relatórios duplicados são desperdício: vinte linhas descrevendo três bugs. É o contrário.
Cinco pessoas reportando o mesmo botão de salvar quebrado dão a você cinco ambientes, cinco sequências de passos, cinco logs de rede. Se quatro estão no Safari e uma no Chrome com viewport estreito, você tem a causa antes de alguém abrir o código. Um único relatório desse bug teria dito muito menos.
Você não precisa de menos duplicados. Precisa de uma estrutura em que os duplicados se empilhem em vez de se espalharem. É exatamente por isso que o BugDump separa relatórios de tarefas: um relatório é a evidência de uma pessoa, uma tarefa é aquilo que você de fato corrige, e muitos relatórios se ligam a uma tarefa. Vinte relatórios viram seis tarefas, cada uma com o conjunto completo de evidências, e as vinte linhas deixam de ser bagunça e passam a ser uma matriz.
Os testers podem anexar o próprio relatório a uma tarefa existente pelo ID público quando você ativa allowTaskAttach. Com isso, «alguém provavelmente já reportou isso» deixa de ser motivo para não reportar e vira uma confirmação de um clique de que o bug acontece com eles também.
Feche o ciclo ou a rodada morre
O jeito mais garantido de matar a participação numa rodada de UAT é o silêncio. Um tester que envia seis relatórios na primeira semana e não ouve nada envia zero na segunda. Não por birra: ele simplesmente aprendeu que reportar não tem efeito, e está certo.
Duas coisas resolvem isso, e as duas são baratas.
Encaminhe os relatórios para onde a equipe já está. Um canal no Telegram, no Slack ou no Discord que recebe uma mensagem por relatório faz a rodada parecer viva para todo mundo, testers incluídos. Se os bugs devem virar issues, uma integração com GitHub Issues ou Jira evita que alguém precise redigitar a planilha num bug tracker.
Dê aos testers uma página de status. Um portal público em que quem reportou acompanha a tarefa passar de Confirmado para Concluído é todo o mecanismo. Quem vê o próprio relatório ser corrigido envia o próximo, e envia na terceira semana, que é quando os bugs interessantes aparecem.
Como fica no fim da rodada
A planilha dá lugar a um quadro. Sessenta relatórios viraram umas duas dúzias de tarefas, cada uma com as evidências de todos que esbarraram nela. As linhas inúteis sumiram, porque os campos que as tornavam inúteis foram preenchidos pelo navegador, e não por uma pessoa tentando adivinhar o que importava.
O trabalho do tester voltou a ser o que deveria ter sido: usar o software e dizer o que pareceu errado. Descobrir o que isso significa é trabalho do desenvolvedor, e agora ele tem o que precisa para fazer isso.
O plano Grátis do BugDump cobre 500 relatórios por projeto sem pedir cartão, bem mais do que a maioria das rodadas de UAT produz.
Leia também
Como coletar relatórios de bug de beta testers sem perder metade deles — como montar o canal de um beta para que os testers reportem no momento do bug e vejam o que aconteceu depois.
De 40 relatórios a 6 bugs: como a triagem deveria funcionar — por que separar relatórios de tarefas transforma os duplicados na sua melhor pista de depuração.
Como coletar relatórios de bug dos sites de clientes: um esquema para agências — como uma agência troca os e-mails dos clientes por um widget em cada site, com um quadro por projeto.