O modelo de relatório de bug que nenhum revisor rejeita

O que é um modelo de relatório de bug?

Um modelo de relatório de bug nomeia cada campo que um ticket precisa antes que um engenheiro possa agir sobre ele, do título até a linha de ambiente, para que nada precise ser perseguido depois que o ticket é aberto. Cada campo responde a uma pergunta que um revisor teria que fazer numa thread de comentários, se não existisse. Preencha cada campo antes de enviar, e trate um campo em branco como motivo para o ticket voltar.

Por que o campo de título existe e o que torna um título útil?

O campo de título existe para que um revisor consiga dizer o que está quebrado sem abrir o ticket, o que decide se ele é pego na próxima rodada de triage ou fica enterrado sob outros cinquenta. Um título útil nomeia a ação e a falha juntas, como "Aplicar um vale-presente no checkout mostra uma página em branco em vez de um erro", não um humor como "o checkout está quebrado". Escreva o título por último, depois que os passos e o resultado real estiverem claros, para que ele nomeie a falha real em vez de um chute.

Por que o campo de passos para reproduzir existe?

O campo de passos para reproduzir existe para que uma segunda pessoa consiga disparar a mesma falha sem perguntar mais nada a quem relatou, transformando uma observação pontual num caso de teste repetível. Ações numeradas a partir de um ponto de partida declarado são o que separa um relatório com o qual um engenheiro consegue trabalhar de um relatório que precisa de uma reunião de acompanhamento. Passos para reproduzir cobre como é um conjunto completo de passos e por que uma pré-condição faltando é o motivo mais comum para eles falharem.

Por que gravidade precisa de seu próprio campo, separado de prioridade?

Gravidade precisa de seu próprio campo porque mede o dano técnico, enquanto prioridade mede quão rápido alguém precisa corrigir, e as duas respostas raramente coincidem. Um bug de pagamento que atinge uma única conta num fim de semana é grave, mas não é urgente hoje à noite; um erro de digitação na página inicial é menor, mas urgente antes de um lançamento. Gravidade vs. prioridade detalha como quem faz o triage pontua cada uma sem que um número vaze para o outro.

Gravidade e prioridade puxam em direções diferentes

Grave, mas não urgente

• O bug de pagamento afeta uma conta
• Acontece num fim de semana

Urgente, mas não grave

• Erro de digitação na página inicial
• Precisa ser corrigido antes de um lançamento

O que deve entrar no campo de ambiente?

O campo de ambiente nomeia o navegador e a versão, o sistema operacional, o tamanho da tela e se a falha aconteceu em produção, staging ou um build local, porque a mesma sequência de cliques pode se comportar de forma diferente em qualquer um desses casos. Um revisor sem esse campo não consegue saber se um bug é universal ou está preso a uma única configuração, o que significa que ele nem consegue estimar quantos usuários ele afeta. Copie a string de versão exata da página about do navegador em vez de um chute como "Chrome mais recente".

O que deve entrar nos campos de resultado esperado e resultado real?

O campo de resultado esperado declara o que a interface deveria mostrar, e o campo de resultado real declara exatamente o que apareceu em vez disso, cada um como uma linha concreta, não um parágrafo compartilhado sobre como o bug pareceu. "Esperava-se a mensagem 'Código inválido', apareceu uma página branca em branco sem saída no console" dá a um engenheiro algo para comparar; "o checkout não funciona" não dá. Escreva as duas linhas antes de escrever o título, já que a discrepância entre elas é o que o título tem que nomear.

Campo	Pergunta que responde	O que um revisor rejeita se estiver faltando
Título	O que está quebrado, em uma linha	Um título vago ou baseado em humor, sem falha nomeada
Pré-condições	Que estado existia antes do passo um	Tipo de conta, dados existentes ou ações anteriores deixados de fora
Passos para reproduzir	O que clicar, digitar ou enviar, em ordem	Passos que pulam uma ação ou não estão numerados
Resultado esperado	O que deveria ter acontecido	Um resultado esperado faltando ou vago
Resultado real	O que aconteceu em vez disso	"Está quebrado" em vez do erro ou tela exatos
Gravidade	Quanto dano técnico o bug causa	Gravidade usada como substituto de urgência
Prioridade	Quão rápido o bug precisa ser corrigido	Prioridade definida sem uma gravidade declarada que a justifique
Ambiente	Navegador, sistema operacional, tamanho de tela e estágio de build	"Chrome mais recente" em vez de uma string de versão exata

O que faz um revisor rejeitar uma submissão de cara?

Um revisor rejeita uma submissão de cara quando um dos oito campos acima está em branco, vago ou responde à pergunta errada, já que quem faz o triage não consegue pontuar gravidade e prioridade num relatório que não consegue visualizar. A causa isolada mais comum é uma pré-condição faltando: os passos parecem completos, mas ninguém declara o estado da conta ou os dados existentes que os passos pressupõem. A segunda causa mais comum é combinar resultado esperado e resultado real numa única frase, o que esconde a discrepância exata que uma correção precisa fechar.

Como o session replay preenche um modelo de relatório de bug automaticamente?

O session replay preenche um modelo de relatório de bug automaticamente porque a gravação já contém as pré-condições, as ações numeradas e o ambiente que um relatório manual teria que descrever à mão. A Flowsery anexa a gravação, os passos para reproduzir e os detalhes de ambiente a cada issue assim que ele chega no Slack, Linear ou Jira, então quem relata só precisa confirmar a gravidade em vez de digitar de novo campos que a gravação já responde. O mesmo relatório de bug com session replay mostra a um engenheiro o clique exato que disparou a falha, o que preenche o campo de resultado real sem que ninguém escreva uma descrição dele.

Preenchendo um modelo de relatório de bug em ordem

1

Declare as pré-condições. Estado da conta, dados existentes e qualquer ação anterior antes do passo um.

2

Numere os passos para reproduzir. Um clique, toque ou entrada por linha, na ordem em que foi feita.

3

Escreva o resultado esperado e o real como duas linhas. Não um parágrafo sobre como o bug pareceu.

4

Pontue gravidade, depois prioridade. O dano causado, depois quão rápido precisa ser corrigido.

5

Registre o ambiente. Navegador, sistema operacional, tamanho de tela e produção, staging ou local.

Perguntas frequentes

Quais campos um modelo mínimo viável de relatório de bug precisa?

Um modelo mínimo viável precisa de um título, pré-condições, passos numerados para reproduzir, resultado esperado, resultado real, gravidade, prioridade e ambiente. Deixe de fora qualquer um desses oito e um revisor tem que fazer uma pergunta de acompanhamento antes de fazer o triage do ticket, exatamente o atraso que um modelo existe para eliminar.

Gravidade e prioridade podem compartilhar um campo num modelo de relatório de bug?

Gravidade e prioridade não deveriam compartilhar um campo, porque um bug pode ser grave sem ser urgente, como um bug de pagamento que afeta uma conta num fim de semana, ou urgente sem ser grave, como um erro de digitação na página inicial antes de um lançamento. Juntá-los num só campo obriga quem relata a chutar qual resposta o número representa.

Por que revisores rejeitam relatórios que têm passos, mas não têm pré-condições?

Revisores rejeitam relatórios com passos, mas sem pré-condições porque a mesma sequência de cliques produz resultados diferentes dependendo do estado da conta, dos dados existentes ou de ações anteriores tomadas antes do passo um. Sem um ponto de partida declarado, um engenheiro tem que reconstruir a pré-condição antes mesmo de tentar os passos listados.

Qual é a diferença entre o campo de ambiente e o campo de resultado real?

O campo de ambiente nomeia onde o bug aconteceu, como o navegador, o sistema operacional e o estágio de build, enquanto o campo de resultado real nomeia o que aconteceu, como uma mensagem de erro ou uma tela em branco. Um relatório pode declarar exatamente o que deu errado e ainda assim ser irreproduzível se nunca disser qual navegador ou ambiente causou isso.

A criação automática de tickets de bug elimina a necessidade de um modelo de relatório de bug?

A criação automática de tickets de bug elimina a necessidade de digitar os campos à mão, não a necessidade dos campos em si. A Flowsery anexa a gravação, os passos para reproduzir e o ambiente a cada issue automaticamente, então quem relata revisa e confirma os campos em vez de digitá-los de novo de memória.

Quanto tempo deve levar para preencher um modelo de relatório de bug?

Um modelo de relatório de bug deve levar o tempo que leva para declarar oito fatos que um revisor precisa: título, pré-condições, passos, resultado esperado, resultado real, gravidade, prioridade e ambiente. Um relatório que leva muito mais tempo do que isso preenche descrição no lugar de um desses fatos; um relatório que leva menos pulou um deles por completo.

Quem preenche um modelo de relatório de bug, o relator ou o revisor?

O relator preenche cada campo na criação do ticket, informando o título, as pré-condições, os passos, o resultado esperado e o real, a gravidade, a prioridade e o ambiente. O revisor lê esse mesmo modelo para conferir se nada falta antes de o ticket chegar a um engenheiro, e devolve o ticket em vez de corrigi-lo se algum campo estiver vazio. Quando o session replay anexa os passos e o ambiente automaticamente, a parte do relator se reduz a confirmar a gravidade.

O que acontece depois que um revisor rejeita um relatório de bug?

O ticket volta para o relator em vez de seguir para um engenheiro. O relator precisa completar o que o revisor apontou, quase sempre uma pré-condição ausente ou um resultado esperado e real resumidos numa única frase, antes de o ticket voltar à triagem. Ninguém pontua gravidade ou prioridade num relatório devolvido, porque quem faz a triagem não consegue avaliar um bug que não consegue visualizar.

Por que resultado esperado e resultado real não devem compartilhar uma frase?

Juntar os dois numa única frase esconde exatamente o desajuste que uma correção precisa fechar, e essa é a segunda causa mais comum de rejeição por um revisor. Escritos como duas linhas separadas, como uma mensagem esperada de 'Código inválido' contra uma tela branca real, um engenheiro consegue identificar a lacuna diretamente em vez de ler um parágrafo sobre como o bug pareceu. O campo de título só funciona depois que esse desajuste é dito com clareza, já que o título precisa nomear a falha que essas duas linhas descrevem.

A ordem dos campos num modelo de relatório de bug importa?

A ordem importa porque cada campo depende do anterior: as pré-condições precisam existir antes dos passos que as pressupõem, e a gravidade é pontuada antes da prioridade para que a urgência tenha um dano ao qual se referir. O resultado esperado e o real são escritos antes do título, já que o desajuste entre essas duas linhas é o que o título precisa nomear. Seguir essa ordem é o que faz o título, o último campo, praticamente se escrever sozinho.