Como escrever um relatório de erros (+ transferência gratuita de modelo)

Saber como criar um relatório de erros eficaz é uma parte importante do trabalho de um testador de software para manter a garantia de qualidade, por isso passamos muito tempo a registar erros nas nossas ferramentas de acompanhamento de erros. Encontrar um erro pode ser entusiasmante, especialmente se for um cenário interessante. Mas a forma como o reportamos pode ser tão importante como o seu impacto no sistema.

Um relatório de erros mal redigido pode causar muitos atritos entre os membros da equipa, nomeadamente entre os testadores e os programadores, o que pode criar obstáculos à correção dos erros e, em última análise, prejudicar a experiência do utilizador.

Neste artigo, vou partilhar informações essenciais, como:

• Dominar os relatórios de erros: Aprenda os elementos essenciais que todos os relatórios de erros eficazes devem incluir para simplificar a comunicação e acelerar as correções.
• Promover a harmonia da equipa: Descubra como os relatórios de erros bem redigidos evitam atritos entre testadores e programadores, conduzindo a fluxos de trabalho mais simples.
• Modelo gratuito para descarregar: Obtenha um modelo gratuito de acompanhamento de erros, pronto a descarregar, para dar início ao seu processo eficiente de elaboração de relatórios de erros.

Elementos essenciais de um relatório de erros

Independentemente do tipo de aplicação que está a testar, seja uma aplicação de ambiente de trabalho, Web, móvel ou um projeto de API, existem alguns elementos essenciais que todos os bons relatórios de erros devem incluir. A maioria dos programas de acompanhamento de erros disponibiliza campos para estes elementos, incluindo:

• ID: Se estiver a utilizar uma ferramenta de gestão de projetos, como o Jira, será atribuído automaticamente um ID a quaisquer novos problemas abertos. Também existem ferramentas de gestão de testes para o Jira para o acompanhamento de erros
• Título/Descrição: Esta é uma breve descrição do problema. Deve ser suficientemente concisa para ser fácil de ler, mas suficientemente descritiva para que os outros possam compreender onde reside o problema. Por exemplo, “a ordenação dos itens por preço não funciona quando é aplicado um filtro.” 
• Passos para reproduzir: Inclua aqui o maior número possível de detalhes relevantes. Certifique-se de que qualquer pessoa que tente reproduzir o problema ou verificar a correção o consegue fazer apenas seguindo os passos. Não omita passos por assumir que todos saberão implicitamente que devem realizar determinadas ações, mesmo que estas não estejam mencionadas; inclua-as no relatório de erros. 
• Resultados esperados: Mais uma vez, não parta do princípio de que as pessoas já sabem como a aplicação deve funcionar. É claro que, se for apresentada uma exceção na interface de utilizador quando prime um botão, sabe que isso não é esperado. No entanto, eu não diria que o resultado esperado é “a exceção não é lançada”, mas sim a ação que o botão deve executar, ou seja, “a caixa de diálogo das definições é aberta.”
• Resultados reais: Isto é autoexplicativo — deve descrever o que acontece na aplicação depois de serem executados todos os passos para reproduzir o problema.
• Gravidade: Representa o impacto que o erro tem no AUT.
• Prioridade: A rapidez com que o erro deve ser corrigido. Uma prioridade mais elevada significa que o erro deve ser colocado numa posição superior na lista de pendências e corrigido mais rapidamente.

Outras informações importantes a incluir 

Para além dos elementos mencionados acima, podem ser relevantes outras informações, especialmente ao introduzir dados numa ferramenta de elaboração de relatórios de erros. Estas informações podem depender do tipo de projeto, dos requisitos do projeto ou até do próprio erro:

• Versão do software: O número da compilação em que o erro foi identificado. Isto pode ajudar a isolar as compilações onde o problema foi potencialmente introduzido e a identificar o código que o causou.

• Anexos: Estes podem nem sempre ser necessários ou estar disponíveis, mas normalmente acrescentam muito valor. Considere fornecer capturas de ecrã ou gravações do problema encontrado, ficheiros de registo, rastreios da pilha, pedidos e respostas de rede, etc. 
• Dados de teste: Por vezes, os erros que encontramos só são reproduzidos para conjuntos específicos de dados. Se for esse o caso, certifique-se de que os inclui, quer nos passos para reproduzir o problema (por exemplo, “iniciar sessão com o utilizador andreea@theqalead.com”), quer num campo específico da ferramenta de acompanhamento de erros.
• Detalhes do ambiente: Se o erro só for reproduzido num sistema operativo, navegador ou ambiente de desenvolvimento específico, mencione-o.  

Sugestões para criar um bom relatório de erros

• Limite-se a um único erro por relatório. Se descobrir mais erros nas mesmas áreas, pode associá-los ao seu sistema de acompanhamento de problemas. Incluir mais do que um defeito pode causar confusão e atrasos na eventual correção dos erros.
• Verifique o seu sistema de acompanhamento para garantir que o erro ainda não foi comunicado. Se já estiver aberto, adicione quaisquer detalhes relevantes que tenha descoberto e que não tenham sido incluídos no relatório de erro original.
• Tente reproduzir o erro mais do que uma vez. Pode tentar encontrar a forma mais rápida de o reproduzir (utilizando o menor número possível de passos).
• Não se perca em detalhes irrelevantes. O relatório de erro e os passos devem ser fáceis de ler e seguir.
• Não faça suposições sobre a razão pela qual o erro ocorre (a menos que tenha 100% de certeza de que sabe o que o causou).

Modelo de relatório de erros

Agora, gostaria de partilhar consigo alguns modelos de relatórios de erros. Pode copiá-los ou modificá-los de acordo com as necessidades do seu projeto.

Modelo de acompanhamento de erros do Jira

O Jira é uma ferramenta de acompanhamento de problemas muito comum da Atlassian. Se a sua equipa o utilizar, o tipo de problema relativo a erros provavelmente já estará configurado. Como testador ou gestor de uma equipa de desenvolvimento de software, pode configurar um fluxo de trabalho de acompanhamento de erros para o ciclo de vida dos erros (esta capacidade é uma das muitas vantagens do software de acompanhamento de problemas). 

Também pode adicionar campos personalizados no Jira, por exemplo, para o ambiente ou um campo exclusivo onde seja adicionada a funcionalidade testada. Ou pode adicionar uma descrição predefinida com todas as informações que pretende incluir em cada relatório de erro. Eis um que criei:

Agora, quando quiser criar um novo erro, terei estas informações pré-preenchidas. Eis o meu modelo de erro no Jira, utilizando campos personalizados e uma descrição predefinida:

Contém as informações essenciais que dissemos que o erro deve incluir:

• Um título (“Erro de exemplo”)
• Na descrição: as pré-condições, os passos para reproduzir o erro e os resultados esperados e reais
• Um campo personalizado para o ambiente
• Uma gravidade e uma prioridade, selecionadas em menus pendentes com valores predefinidos
• Deixei o responsável vazio. Dependendo das convenções do seu projeto, os novos erros podem ser atribuídos automaticamente a um membro específico da equipa ou a pessoa que começar a trabalhar neles pode atribuí-los a si própria
• Uma etiqueta — pode ser útil, por exemplo, se quiser acompanhar qual a funcionalidade afetada
• Uma data-limite — pode não ser preenchida até que a lista de pendências tenha sido priorizada
• O autor do relatório (que, neste caso, é preenchido automaticamente com o utilizador do Jira que criou o erro)

Opcionalmente, o Jira dispõe de várias integrações e o erro pode ser associado a casos de teste, ramificações do Git ou até pedidos de integração.

Também pode utilizar o seu modelo de acompanhamento de erros como modelo de projeto se apenas precisar do Jira para o acompanhamento de defeitos e não trabalhar num ambiente ágil.

Modelo de acompanhamento de erros no Excel

Algumas equipas podem utilizar folhas de cálculo para o seu sistema de acompanhamento de erros. Considero-as úteis para projetos muito pequenos, nos quais configurar uma ferramenta de acompanhamento de problemas simplesmente não vale a pena, ou para comunicar erros em novas funcionalidades que ainda estão em desenvolvimento. 

Pode utilizar o Google Sheets/Docs ou o Microsoft Excel/Word — de qualquer forma, um modelo de erro pode ter este aspeto:

As colunas refletem as informações que o relatório deve conter:

• O ID (o Excel saberá como aumentar automaticamente o valor sempre que for adicionada uma nova linha)
• Um título
• As etapas para reproduzir
• Os resultados esperados e reais
• O nome do autor do relatório
• A gravidade e a prioridade do erro — aqui, usei menus pendentes porque os valores devem estar predefinidos
• Ambiente
• Informações adicionais: isto destina-se a qualquer outro aspeto digno de nota que não se enquadre nas restantes colunas

Considerações finais

Elaborar um bom relatório de erro de software é uma competência essencial para os testadores de software, por isso preste especial atenção às práticas recomendadas explicadas acima. Também pode basear-se nos exemplos de modelos de acompanhamento de erros que forneci. Estes podem ser adaptados às diferentes ferramentas que utiliza, como o Trello ou o Asana.

Se gostou deste conteúdo, subscreva a newsletter da The QA Lead para se manter a par de mais novidades e tendências no processo de testes de software!