Não tem jeito, uma das coisas que mais causa apreensão, medo e noites mal dormidas em um time é encontrar aquele famoso bug que ninguém faz ideia de como arrumar. Passamos por todas as fases, desde a negação até a aceitação e choro, mas não se preocupe pois nós temos a solução! Na verdade não é bem uma solução mas são passos que podem te ajudar a lidar melhor nesse momento tão difícil.

Por onde começar?

O primeiro passo é escolher uma ferramenta adequada para o reporte e gerenciamento desses bugs. Na maioria das vezes, principalmente em problemas que são reportados diretamente pelos usuários finais, não temos o passo a passo de reprodução. Ter um local apropriado para registrar essas possíveis falhas facilita a vida do Tester, já que ele(a) terá o trabalho de tentar reproduzir e identificar onde está o erro, possíveis causas e qual a sequência de ações que qualquer membro do time deve fazer para obter a falha.

No geral os reportes feitos pelos usuários são enviados pelas avaliações e comentários da Play Store ou App Store, mas também é interessante utilizar formulários de feedback ou os famosos Fale Conosco. De qualquer forma manter esses bugs reportados apenas nessas plataformas é ruim, já que o time precisa conseguir acessá-los rapidamente com todas as informações necessárias para reproduzi-los.

Existem várias ferramentas específicas de teste, que inclusive integram com repositórios ou plataformas de comunicação como o Slack, porém se você não faz nenhuma gerência de bugs atualmente o Trello é suficiente para começar e manter os status e progresso sob controle. 

Feito isso, o próximo passo é entender o quanto isso afeta o usuário. Existem diversas técnicas e métodos para classificar esses bugs em prioridade. Uma das formas de fazer isso é classificar em:

Problemas impeditivos

São bugs que impedem o usuário de seguir por um fluxo independente da entrada que ele forneça. Em suma essa é a maior prioridade dentre todas já que a pessoa não consegue finalizar um fluxo e dessa forma não é possível utilizar a feature.

Prioridade alta

São problemas que impedem uma classe importante de usuários de seguir o fluxo. Por exemplo, se sua aplicação segue por caminhos diferentes para usuários maiores e menores de idade e o fluxo para o primeiro apresenta problemas que o impedem de ser finalizado. Alguns usuários ainda conseguirão utilizar a funcionalidade, porém uma parcela muito significativa não.

Prioridade média

Bugs que não impedem o fluxo de continuar porém afetam a usabilidade ou apresentam resultados errados para o usuário. Um exemplo é: sua aplicação é um controle de estoque onde o cadastro dos itens com seus preços funciona corretamente, porém a soma dos valores totais está com o arredondamento errado – o usuário ainda consegue lançar os produtos no estoque, porém está recebendo um dado errado.

Prioridade baixa

São problemas de layout que afetam a usabilidade porém não impedem o uso. Exemplos: botão torto na tela; erro de português em algum alerta.

Melhorias

Esses NÃO SÃO BUGS, porém acabam muitas vezes sendo reportados como tais, afinal a falta de uma funcionalidade pode ser vista pelo usuário como um problema. Contudo é muito importante manter as melhorias no radar para adicionar novas features que façam sentido com o uso do produto.

Quem faz essa priorização?

Se você fizer essa pergunta para algum time ele provavelmente irá responder o Product Owner ou o Tester, porém essa atividade é muito mais eficaz se feita com todo o time! 

Ok, talvez “todo” seja uma palavra muito forte, pois seu time pode ser composto por uma quantidade muito grande de pessoas, porém é muito importante envolver outros membros nessa discussão, afinal alguém como o Designer pode acabar tendo ideias bacanas sobre como mudar a tela para deixar algo mais usual, ou o próprio Desenvolvedor pode contribuir com uma solução mais simples para o problema.

O foco deve ser sempre resolver o problema com simplicidade, afinal no mundo de desenvolvimento de software nunca teremos a certeza se o usuário vai utilizar determinada funcionalidade da forma como ela foi planejada e isso fará com que existam modificações.

Ter várias pessoas de funções diferente fazendo o trabalho de priorização ajuda a ter visões diferentes sobre um mesmo problema. Lembre-se, colaborar é muito melhor do que delegar!

Certo, mas e o que eu faço com isso?

Depois de priorizados é importante entender qual o momento do projeto. Algumas vezes temos novas features para serem adicionadas antes de uma correção de bugs e está tudo bem em fazer isso! Afinal, se fizermos os passos corretamente, saberemos qual o impacto de cada problema encontrado e com isso decidir o que de fato trará mais valor ao usuário.

Porém lembre-se que o objetivo maior é elencar quais problemas devem ser corrigidos primeiro, já que temos um limite de trabalho que conseguimos entregar por sprint. Pense na priorização como uma aliada para saber o que deve chegar na mão do usuário primeiro ao invés de esperar um grande lote de coisas de uma vez, afinal, se a abordagem for liberar uma atualização de correções apenas depois de ter corrigido tudo o que foi encontrado, nada do que fizemos aqui fez sentido!

Então é só seguir esse passo a passo e fechou?

Não! Essas são dicas para te ajudar a entender o processo de priorização mas elas não são regras soberanas do universo, lembre-se sempre de usar o contexto em que seu projeto está inserido. Pense no exemplo que eu dei anteriormente sobre uma aplicação que tem fluxos diferentes dependendo se o usuário é maior ou menor de idade.

Nesse caso se o público alvo da minha aplicação fosse apenas pessoas maiores de idade eu teria um problema impeditivo ao invés de prioridade alta, já que quase a totalidade dos meus usuários seriam dessa classe. Assim como se eu tivesse uma aplicação feita para uma escola de língua portuguesa e existisse um erro de escrita, não seria apenas um bug de prioridade baixa já que pegaria bem mal pro negócio!

Um exemplo real que vivi foi de um problema impeditivo que acontecia apenas no Android 10, porém essa versão do sistema havia acabado de lançar e segundo o console da Google Play existiam apenas 3 usuários com essa versão utilizando nosso app. Se tivéssemos usado o guia de priorização o problema estaria no máximo, porém deixamos de priorizá-lo em prol de outras correções e melhorias já que o retorno delas para o usuário seria bem maior e para bem mais gente.

Mas claro, para chegar nessa conclusão recorri ao meu time e levantamos os dados para tomar essa decisão juntos! Dessa forma todos ficam alinhados com as prioridades, objetivos e próximos passos.

Espero que você tenha gostado e não deixe de acompanhar nosso blog e redes sociais para mais tutoriais, dicas e conteúdos! 

Texto por Leonardo Kramer.