Você fez tudo certo. Você já instruiu seus testadores e agentes de controle de qualidade, e também já configurou uma ferramenta de rastreamento de bugs de fácil utilização e uma suíte de testes para seu projeto. E então tudo acontece.

Relatórios ruins de bugs acontecem com todos de nós e, infelizmente, eles podem acontecer muitas vezes. Então, nós da Usersnap juntamos nossas cabeças para pensar nos relatórios de bugs mais comuns e em maneiras para evitar esses relatórios ruins de bugs.

5 relatórios de bugs que deram errado

Então aqui estão eles. Relatórios de bugs que deram errado. Se você adotar as táticas recomendadas, pode até se apaixonar por sua equipe de gerenciamento de bugs. Eu prometo!

1. O relatório de bug que não está arquivado

Como Enzo Pietzsch, Engenheiro de Usabilidade da Jimdo declara: “O pior relatório de bugs é aquele que não foi bem arquivado”.

Não ter uma ferramenta de rastreamento de bugs em pleno funcionamento não é uma desculpa. Não ter uma ferramenta de rastreamento de bugs amigável não irá ajudá-lo também. Certifique-se de que seus clientes, colegas ou visitantes do site possam enviar relatórios de erros tão facilmente quanto possível. Não importa o quanto eles sejam esclarecidos em tecnologia. Todo mundo na equipe do projeto deve ser capaz de relatar anormalidades.

Deixe claro logo no início de um projeto como você deseja receber informações sobre bugs. Pequena dica: e-mail não é a melhor forma.

2. O relatório de erros que é arquivado por e-mail

É certo que todos nós fazemos isso. É super fácil iniciar seu cliente de email e enviar seus comentários e feedbacks para os desenvolvedores responsáveis. E então estárá feito. Bem, pelo menos você pensa assim.

Para os desenvolvedores e os responsáveis por reproduzir e corrigir bugs, lidar com relatórios de bugs por e-mail pode se tornar bastante caótico. Os e-mails não são fáceis de estruturar e priorizar. E-mails podem se perder na caixa de entrada.

Se você não tem certeza de como enviar um relatório de erros, pergunte ao gerente de projetos ou à pessoa responsável pela fase de QA (Quality Assurance – Controle de Qualidade) do projeto. Uma tonelada de tempo pode ser economizada usando as ferramentas adequadas durante testes e QA.

3. O relatório de bug que não contém informações específicas

Encontrar um bug em um site ou aplicativo web não é um motivo de alegria. Especialmente se esses bugs descobertos forem críticos para o marketing ou para os esforços do seu negócio.

No entanto, você não vai fazer nenhum bem apresentando um relatório de bugs simplesmente dizendo: “Isso não funciona”.

Há muitas outras perguntas que precisam ser respondidas a fim de resolver o problema que ocorre em seu site ou aplicativo web. O que aconteceu? Onde isso aconteceu? E muitas outras perguntas. Para mais informações em profundidade, recomendo este artigo sobre os 4 Ws de relatórios de erros.

Se há uma regra de ouro no relatório de bugs, ela provavelmente seria a seguinte: ser o mais preciso possível. Descrever o problema da forma mais específica possível irá funcionar para todos.

Caso contrário, a caixa de entrada ou a thread de bugs de seu desenvolvedor será parecida com isto:

4. O relatório de bugs que é arquivado no Twitter

Não há nada de errado em uma conversa no Twitter com seus clientes e colegas. No entanto, essas conversas no Twitter podem facilmente levar a longos papos sobre problemas em seu aplicativo web ou novas solicitações de recursos.

Tenha sempre um lugar onde bugs, problemas, solicitações de mudanças e novas ideias devem entrar. O Twitter não é o lugar certo para arquivamento, armazenamento e organização de relatórios de bugs. Certifique-se de estabelecer um terreno comum onde você deseja colaborar com relatórios de bugs e problemas.

5. Muitos relatórios de bugs, poucos recursos

Então você tem evitado todos os relatórios de bugs mencionados até agora? Bom trabalho. Aqui está um erro comum que acontece com as melhores pessoas. Você já instruiu sua equipe de QA, instalou um fluxo de trabalho de gerenciamento de bugs e seus testadores agora estão motivados para testar seu aplicativo. Bom trabalho.

No entanto, não se esqueça dos recursos de correção de bugs e desenvolvimentos presentes na outra extremidade também. Tente criar um fluxo de trabalho de gerenciamento de bugs interativo e flexível. Caso contrário, os recursos de desenvolvimento serão parecidos com isto:

Como resolver o problema de relatórios de bugs?

Desenvolvedores responsáveis ​​consideram outras coisas mais úteis para reproduzir e corrigir bugs do que a maioria dos relatórios simples de bugs.

A apresentação de um relatório de bug é um processo bastante demorado, o que significa que ela não está na agenda da maioria dos visitantes do site ou dos membros da equipe. Então, o que fazer? Especialmente quando se trabalha com equipes menores, uma abordagem ágil para acompanhamento de bugs é fundamental.

1. Realizar testes alfa e beta abrangentes antes de ir para a produção: testar seu aplicativo ou site durante o desenvolvimento não só poupa-lhe uma tonelada de tempo após o lançamento, mas também impede que você falhe em alguma coisa.
2. Obter cada membro da equipe a bordo e aumentar a consciência: acompanhar o erro significa fazer perguntas. Se você se deparar com uma anormalidade durante o design, a prototipagem ou a fase de desenvolvimento do seu projeto, simplesmente comece a fazer perguntas. Quanto mais perguntas são respondidas durante o desenvolvimento, menos erros serão enviados para o ambiente de produção.
3. Encontrar uma forma de testar em comum: antes de começar a testar seu site ou aplicativo, certifique-se de encontrar uma ferramenta comum que é usada para os erros de rastreamento mais básicos. Idealmente, você está usando uma ferramenta de rastreamento de bugs fácil de usar, como Usersnap, para todas as suas atividades de rastreamento de bugs.

***

Thomas Peham faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://usersnap.com/blog/bad-bug-reports-examples/