Boas práticas no report de bugs

Um problema de comunicação que pode ser evitado.

Published in

Revista eQAlizando (antiga Revista TSPI)

6 min readJun 23, 2020

A foto mostra uma joaninha, um inseto nas cores laranja e preta, em cima de uma folha verde. — Photo by Haley Photography on Unsplash

É sabido por 99,9% dos profissionais que trabalham no contexto de desenvolvimento de software que nenhum sistema está livre de inconsistências, vulgo bugs.

Relatar um bug de maneira efetiva aumenta as chances dele ser solucionado, pois todos os dados necessários para reproduzir a situação estão lá e não é necessário que o desenvolvedor entre em contato com quem registrou a inconsistência para tirar alguma dúvida, o que causa a perda de concentração para ambas as partes.

Segundo um artigo da Exame, um ser humano leva cerca de 15 minutos para se concentrar em alguma atividade, após ela ter sido interrompida. Então vamos eliminar essa possibilidade de interrupção no nosso time com um bug report efetivo?

Obs: As palavras bug e inconsistência serão utilizadas como sinônimos para não soar muito repetitivo.

Antes de registrar um bug…

Antes de registrarmos um bug precisamos ter a certeza de que ele realmente é uma inconsistência ou se foi causado devido a uma instabilidade esporádica no sistema:

Reproduza a inconsistência pelo menos três vezes antes de registrá-la;
Verifique se houve problemas com serviços terceirizados que afetam o sistema, tais como serviço de CDN, serviço de cacheamento, serviços de cloud em geral;
Identifique o ambiente, isso ajuda na priorização da correção. Bugs identificados em produção tendem a ter maior prioridade do que os encontrados em ambientes de testes. E, caso um bug seja encontrado no ambiente de testes, verifique se ele também ocorre em produção;
Verifique se essa inconsistência já foi registrada por outro membro do time.

Informações indispensáveis

1. Número identificador

Ter um identificador facilita a localização do bug. Em grandes times de desenvolvimento, onde várias inconsistências são registradas, o cenário seria caótico caso muitas inconsistências sem identificação fossem registradas.

2. Descrição breve e objetiva

O problema precisa ser entendido com poucas palavras, porém com todas as informações pertinentes. É bom evitar redações e prolixidades.

Como não deve ser registrado: Os usuários do nosso sistema não conseguem fazer o login.
Como deve ser registrado: Na tela de login da plataforma, o campo username sobrepõe o campo senha, impossibilitando aos usuários do sistema de realizarem o login.

3. Passos para a reprodução

É literalmente o passo a como de como reproduzir a inconsistência, levando em consideração todo o contexto que envolve o software: rede, versão do sistema, ambiente, etc.

Como não deve ser feito: Acesso o site da plataforma, tento realizar o login e não consigo.
Como deve ser feito:
1. Acessar o site da plataforma;
2. Preencher o username com um nome de usuário válido;
3. O campo senha não pôde ser preenchido porque o campo username o sobrepõe.

Nesta etapa é legal informar também qual seria o resultado esperado, ou seja, como o software se comportaria caso este bug não existisse.

4. Evidências

“E nessa loucura de dizer que não te quero
Vou negando as aparências
Disfarçando as evidências…”

As evidências são importantes para comprovar a existência do bug e geralmente são anexadas ao bug report. O que você pode utilizar como evidência:

Prints de tela (screenshots);
Gravações de tela, onde você reproduz a inconsistência;
Para sistemas web, erros que podem ser observados no console do navegador (ajuda bastante):

A imagem mostra um erro no console do navegador.

Logs (ajuda muuuuito): caso o sistema com o qual você trabalhe possua alguma ferramenta de log integrada, provavelmente quando ocorrer algum bug, um log informando essa inconsistência será registrado. Onde atuo, essa ferramenta de log é integrada ao Slack, então não é difícil de achar essa informação.

5. Informações adicionais

São informações que também são importantes para identificar a causa do bug, tais como:

Versão da aplicação;
Ambiente (teste, beta1, beta2, produção…);
Versão do navegador (para aplicações web);
Tipo de navegador (chrome, firefox, safari…);
Horário em que ocorreu a inconsistência (ajuda na localização de logs);
Qualquer outra informação que seu time julgue importante.

6. Prioridade

Alta: precisamos corrigir a inconsistência hoje!
Média: beleza, vamos corrigir até o final da sprint.
Baixa: de boas, podemos corrigir no futuro.

7. Severidade

Alta: quando o usuário não consegue sair da situação onde o bug ocorreu, quando, por exemplo, o sistema trava de vez;
Média: o usuário não consegue sair da tela, mas clicando em determinado lugar, ele consegue continuar utilizando o sistema;
Baixa: é uma inconsistência, mas não machuca ninguém.

8. Antes de confirmar o registro

Leia novamente toda a descrição do bug antes de registrá-lo, a fim de verificar se não falta nenhuma informação relevante;
Não usar linguagem abusiva, onde você culpa indiretamente alguém pela ocorrência da inconsistência.

Dica de ouro

Sempre vincule o título da inconsistência ao impacto que ela causa nos usuários e informe na descrição se outras áreas da aplicação são afetadas pelo mesmo problema, pois isso ajuda na priorização de sua correção!

Exemplo: Usuários de perfil A (40% da base) não conseguem realizar transferências bancárias.

Imaginem um analista de negócios ou um PO lendo o título desse bug…

Maus costumes

Thomas Pehan, em um artigo do Usersnap, descreveu de forma bem divertida cinco situações onde, segundo ele, “bug reports ruims acontecem com boas pessoas”:

Um bug report sem evidência;
Um bug reportado via e-mail;
Um bug sem informação específica (como no exemplo do login citado anteriormente);
Um bug reportado via twitter;
Muitos bugs, pouco recurso humano: esse ponto está relacionado a gestão do ciclo de vida do bug, onde quando mal implementado não há vazão da correção das inconsistências.

Templates

Gary Gaspar escreveu um artigo no blog da Maker, onde ele dá exemplos de como reportar inconsistências em diversas ferramentas utilizadas no mercado, tais como o Jira e o Trello. Vale a pena dar uma conferida!

Inconsistências x Melhorias

É importante ter clareza de como diferenciar inconsistências de melhorias. Um bug ocorre quando a expectativa conhecida por todos os membros do time perante o comportamento da aplicação é quebrada de alguma forma, seja através dos documentos de especificação do sistema ou pelo consenso do próprio time. Uma melhoria é identificada quando esse mesmo comportamento não atende a expectativa de quem a encontrou.

Por exemplo, testando o login do sistema eu percebi que, após colocar os dados necessários para realizar o login, o sistema leva cerca de 5 segundos até que a página inicial seja apresentada. Logo, pelos padrões de mercado que conheço, essa seria uma inconsistência, pois o tempo ideal seria abaixo de 2 segundos.

Fui falar com o time e nenhum membro identificou o comportamento como inconsistência, pois não havia documentação da funcionalidade informando que o tempo ideal do login deveria ser abaixo de 2 segundos e tampouco o time acredita que isso seja uma inconsistência. Logo, o comportamento identificado é uma melhoria e, algum dia, quando o time acreditar que ela deva ser feita, ela será desenvolvida.

Porém, se o time acreditar que esse comportamento realmente está incorreto, logo ele será classificado como uma inconsistência.

Conclusão

É muito importante que todos os profissionais que registrem inconsistências se atentem aos mínimos detalhes sobre o bug encontrado e que tenham em mente que toda e qualquer informação adicional pode acelerar a correção do problema. E quem fica feliz com isso? Todo mundo!

O cliente por ter seu problema resolvido (caso tenha sido ele quem tenha encontrado o bug);
O time por ter a sensação de “dever cumprido” e um bug a menos para se preocupar;
A área de negócios, pois um bug a menos é um motivo a menos para o churn de clientes da base;
A área financeira da empresa, pois se formos contabilizar em horas o tempo despendido para tentar entender um bug mal relatado, além dos impactos com a perda de concentração… a conta nem sempre sairia barata!

Então galera, vocês já relatam os bugs com todas, ou pelo menos a maior parte, das informações necessárias? Acreditam que algum ponto pode ser adicionado nesse checklist que apresentei? Deixem nos comentários, vamos conversar mais sobre o assunto! #hugs