Todo bug encontrado em um projeto percorre um caminho previsível. Registrar esse caminho em estados bem definidos evita a pergunta mais comum de qualquer time: “esse bug já foi corrigido ou não?”. O fluxo abaixo mostra a jornada completa de um defeito, da abertura ao fechamento.

A ideia central: um bug só sai do ciclo quando o QA — e não o desenvolvedor — confirma que ele foi resolvido. Enquanto isso não acontece, ele continua circulando.

🔄 Etapas sugeridas

1 NOVO

Bug recém-identificado e registrado no sistema.

2 ATRIBUÍDO

Bug foi direcionado a um desenvolvedor para análise.

3 ABERTO

O desenvolvedor iniciou a correção.

4 CORRIGIDO

Correção aplicada e enviada para testes.

5 AGUARDANDO RETESTES

QA precisa validar se o bug foi realmente resolvido.

6 VERIFICADO

QA confirmou que o bug foi corrigido com sucesso.

7 PERSISTÊNCIA DO BUG

Bug persiste e é encaminhado de volta ao início.

8 FECHADO

Ciclo encerrado, bug resolvido e validado.

📋 Resumo em tabela

StatusO que significaQuem age
NovoBug recém-identificado e registrado no sistemaQA
AtribuídoBug direcionado a um desenvolvedor para análiseLíder técnico
AbertoO desenvolvedor iniciou a correçãoDev
CorrigidoCorreção aplicada e enviada para testesDev
Aguardando retestesQA precisa validar se o bug foi resolvidoQA
VerificadoQA confirmou que o bug foi corrigido com sucessoQA
Persistência do bugBug persiste e volta ao início do fluxoQA
FechadoCiclo encerrado, bug resolvido e validadoQA

↩️ O laço de reabertura

O detalhe mais importante do fluxograma não é a linha reta que vai de A Fazer até Concluído — é a seta de retorno. Quando o reteste falha, o bug entra em Persistência do Bug e volta para A Fazer, reiniciando o ciclo.

Esse laço é o que garante que nada seja dado como pronto sem validação. Um bug pode percorrer o caminho várias vezes, e isso não é um problema do processo: é o processo funcionando. O que seria um problema é um defeito ir direto de “Corrigido” para “Fechado” sem passar pelo QA.

✅ Conclusão

Um ciclo de vida bem definido transforma o tratamento de bugs em algo rastreável. Cada status responde a três perguntas objetivas: em que pé está, de quem é a bola agora e o que precisa acontecer para avançar. Com isso, o time para de gastar tempo alinhando status em reunião e passa a ler essa informação direto do board.