Por que os passos para reproduzir decidem se um bug é corrigido

O que são passos para reproduzir em um relatório de bug?

Um relatório de bug ganha o rótulo de reproduzível quando seus passos para reproduzir listam as ações numeradas exatas, o estado inicial e as entradas necessárias para disparar a falha de novo. Qualquer pessoa que leia a lista, não só quem encontrou o bug, deve conseguir seguir os passos e chegar ao mesmo erro. Escreva os passos como um roteiro curto para outra pessoa executar, não como um resumo do que aconteceu, ou anexe um session replay para que o roteiro se escreva sozinho a partir da gravação.

O que uma seção completa de passos para reproduzir contém?

Uma seção completa nomeia cinco coisas: as pré-condições, as ações numeradas, o resultado esperado, o resultado real e o ambiente. Faltar qualquer uma delas transforma um bug reproduzível em um chute, já que um engenheiro sem o estado inicial precisa reconstruí-lo antes de sequer tentar os passos. Esse mesmo detalhe também decide gravidade versus prioridade, já que quem avalia sem uma reprodução completa chuta tanto o dano quanto a urgência.

Por que as pré-condições importam antes dos passos numerados?

As pré-condições importam porque a mesma sequência de cliques produz resultados diferentes dependendo do estado em que o usuário começou. "Clicar em checkout" se comporta de um jeito com o carrinho vazio e de outro com um cupom já aplicado, então uma lista de passos sem pré-condições dá ao engenheiro as ações, mas não o ponto de partida. Informe o tipo de conta, os dados já existentes no sistema e qualquer ação anterior tomada na mesma sessão antes do passo um.

Como o comportamento esperado e o real devem ser escritos?

O comportamento esperado e o real devem ficar em linhas separadas, cada uma com um resultado concreto em vez de uma impressão sobre o bug. Escreva o resultado esperado como o que a interface deveria mostrar, e o resultado real como exatamente o que apareceu em vez disso, incluindo texto de erro, uma tela em branco ou um valor errado. "A página parece quebrada" não reproduz nada; "esperava-se a mensagem 'Código inválido', apareceu uma tela branca em branco sem saída no console" dá ao engenheiro um alvo específico para comparar.

Quais detalhes de ambiente devem entrar em um relatório de bug?

Os detalhes de ambiente cobrem o navegador e a versão, o sistema operacional, o tamanho da tela, as condições de rede e se o bug aconteceu em produção, staging ou um build local. Um bug de layout ligado ao tratamento de flexbox do Safari ou um bug de tempo ligado a uma conexão lenta desaparece assim que alguém testa em outra configuração, então a linha de ambiente transforma um "não consigo reproduzir isso" em um "testei o navegador errado."

Por que o "funciona na minha máquina" acontece?

"Funciona na minha máquina" acontece quando quem relata e o engenheiro estão, sem perceber, usando pré-condições ou ambientes diferentes, não porque o bug seja falso. Uma feature flag ativada para uma conta e desativada para outra, um cache desatualizado, uma largura de tela diferente ou uma extensão de navegador que bloqueia um script reproduzem a falha para uma pessoa e a escondem da próxima. Trate a frase como um campo faltando no relatório, e volte para preencher o ambiente e as pré-condições em vez de fechar o ticket.

Como o session replay encurta a escrita dos passos para reproduzir?

O session replay encurta a redação porque a gravação já contém cada clique, entrada e estado de página que um relatório manual teria que descrever à mão. A Flowsery anexa a gravação e os passos para reproduzir a cada issue e relatório de bug automaticamente assim que chega no Slack, Linear ou Jira, então o engenheiro assiste à sequência exata em vez de confiar na memória do usuário sobre onde clicou. Rage clicks e dead clicks marcam o momento em que o usuário encontrou a falha, o que elimina o chute sobre onde procurar no fluxo, e marcar @flowsery na mesma thread do Slack abre um rascunho de pull request assim que a correção fica clara.

Perguntas frequentes

O que torna os passos para reproduzir bons em vez de vagos?

Bons passos para reproduzir são numerados, começam de uma pré-condição declarada e terminam com um resultado esperado declarado ao lado do resultado real. Um relatório vago descreve uma impressão ("o checkout está quebrado"); um bom relatório lista cinco cliques, o que deveria ter aparecido e o que apareceu em vez disso.

Qual é a diferença entre passos para reproduzir e uma descrição de bug?

Uma descrição de bug explica em texto corrido o que deu errado, enquanto passos para reproduzir são um roteiro que outra pessoa pode executar para ver a mesma falha. Um relatório pode ter uma descrição clara e ainda assim ser irreproduzível se pular as ações numeradas ou o estado inicial.

Por que um engenheiro não consegue reproduzir um bug relatado por um cliente?

Um engenheiro geralmente não consegue reproduzir um bug relatado porque falta ao relatório uma pré-condição ou um detalhe de ambiente, como um estado de conta, uma versão de navegador ou uma feature flag que difere entre os dois ambientes. O bug é real; o relatório está incompleto.

O que deve entrar na seção de ambiente de um relatório de bug?

A seção de ambiente deve nomear o navegador e a versão, o sistema operacional, o tamanho da tela, as condições de rede e se o bug ocorreu em produção, staging ou local. Qualquer um desses detalhes pode mudar se um bug aparece ou não.

Quantos passos uma reprodução deve ter?

Uma reprodução deve ter tantos passos numerados quantas forem as ações distintas que o usuário tomou antes da falha, nem mais nem menos. Combinar duas ações em um só passo, ou encher a lista com passos que não afetam o resultado, torna o relatório mais difícil de seguir, não mais fácil.

O session replay substitui os passos para reproduzir escritos?

O session replay substitui a necessidade de escrever as ações numeradas à mão, já que a gravação mostra os cliques, entradas e estados de página exatos em ordem. O ambiente e as pré-condições continuam sendo anexados automaticamente com a gravação, então o engenheiro abre um único issue em vez de pedir ao relator os detalhes que faltam.

Por que "a página parece quebrada" não conta como relatório de bug?

"A página parece quebrada" descreve uma sensação, não um resultado, e não dá ao engenheiro nada para comparar. Um relatório precisa de duas linhas separadas: o que a interface deveria mostrar e o que apareceu de fato, incluindo texto de erro ou tela em branco. Compare isso com "esperava-se a mensagem 'Invalid code', apareceu uma tela em branco sem saída no console", que aponta exatamente o que checar.

Como os passos para reproduzir afetam severity e priority?

Quem avalia um bug sem passos de reprodução completos precisa adivinhar tanto o dano causado quanto a urgência do conserto. As pré-condições, os passos numerados, o resultado esperado, o resultado real e o ambiente juntos dizem a quem faz a triagem o que realmente quebra e para quem. Faltando qualquer um desses campos, severity e priority viram estimativas em vez de decisões.

O que rage clicks e dead clicks acrescentam a um relatório de bug?

Rage clicks e dead clicks marcam o momento exato em que o usuário esbarrou na falha dentro do session replay. Essa marcação elimina a adivinhação de onde começar a procurar em uma sessão gravada. Junto com os passos para reproduzir anexados automaticamente, o engenheiro vai direto à falha em vez de vasculhar a sessão inteira.

A quais ferramentas o Flowsery anexa os passos para reproduzir automaticamente?

O Flowsery anexa o session replay e os passos para reproduzir a cada issue automaticamente assim que ela chega ao Slack, Linear ou Jira. O engenheiro então vê a sequência exata de cliques e inputs em vez de depender da memória de quem reportou. Marcar @flowsery na mesma thread do Slack também pode abrir um rascunho de pull request assim que a correção estiver clara.