Requisitos de relatório de bug

Como posso documentar um relatório de bug corretamente e quais são os padrões de IO de teste?

Escrito por Markus

Atualizado há mais de uma semana

Neste artigo, você aprenderá como documentar adequadamente seu bug de acordo com nossas regras
e padrões. Para entender um bug, os clientes precisam de informações suficientes com documentações
de alta qualidade.

Sua primeira etapa no formulário de relatório de bug deve ser selecionar o recurso correto. Se você não
conseguir encontrar o recurso correto na lista suspensa, volte para a página de visão geral do teste, leia
todas as descrições de recursos e marque-as como lidas . Depois disso, você pode voltar ao formulário
de relatório de bug e todos os recursos serão apresentados na lista suspensa.

Formulário de Bug
Depois de selecionar o recurso, todo o formulário de bug ficará visível para você. Um formulário para
bugs funcionais, por exemplo, é o seguinte:
Você deve preencher todos os campos do formulário de bug com as informações específicas e de
acordo com nossos padrões de qualidade. Informações mais detalhadas sobre cada campo e seus
requisitos podem ser encontradas abaixo.

Gravidade
Apenas para bugs funcionais , você verá um campo extra chamado Severidade : Baixa , Alta e / ou
Crítica . A gravidade indica a urgência do seu relatório e depende de vários fatores. Para saber mais
sobre os diferentes níveis de gravidade, visite o seguinte artigo Bugs funcionais .

O campo Severidade não será exibido para outros tipos de bug.

Título

O título do relatório de bug deve resumir o problema, para que o leitor tenha uma idéia geral do bug
apenas lendo o título do bug. Eles não deveriam ter que ler o relatório inteiro para entender qual é o
problema. O título do seu relatório de bug deve ser preciso e não muito longo ao mesmo tempo. Ele
deve conter o elemento em questão (por exemplo, campo de pesquisa), qual funcionalidade está
quebrada e a origem .

Ao escrever o título de um bug, descreva o que está acontecendo em vez do que não está
acontecendo. Seu título nunca deve declarar que algo não está funcionando , caso contrário, o leitor não
tem ideia do que está realmente acontecendo.

Os títulos devem refletir o problema real. Se o bug ocorrer apenas sob certas condições, as condições
devem ser incluídas no título do bug. Se, por exemplo, não conseguir reservar um bilhete ao afirmar que
é adolescente, esta é uma informação relevante e deve constar do seu título.

Para inventar um título descritivo, coloque-se no lugar de alguém que nunca testou o site / aplicativo,
que não consegue imaginar em que página você está, sua aparência e o que você fez. Leia seu título da
perspectiva dessa pessoa para ver se você entende o bug. Se você não tiver uma boa ideia do bug,
ajuste o título do bug e repita o processo.

Títulos de bug exemplares

Errado: a pesquisa não funciona.
Correto: a pesquisa não é acionada ao clicar no botão de pesquisa

Errado: o método de classificação não funciona corretamente.

Correto: ao definir o método de classificação X, os produtos não mudam de pedido

O que há de errado com os exemplos acima: há muitos cenários possíveis nos quais esses títulos se
encaixariam por serem muito abstratos. O leitor não sabe qual ação você executa e como o sistema
responde a ela. Portanto, o revisor deve ler todo o relatório para entender o que é o bug e não pode
distingui-lo facilmente de outros.
URL

Visite a página onde o bug aparece e copie e cole o URL do campo URL do seu navegador no campo
URL do formulário de relatório do bug.

O URL deve ser completo, para que redirecione ao destino correto.

Se você testar um aplicativo , deixe este campo em branco, a menos que indicado de forma diferente
na descrição do teste ou no bate-papo de teste.

Passos para reproduzir

Os bugs devem ser reproduzíveis e precisam de um guia detalhado passo a passo sobre como podem
ser reproduzidos. Cada etapa deve descrever uma ação separada. Observe que você não precisa
numerar seus passos, pois isso é feito automaticamente pelo nosso sistema.

A primeira etapa deve conter o URL da página de destino se você testar um site ou o nome do
aplicativo se você testar um aplicativo móvel. Todas as etapas seguintes devem descrever suas ações
desde a etapa inicial até o ponto em que o bug ocorre - quais botões você pressiona, quais links você
segue e o que você insere. Sua última etapa deve descrever a ação que você executa que aciona o
bug.

Seus passos devem ser tão gerais quanto possível . Apenas se o seu bug ocorrer sob condições
específicas, por exemplo, apenas para uma página de visão geral de um produto específico, para um
filtro específico, para uma entrada específica, etc., nomeie essa condição em suas etapas. Por exemplo,
em suas etapas, não descreva a página de visão geral do produto específico que você visitou e, em
seguida, o produto específico que você adicionou ao carrinho se o problema ocorrer com qualquer
produto. Isso ajudará o leitor a entender a ideia do bug e não se distrairá com detalhes irrelevantes.

Se você tiver que ser específico, por exemplo, quando for solicitado a documentar quais credenciais
você usou para fazer login em sua conta de usuário, use os nomes que são palavras reais e não
apenas destrua seu teclado. Um mau exemplo seria “asdlkfgjasdfkg lajsdhjasd”, pois isso não parece
profissional para nossos clientes.

Etapas exemplares
 Vá para http://www.examplewebsite.com
Insira qualquer consulta de pesquisa na barra de pesquisa superior direita (por exemplo, “São
Francisco”)
Clique em “Pesquisar agora” ou pressione a tecla Enter

Resultado atual

O resultado real é um dos campos mais importantes de um relatório de bug porque aqui você explica
qual é o problema e todos os detalhes adicionais que são necessários para entender o bug.

O que realmente acontece depois de seguir seu guia passo a passo deve ser descrito da forma mais
detalhada possível. Tente ser muito preciso e não muito genérico, por exemplo, dizendo que os produtos
permanecem principalmente na mesma ordem depois de aplicar o método de classificação X, mas, em
vez disso, descreva exemplos específicos dos produtos que não estão na ordem correta. Adicione
qualquer informação neste campo que seja relevante para o bug, por exemplo, exemplos, outras
condições ou exceções. Apenas certifique-se de estruturar suas informações para ajudar o leitor a
entender seu processo de pensamento.

Notas importantes: Os resultados reais e esperados nunca devem ser exatamente o oposto um do
outro. Sua expectativa e o que realmente acontece diferem muito.

Da mesma forma, o resultado real não deve ser igual ao título do relatório. Embora o título seja um
resumo do problema, o resultado real deve ser uma descrição detalhada do mesmo e incluir mais
detalhes, como informações do cenário e exemplos.

Resultado real exemplar

Errado: a função de pesquisa de nome de cidade não funciona.
Correto: Depois de clicar em “Pesquisar agora”, nada acontece. Nenhum resultado de pesquisa é
exibido em uma nova página do navegador e o usuário não recebe nenhuma mensagem ou notificação
sobre o que deu errado. O botão “Pesquisar agora” não mostra nenhuma funcionalidade implementada.

resultado esperado
Descreva o que você espera que aconteça após realizar a última etapa descrita. Como sempre, os
detalhes são a chave. Pense no que deveria ter acontecido se você não tivesse experimentado o bug -
se tudo funcionasse corretamente.

Resultado esperado exemplar

Errado: a função de pesquisa do nome da cidade funciona.
Correto: Depois de inserir o nome da cidade “San Francisco”, os hotéis disponíveis em San Francisco
devem ser exibidos. Se não houver tais hotéis, uma mensagem correspondente deve ser exibida, e. g.
“Não há hotéis disponíveis na sua cidade”.

Anexos

Pelo menos um anexo deve ser carregado para cada relatório de bug. Para saber que tipo de anexo
deve ser anexado ao seu bug e quais regras se aplicam, visite o seguinte artigo: Requisitos para anexos
de relatório de bug .

Ambiente usado

É importante para nós e para o nosso cliente saber qual dispositivo você usou quando encontrou o bug.
Ao testar um site, clique no ícone do navegador ao lado do dispositivo que você usou. Ao testar um
aplicativo móvel, selecione o dispositivo que você usou para testar e que possui o aplicativo instalado.

Você só pode usar os dispositivos para teste listados nesta seção. Seu dispositivo, navegador e / ou
versão do sistema operacional deve corresponder ao dispositivo que você mostra em seu anexo.
Certifique-se de selecionar o ambiente certo durante o processo de envio, pois esta é a única
informação que não pode ser alterada posteriormente - nem por você nem pelo líder da equipe.
Infelizmente, seu relatório deve ser rejeitado se você selecionar o ambiente errado, mas você pode
reenviar seu bug se o teste ainda estiver em execução e se nenhum outro testador já tiver enviado o
bug corretamente nesse ínterim.

Você gostaria de testar com um dispositivo que não está na lista de dispositivos disponíveis em seu perfil
? Basta enviar-nos um pedido através do chat de suporte e adicionaremos o seu dispositivo à sua lista,
desde que seja relevante para os nossos clientes.

Nota: Quando você remove o dispositivo para o qual foi convidado da lista de dispositivos em seu perfil
de testador, não pode mais enviar relatórios neste teste. A seção de ambiente do formulário de bug
estará vazia e o formulário não pode ser enviado. A exclusão de um dispositivo em seu perfil não pode
ser revertida após você aceitar um convite de teste!

Regra de rejeição direta

Por favor, invista tempo suficiente para documentar seus bugs, pois os Líderes de Equipe não irão
melhorar seus relatórios de bug para atingir o nível de qualidade exigido - É seu trabalho e
responsabilidade. Se você não for mais um testador novato, os líderes de equipe terão que rejeitar
diretamente os relatórios de bug se um ou mais dos seguintes casos forem verdadeiros para o seu
relatório de bug:

Vários erros gramaticais (não apenas um erro de digitação)

Escolha de recurso incorreto repetido
A descrição geral do relatório de bug não é compreensível
Título do relatório de bug pouco claro
Faltam etapas importantes
O testador claramente não leu ou seguiu as instruções do teste
Evidência inconsistente - quando a discrepância entre as etapas e o screencast é muito grande.
Evidência incompleta, como anexos ausentes, incluindo logs de travamento ausentes.

Se um de seus relatórios de bug for rejeitado por baixa qualidade, você pode enviá-lo novamente com a
qualidade adequada, a menos que outro testador já o tenha feito nesse meio tempo. Nesse caso, o bug
será uma duplicata e será rejeitado.