O que é o relato visual de bugs e como se diferencia do session replay

Alguém no seu site esbarra num bug. Essa pessoa consegue vê-lo: o layout quebrado, o botão que não faz nada, o erro em vermelho. Quando aquilo chega a um desenvolvedor já virou uma frase. “O checkout está quebrado.” Tudo o que dava para ver foi jogado fora, e o primeiro trabalho do desenvolvedor é reconstruir aquilo à base de perguntas.

O relato visual de bugs é a prática de capturar o que estava na tela, e o que o navegador sabia, no momento em que alguém decidiu relatar um problema. O relatório é a evidência, e não uma descrição dela.

O que há realmente dentro de um

A palavra “visual” fica aquém. A imagem é a parte que a pessoa nota; a maior parte do valor está no que o navegador estava fazendo por trás da imagem.

Um relatório visual de bug costuma trazer algumas destas coisas, ou todas:

• Uma captura de tela ou uma gravação da página tal como quem relata a viu, muitas vezes com algo desenhado em cima para apontar o problema.
• O ambiente: navegador e versão, sistema operacional, tamanho da tela. Os dados que decidem se um defeito é universal ou pertence a uma única configuração.
• A saída do console, incluindo o erro que foi impresso enquanto ninguém estava olhando para o console.
• O log de rede: quais requisições a página fez, o que voltou, quanto tempo levou. Com frequência a resposta é um 403 que ninguém viu.
• O que quem relata fez: os cliques, o que digitou nos formulários e as mudanças de página que levaram até ali, em ordem.

É esse último ponto que transforma um relatório em instruções. Passos de reprodução escritos de memória são uma reconstrução; uma sequência gravada é um registro.

Como se diferencia do session replay

Os dois são confundidos, inclusive por nós: nosso produto se chama Session Replay, que é um nome que escolhemos e uma categoria em que não estamos.

O session replay, no sentido em que o termo é normalmente usado, é uma prática de analytics. Um script roda em toda página para todo visitante, gravando sessões continuamente para que alguém possa assisti-las depois, geralmente procurando padrões: onde as pessoas hesitam, onde abandonam um formulário, qual rage click precede qual desistência. Ninguém aperta nada. A gravação existe porque todo mundo é gravado.

O relato visual de bugs começa quando uma pessoa decide que algo está errado. Nada é gravado até que ela aja, e o que ela produz é endereçado a um leitor específico com um defeito específico em mente.

Session replay

Sempre ligado, todos os visitantes, assistido depois para achar problemas que ninguém relatou

Relato visual de bugs

Começa quando alguém relata, captura um incidente, vai para quem pode corrigir

A diferença importa por duas razões práticas. A primeira é privacidade: uma ferramenta que grava todo mundo por padrão tem de responder pelo que guardou sobre pessoas que nunca pediram nada, e é por isso que as ferramentas de session replay dedicam boa parte da documentação ao mascaramento. Um relatório que só existe porque alguém escolheu enviá-lo tem uma pergunta bem menor a responder.

A segunda é a recuperação. Achar entre milhares a única sessão que contém o bug sobre o qual lhe falaram é um trabalho por si só. Um relatório chega já sabendo de que incidente se trata.

Onde é a ferramenta errada

O relato visual de bugs só enxerga o que alguém escolheu relatar. Ele não vai lhe dizer quantas outras pessoas esbarraram no mesmo defeito e foram embora, e não vai revelar um problema do qual ninguém reclamou. Isso quem responde é a analytics, e um relatório de bug não consegue.

Ele também é inútil para tudo o que o navegador não consegue ver. Um job que falhou numa fila, uma importação noturna que gravou as linhas erradas, uma corrida entre dois serviços: nada disso está numa página, e nenhuma quantidade de captura de tela vai encontrar. Para isso servem os logs e o tracing.

A posição honesta é que são três ferramentas para três perguntas diferentes. O que deu errado para esta pessoa, agora, é a única que um relatório visual de bug responde bem.

Como isso funciona na prática

A versão que construímos é uma extensão do Chrome. Alguém esbarra num bug, clica no ícone e recebe uma captura de tela ou uma gravação com o ambiente, a saída do console, o log de rede e a sequência do que fez anexados. A pessoa recebe um link para colar onde o trabalho é acompanhado. Não é preciso conta para enviar um.

Duas coisas que ela não faz, já que uma explicação de categoria que só lista qualidades é um anúncio. Ela não observa todo mundo: nada é gravado até alguém decidir relatar algo, então ela nunca vai lhe contar sobre as pessoas que esbarraram no mesmo defeito e foram embora sem dizer nada. E ela não decide o que importa. O título, a severidade e o julgamento sobre se dois sintomas são um mesmo defeito continuam com a pessoa que estava lá, que é o assunto de como escrever um relatório de bug perfeito.

Se você está escolhendo entre os dois

Pergunte que pergunta você está tentando responder.

Se for “por que as pessoas abandonam este formulário”, você quer analytics, e o session replay faz parte dessa família. Se for “por que isso quebrou para esta pessoa”, você quer o incidente capturado e enviado a alguém, e isso é relato de bugs. Times que precisam das duas coisas costumam usar as duas, e confundir uma com a outra é o caminho para acabar assistindo quatrocentas gravações à procura de uma que alguém poderia ter lhe entregado em quinze segundos.

Os relatórios em si ainda precisam ser bem escritos: a captura tira a desculpa de faltar contexto, não a necessidade de um título claro e de um relato honesto do que você esperava. Os dez erros mais comuns continuam ao alcance de quem relata, mesmo com a melhor ferramenta do mundo.