O que é a gestão de defeitos? Severidade, prioridade e os estados pelo meio

A gestão de defeitos é o que acontece a um erro entre alguém dar por ele e alguém confirmar que desapareceu. É um processo, não uma ferramenta: os estados por que um defeito passa, quem o faz avançar e como a equipa decide quais são corrigidos primeiro.

A maioria das equipas tem um, quer o tenha escrito quer não. A versão não documentada costuma ser “põe no tracker e espera”, o que funciona até haver mais defeitos do que alguém consegue guardar na cabeça - tipicamente uns trinta.

O ciclo de vida

Os estados têm nomes diferentes em cada tracker, e a forma por baixo é a mesma.

• Novo. Relatado, ainda ninguém lhe pegou.
• Triado. Alguém o leu, confirmou que é real e decidiu quão urgente é.
• Atribuído. Tem um responsável.
• Corrigido. O responsável acredita que está feito. Mais ninguém acredita em nada ainda.
• Verificado. Alguém que não é o responsável confirmou-o face ao relato original.
• Fechado. Terminado.

Há outros dois finais legítimos e muitas vezes mal tratados. Rejeitado significa que não é um defeito: o comportamento é intencional, ou o relato descrevia um mal-entendido. Adiado significa que é real e que não vai ser corrigido agora. Ambos precisam de um motivo escrito no ticket, porque a alternativa é o mesmo defeito ser relatado outra vez daqui a seis semanas por alguém que não tem como saber que já tinha sido considerado.

O passo que as equipas saltam em silêncio é a verificação. Um defeito fechado pela pessoa que o corrigiu é um defeito fechado sobre a opinião de uma só pessoa, e a correção que afinal não cobria o caso relatado é uma experiência suficientemente comum para ter o seu próprio problema de reprodução.

Severidade e prioridade não são a mesma coisa

Esta é a confusão que vale a pena esclarecer, porque causa discussões que parecem desacordos sobre o defeito mas são na verdade duas pessoas a usar uma palavra para duas ideias.

A severidade é o quão mau é o comportamento. Perder dados é grave. Um ícone desalinhado não é. É uma propriedade do próprio defeito e não muda porque o calendário mudou.

A prioridade é o quão cedo é corrigido. Isso é uma decisão de negócio, e depende de quem é afetado, de quantos, de haver ou não uma solução alternativa e do que mais compete pela mesma semana.

As duas separam-se nos dois sentidos, e é isso que torna útil distingui-las:

Severidade alta, prioridade baixa

Uma falha num ecrã de administração usado duas vezes por ano por uma pessoa que conhece a solução alternativa

Severidade baixa, prioridade alta

O nome da empresa mal escrito na página de preços, visto por toda a gente, corrigido esta manhã

Os trackers que oferecem apenas um campo obrigam a fazer a média dos dois num número que não significa nenhum. Se o vosso faz isso, digam qual dos dois representa e deixem-no escrito, porque caso contrário metade da equipa ordena por dano e a outra metade por urgência.

Quem tria, e com que frequência

A triagem é uma decisão, por isso precisa de alguém com autorização para a tomar. Numa equipa pequena é uma pessoa a percorrer a fila dos novos todas as manhãs. Numa maior é uma reunião curta e recorrente com um programador, um tester e alguém que fale pelo produto.

O que importa mais do que o formato é ser regular. Uma fila triada quando alguém se lembra acumula uma cauda de defeitos que ninguém leu, e o custo disso não é a cauda por tocar: é que ninguém confia mais na fila, por isso os defeitos reais passam a ser relatados no chat.

A triagem precisa de três respostas por defeito, e não mais: é real, quão mau é, de quem é. Qualquer coisa mais longa é trabalho de desenho a acontecer na reunião errada.

Os relatos decidem a que velocidade o processo corre

Cada estado depois de “novo” depende de quão bom foi o relato.

A triagem não consegue julgar a severidade sem saber o que aconteceu de facto. O responsável não consegue corrigir aquilo que não consegue reproduzir. A verificação não consegue confirmar nada se os passos originais já não estiverem escritos. Um relato vago não custa apenas os cinco minutos de quem o escreveu: custa uma ida e volta em cada fase, e cada ida e volta é um dia.

É aqui que vai a maior parte do tempo. Não a corrigir, a perguntar outra vez.

O nosso guia do relatório de erro tem a forma que sobrevive à triagem: o que aconteceu, o que era esperado, os passos e o ambiente. Peçam essas quatro coisas e a maior parte das idas e voltas deixa de acontecer.

Métricas que enganam

Três números são contados por serem fáceis de contar, e cada um merece ser lido com cuidado.

• Número de defeitos abertos. Sobe quando os testes melhoram, que é o contrário do que parece. Cair a zero significa mais vezes que as pessoas deixaram de relatar do que que o software melhorou.
• Defeitos por programador. Premeia quem mexe em menos código. Não o façam.
• Tempo até fechar. Útil, mas mede o processo tanto como o trabalho: uma semana à espera que quem relatou responda a uma pergunta conta como uma semana de depuração.

A que vale mesmo a pena acompanhar é a taxa de reabertura: defeitos marcados como corrigidos que voltaram. É uma medida direta de se “corrigido” significa alguma coisa na vossa equipa e, ao contrário das outras, é difícil de manipular.

A versão curta

Seis estados, um motivo escrito para tudo o que for rejeitado ou adiado, e uma verificação feita por alguém que não seja quem corrigiu. A severidade é quão mau, a prioridade é quão cedo, e são campos diferentes. Triagem com horário em vez de quando alguém se lembra. E a maior parte do tempo poupado é poupada no início, no relato: um defeito que chega completo atravessa todo o processo sem que ninguém tenha de fazer uma pergunta.