Você ainda olha para os seus bugs esquecidos no backlog?

Nathalia Freire
Inside SumUp
Published in
4 min readJul 20, 2021

Esses dias eu estava zapiando pelo Twitter, e me deparei com um tweet de outro QA dizendo: “Vocês preferem abrir um bug e ele ficar esquecido no backlog (sabendo que vai ficar) ou nem abrir?” Isso costuma acontecer com certa frequência em várias empresas, mas o que pode ser feito pra não deixar isso acontecer?

Quando eu cheguei na minha atual empresa: SumUp, tínhamos isso inclusive settado no OKR como meta a ser atingida pelo time, algo como: Como dar a visibilidade necessária para os bugs que temos de maneira a sempre priorizar os mais importantes e ter isso documentado visualmente?

Se vocês já trabalharam em fábrica de testes como eu, vão lembrar de imensos relatórios entregues ao cliente, que tinham que ser preenchidos com as quantidades de bugs encontrados, os dias que eles ficaram abertos, planilhas enormes com métricas que me dá até canseira só de lembrar. Muito documento que no fim, não era usado pra nada depois disso.

Em uma outra empresa que trabalhamos juntos, meu marido (também QA) desenvolveu uma forma de fazer um relatório totalmente visual, que fosse possível saber:

  1. As áreas mais afetadas por bugs no sistema.
  2. Quais eram as severidades dos bugs em cada uma dessas áreas.
  3. E de uma maneira que ao bater o olho é possível entender onde devemos focar a atenção

Essa ideia mudou tudo.

Beleza, mas aí como fazer acontecer?

Algo que sempre me confundiu era prioridade e severidade, como relacionar as duas coisas? Existem N definições complexas na internet, mas eu queria algo simples, uma delas, a que eu acho mais assertiva é:

Severidade: Indica o quão grave é o bug e o impacto desse bug na funcionalidade, é contornável ou não? Impacta diretamente no fluxo principal?

Prioridade: Indica a ênfase e a urgência de resolução do bug

Esse artigo aqui, ilustra bem o que eu penso sobre isso, e a verdade é que no fim, o que realmente queríamos saber é o tamanho da dor que está causando no usuário ao usar o sistema e isso define a severidade primeiro e prioridade depois.

Dado que queríamos saber onde acontecia o bug e qual o tamanho da dor, inclui dois campos novos no Jira:

Módulo e Severidade do bug

Módulo indica em qual parte, tela, api acontece o bug, se o bug acontecer em duas, escolhemos a mais relevante. Com essa informação, eu montei com a minha UX maravilhosa (Carina Bernaldo), um report assim:

Um exemplo do report que usamos com todas severidades mapeadas

Explicando a severidade e como dividimos:

No bugs found: Não há bugs nesse módulo, então essa parte do sistema está funcionando bem.

Trivial bugs found: Existem bugs, mas eles não estão no caminho feliz da funcionalidade e o bug pode ser contornado, o módulo continua funcionando sem corrigi-lo.

Minor bugs found: Existem bugs considerados de baixa importância, fora do caminho feliz do módulo e precisam ser corrigidos de alguma forma.

Major bugs found: Existem bugs considerados de alta importância para o bom funcionamento do módulo.

Critical bugs found: Existem bugs no caminho feliz do módulo e não permite que o usuário execute as tarefas principais.

Mas e aí, Nath? Na prática, eu tenho mais de um bug no módulo com diferentes severidades, o que eu faço?

Vou explicar o exemplo do módulo Cadastro aqui:

Levei em consideração o seguinte, vamos dizer que eu tenho dois bugs em cadastro com severidade: Minor e Critical, a severidade que determina a “saúde” do módulo sempre será a mais crítica, então: Critical Bugs Found.

Se esse bug Critical for corrigido posteriormente, o módulo volta pra severidade: Minor
E assim, por diante, o bug com maior severidade determina a “saúde” do módulo e a saúde e o módulo em si, determina a prioridade de correção. Lindo né? Foi assim que fizemos aqui na SumUp, pois temos uma maior rastreabilidade dos bugs e inclusive mais de um time tá usando essa técnica, e você, curtiu?

Concluindo:

Esse foi o jeito que achamos mais efetivo pra sempre olhar pros bugs e eles não ficarem esquecidos no backlog, inclui um pouco de trabalho manual, mas pra visualizar é fácil e posteriormente vc pode incluir outras informações como o número de bugs por módulo, pra ter uma idéia da quantidade de bugs que tem naquele módulo.

Está preparado para uma nova oportunidade de carreira?
Confira nossas vagas abertas e conheça mais sobre a cultura da SumUp: https://go.sumup.com/careers_br

--

--

Nathalia Freire
Inside SumUp

QA Engineer na SumUp, Geek Girl, Feminista e Gateira