A vida de um bug: de 'novo' a 'fechado' sem se perder no caminho

Um defeito não se conserta: se gerencia. Essa é a resposta curta para explicar por que existe um ciclo de vida do bug. Quando um tester encontra uma falha, não basta avisar e esperar que alguém a corrija. O defeito entra em um fluxo de estados com regras claras: quem é o responsável, o que se espera dessa pessoa, e quando pode ser considerado realmente fechado. Pular esse fluxo é a forma mais comum de um bug marcado como "consertado" reaparecer em produção duas semanas depois.

O ciclo de vida de um defeito é, no fundo, um contrato entre três papéis: quem reporta, quem corrige e quem verifica. Cada estado do defeito diz de quem é a bola neste momento. Se ninguém sabe de quem é a bola, o defeito fica flutuando, e os defeitos que flutuam são os que chegam ao cliente.

01 · o mapaO que é o ciclo de vida e por que existe

O ISTQB define um defeito como uma imperfeição em um componente ou sistema que pode fazer com que ele não cumpra sua função requerida. A gestão de defeitos, segundo seu glossário, é o processo de reconhecer, registrar, classificar, investigar, resolver e dispor dos defeitos [1]. Essa lista de verbos já é, quase palavra por palavra, o ciclo de vida: cada verbo corresponde a um estado pelo qual o defeito passa.

A razão de fundo é simples. Um defeito solto não tem dono nem memória. Um defeito dentro de um fluxo de estados sempre tem um responsável atual e um histórico de por onde passou. Isso transforma uma reclamação informal em uma unidade de trabalho rastreável, que se pode medir, priorizar e auditar.

Cada estado do defeito responde uma única pergunta: neste exato momento, de quem é a bola?

Convém não confundir duas coisas que soam parecidas. A severidade mede quanto dano o defeito causa ao sistema. A prioridade mede com que urgência ele deve ser corrigido do ponto de vista do negócio. Um erro de digitação no logo pode ser de severidade baixa, mas prioridade alta se aparecer na capa amanhã. O ciclo de vida é independente de ambas: um defeito trivial e um crítico percorrem os mesmos estados, apenas em velocidades diferentes.

02 · os estadosDe 'novo' a 'fechado', passo a passo

Os nomes exatos mudam entre ferramentas como Jira, Bugzilla ou Azure DevOps, mas o esqueleto é quase universal. Estes são os estados que vale a pena entender.

Novo. O defeito acaba de ser reportado. Aqui se joga metade da partida: um bom relatório traz passos para reproduzir, resultado esperado, resultado obtido, ambiente e evidência. Um relatório pobre condena o defeito a ficar quicando em "preciso de mais informação" por dias.

Atribuído. Alguém, quase sempre um líder técnico ou de QA, verifica que o defeito é válido e o atribui a quem deve corrigi-lo. Aqui a bola passa de QA para desenvolvimento.

Em andamento. A pessoa desenvolvedora está trabalhando na correção. O defeito tem dono e está em movimento.

Resolvido. O código já foi corrigido, mas atenção: resolvido não é fechado. É uma afirmação de uma parte que a outra ainda não comprovou. A bola volta para QA.

Verificado. QA executa o cenário de novo e confirma que o defeito não ocorre mais. Esta é a linha que separa o testing sério do "confia em mim, já consertei".

Fechado. O defeito é dado como concluído. Só se chega aqui depois de verificar, não antes.

03 · o ponto críticoPor que a verificação não é opcional

O momento mais frágil do ciclo é o salto de "resolvido" para "fechado". É tentador fechar assim que o desenvolvimento diz que está pronto, sobretudo quando a data de entrega aperta. Mas fechar sem verificar quebra o contrato inteiro. Um defeito resolvido é uma hipótese; um defeito verificado é um fato.

A distinção conecta com algo maior: a diferença entre verificar e validar. Verificar responde "corrigiu-se o que dissemos que corrigiríamos?". Validar responde "isto resolve o problema real do usuário?". O fechamento de um defeito é, em miniatura, um ato de verificação, e por isso não pode ser pulado pela pessoa que fez a correção.

Há uma razão adicional para levar esta etapa a sério: a correção de um defeito pode introduzir outro. É o que se chama de defeito de regressão. Por isso uma verificação madura não apenas comprova que o bug original desapareceu, mas também revisa que nada próximo foi quebrado na tentativa. É aí que a gestão de defeitos se conecta com a estratégia de testes de regressão.

04 · o quadroO que mede um ciclo saudável

Quando o ciclo de vida funciona, o quadro de defeitos começa a contar coisas úteis. A taxa de reabertura revela se as correções aguentam ou se fecham em falso. O tempo em cada estado mostra onde os defeitos travam: se vivem dias em "novo", o problema é a triagem; se vivem dias em "resolvido", o gargalo é a verificação. A densidade de defeitos por módulo aponta qual parte do produto concentra o risco.

Nada disso é possível sem estados disciplinados. Um defeito que salta direto de "novo" para "fechado" não deixa rastro para medir. O ciclo de vida não é burocracia: é a condição para que a equipe aprenda com os próprios erros em vez de repeti-los.

Da próxima vez que alguém disser "já consertei o bug", vale a pena perguntar em que estado ele está. Se a resposta for "resolvido", o trabalho ainda não terminou. Só quando alguém diferente de quem o corrigiu olha de novo, executa o cenário e confirma que a falha se foi é que o defeito pode passar de novo a fechado sem se perder no caminho.