Fluxo de triagem: do susto ao sensor de regressão

O caminho que o TriageBug impõe a cada bug — reproduzir, isolar, corrigir e provar — e por que o último passo é o que impede o retorno.

O TriageBug troca o palpite por um fluxo. Cada bug atravessa quatro estações, e nenhuma pode ser pulada sem deixar a caça incompleta.

1. Reproduzir de forma determinística

Antes de qualquer correção, o bug precisa ser provocado sob demanda. Um bug que só aparece “às vezes” é um bug que não se entende ainda. A reprodução determinística transforma o fenômeno em um caso concreto, com entradas e condições conhecidas.

2. Isolar a causa

Com o caso reprodutível em mãos, a triagem reduz o espaço de busca até a causa real — não o sintoma mais próximo. É aqui que a voz operacional vale ouro: separar o que é urgente do que é recorrente e do que só parecia relacionado.

3. Corrigir

A correção vem depois de entender, não antes. Mexer no código sem o caso reprodutível é apostar; com ele, é engenharia. A mudança é mínima e dirigida à causa isolada na estação anterior.

4. Provar com um sensor de regressão

O passo que quase todo time pula. Encerrar a caça significa criar uma verificação que reproduzia o bug e que agora passa — e que voltará a falhar se o bug retornar. É esse sensor, e não o alívio momentâneo, que responde à pergunta “será que acabou?”. A resposta deixa de ser sentimento e vira um resultado repetível.