Neste artigo, você aprenderá como documentar corretamente seu bug de acordo com nossas regras e padrões. Para entender um bug, os clientes precisam de informações suficientes com documentação de alta qualidade. Você encontrará informações mais detalhadas sobre nossas regras em cada seção deste artigo, mas aqui está um resumo rápido de nossos requisitos para relatórios de bugs:

Seu primeiro passo no formulário de relatório de bug deve ser selecionar o Recurso correto. Se você não encontrar o Recurso certo 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.

Depois de selecionar o Recurso, todo o formulário de bug estará visível para você. Um formulário para bugs funcionais, por exemplo, parece o seguinte:

Você deve preencher cada campo do formulário de bug com as informações específicas corretas de acordo com nossos padrões de qualidade. Informações mais detalhadas sobre cada campo e seus requisitos podem ser encontradas abaixo.

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

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

O título do relatório de bug deve resumir o problema para que o leitor tenha uma ideia geral do bug apenas lendo o título. Eles não devem 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. Deve conter informações: o que é o bug, onde o bug ocorreu e quando o bug é acionado? Portanto, ao escrever um título para o seu relatório de bug, lembre-se sempre: O quê? Onde? Quando?

Quando você escreve um título de bug, descreva o que está acontecendo em vez do que não está acontecendo. Seu título nunca deve afirmar que algo não funciona, caso contrário, o leitor não terá ideia do que está realmente acontecendo.

Os títulos devem refletir o problema real. Se o bug ocorrer apenas em certas condições, as condições devem ser incluídas no título do bug. Por exemplo, se você não conseguir reservar um bilhete quando afirmar que é adolescente, estas são informações relevantes e devem ser incluídas no seu título.

Para criar um título descritivo, coloque-se no lugar de alguém que nunca testou o site/aplicativo, que não consegue imaginar em qual página você está, como ela se parece e o que você fez. Leia seu título sob a perspectiva dessa pessoa para ver se você entenderia o bug. Se você não tiver uma boa ideia do bug, ajuste o título e repita o processo.

Errado: Erro exibido na página do Carrinho

Correto: Um "Erro 500" será exibido na página do Carrinho após o usuário clicar no botão "Finalizar compra"

Errado: O usuário não pode adicionar um produto ao Carrinho

Correto: Um "Erro Inesperado" foi exibido na PDP, quando o usuário selecionou o tamanho e clicou no botão "Adicionar ao Carrinho".

O que está errado nos exemplos acima: Existem muitos cenários possíveis em que esses títulos se encaixariam porque são muito abstratos. O leitor não sabe quais ações você realizou e como o sistema responde a elas. Portanto, o revisor precisa ler o relatório inteiro para entender qual é o bug e não consegue distinguir esse bug dos outros facilmente.

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

A URL deve ser válida.

Os bugs precisam 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.

A primeira etapa deve conter uma indicação para acessar a URL da página de destino fornecida pelo cliente na seção de Acesso, se você estiver testando um site, ou uma indicação para abrir o aplicativo (com seu nome) se você estiver testando 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ê digita. Sua última etapa deve descrever a ação que você executa que aciona o bug. Lembre-se de que "observar" não é uma ação tomada pelo usuário.

Suas etapas devem ser o mais gerais possível. Apenas se o bug ocorrer sob condições específicas, por exemplo, apenas para uma determinada página de visão geral do produto, para um filtro específico, para uma entrada específica, etc., mencione essa condição em suas etapas. Por exemplo, em suas etapas, não descreva a página de visão geral do produto específica 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 seu bug e não se distrairá com detalhes irrelevantes.

Finalmente, certifique-se de que suas etapas contenham o menor número possível de ações para serem executadas. Após ler cada etapa, a pessoa que reproduz o bug relatado deve ser capaz de concluí-las no site ou aplicativo. Eles não devem ter que verificar a mesma etapa várias vezes para lembrar o que precisa ser feito.

O que está errado com os exemplos acima: A primeira etapa deve conter uma indicação para acessar a URL da página de destino, não apenas a URL em si. A terceira etapa não é detalhada o suficiente e contém muitas ações em uma única etapa. As segunda e quarta etapas são redundantes e não são necessárias para entender o bug.

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

O que realmente acontece após seguir seu guia passo a passo deve ser descrito o mais detalhado possível. Tente ser muito preciso e não seja muito geral, dizendo, por exemplo, que os produtos permanecem principalmente na mesma ordem após aplicar o método de classificação X, mas 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, como exemplos, condições adicionais, exceções ou resultados de outros testes importantes, se necessário. Apenas certifique-se de estruturar suas informações para ajudar o leitor a entender seu processo de pensamento.

Da mesma forma, o resultado atual não deve ser o mesmo que o título do relatório. Enquanto o título é um resumo do problema, o resultado atual deve ser uma descrição detalhada dele e deve incluir detalhes adicionais, como informações de cenário, exemplos e resultados obtidos ao realizar as etapas para reproduzir o bug.

Errado: Erro exibido na página do Carrinho após clicar no botão de Checkout.

Correto: Quando o usuário adicionou algum produto ao Carrinho e tentou prosseguir para a página de Checkout, ele perceberá que não será capaz de fazê-lo. Um "Erro 500 - Erro Interno do Servidor - Desculpe, algo deu errado" será exibido quando o botão "Checkout" for clicado no menu lateral direito.

Errado: O usuário não pode adicionar um produto ao Carrinho, um erro é exibido.

Correto: Após o usuário abrir a página de detalhes de "Test IO - Produto 1", selecionar Tamanho: 36 e clicar no botão "Adicionar ao Carrinho", ele encontrará um banner de mensagem de erro "Erro Inesperado" no canto superior direito da PDP, e o produto não é adicionado ao Carrinho.

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

Lembre-se de que o resultado esperado não é o oposto do resultado atual com algumas variações ou palavras negativas, mas sim um campo diferente projetado para que você possa explicar tudo o que deveria ter acontecido após a última etapa para reproduzir o bug ter sido concluída.

Errado: O usuário pode prosseguir para o Checkout.

Correto: Após adicionar algum produto ao Carrinho e clicar no botão "Checkout", o usuário deve ser redirecionado corretamente para a página de Checkout, onde ele deve poder adicionar informações de envio e pagamento e fazer um pedido.

Errado: O produto deve ser adicionado com sucesso ao Carrinho.

Correto: Ao selecionar o Tamanho: 36 para o "Test IO - Produto 1" e clicar no botão "Adicionar ao Carrinho", o produto deve ser adicionado com sucesso ao Carrinho. O usuário não deve encontrar nenhum erro neste processo.

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órios de bugs.

É importante para nós e para nossos clientes 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 tem o aplicativo instalado.

Você só pode usar os dispositivos listados nesta seção para testar. Além disso, você deve selecionar apenas um dispositivo ou navegador ao relatar o bug e fazer upload apenas dos anexos para ele. Se você conseguir reproduzir o bug em outros dispositivos ou navegadores, mencione isso em seu Resultado Atual.

Selecionar o ambiente correto onde o bug ocorre é uma ação obrigatória. Ao enviar seu relatório, certifique-se de selecionar o ambiente correto. Se você acidentalmente selecionar o ambiente errado, poderá corrigi-lo depois de enviar. Você pode fazer essa correção alterando sua seleção de ambiente antes que o líder da equipe ("Team Leader") revise o relatório de bug. Se o relatório de bug contiver o ambiente errado, o TL ("Team Leader") o rejeitará durante a revisão do relatório de bug.

Você gostaria de testar com um dispositivo que não está na lista de dispositivos disponíveis em seu perfil? Basta nos enviar uma solicitação via chat de Suporte e adicionaremos seu dispositivo à sua lista, desde que seja relevante para nossos clientes.

Depois de enviar seu relatório, você ainda pode editar todos os campos, exceto o tipo de bug selecionado. Você sempre deve enviar relatórios de bug completos que estejam prontos para revisão e usar a opção de Edição apenas no caso de ter cometido um pequeno erro de digitação ou quiser reformular suas palavras para melhorar a qualidade do relatório.

Se o seu bug ocorrer apenas com alguma entrada específica, use termos que seriam usados por usuários reais e evite inserir palavras-chave aleatórias ao criar o relatório de bug ou os anexos. Um exemplo ruim seria usar um nome de usuário ao criar uma conta na interface do cliente, como “asdsdfkg_lajsdh”, pois isso faz com que seu relatório pareça não profissional.