Assumindo o código já testado (e particularmente se lançado) de maneira absoluta.
Existem várias razões para isso:
Memory - É muito improvável que o sistema esqueça o bug, qualquer desenvolvedor pode.
Métricas - O número de bugs encontrados, fechados e o tempo gasto podem ser boas métricas fáceis de capturar para informar como a qualidade do seu código está progredindo
Urgência - Pode parecer a coisa mais importante do mundo para o desenvolvedor, entretanto o tempo gasto corrigindo esse problema pode ser melhor gasto em algo que os usuários finais querem primeiro (veja também memória ).
Duplicação - Talvez ele já tenha sido visto e esteja sendo examinado / consertado por outra pessoa. Alternativamente, talvez tenha caído na falta da regra de urgência e sido adiada. É claro que o fato de você tê-lo encontrado novamente não significa apenas que não deveria ser feito, isso pode significar que (como continua aparecendo) isso é agora mais urgente para corrigir.
Análise de causa raiz - O erro mais fácil de corrigir é aquele que nunca esteve lá. Pode ser que a equipe esteja analisando esse bug para descobrir como ele surgiu. Isso é definitivo, não para punir o responsável (que nunca ajuda), mas para descobrir como a situação pode ser evitada no futuro.
Análise de impacto mais ampla - O bug mais barato para encontrar é o que você conhecia antes de encontrá-lo. Observando esse bug (particularmente após a análise da causa raiz), pode ficar claro que esse problema pode existir em outros locais do código. Como resultado, a equipe pode optar por encontrá-lo antes que ele levante sua cabeça feia em um momento mais embaraçoso.
A quantidade de tempo gasto com eles (se houver) depende muito da maturidade e do nível de qualidade do código. É provável que a análise de causa raiz seja exagerada para uma pequena equipe que trabalha com o código de demonstração, mas uma equipe grande em desenvolvimento crítico para os negócios provavelmente precisará aprender as lições de maneira eficaz e eficiente.
A partir da experiência, existem dois motivos amplos pelos quais os desenvolvedores evitam usar a ferramenta:
- A ferramenta de manipulação de bugs e / ou processo é percebida como muito pesada para o desenvolvimento
- Os desenvolvedores acham o desafio mental de consertar o bug mais interessante do que o material em que estão trabalhando atualmente.
O item 1 implica que um sistema melhor / mais simples pode ser necessário; ou, alternativamente, uma justificativa mais convincente do sistema existente pode estar em ordem.
O item 2 deve ser um sinal de alerta útil para o líder de desenvolvimento sobre alocações de tarefas atuais.