Ciclo de Vida do Bug (STLC)

Objetivo: Definir os estágios pelos quais um defeito passa, desde a sua descoberta até o seu fechamento definitivo, garantindo rastreabilidade e clareza no processo.

O ciclo de vida de um bug (Bug Life Cycle) é o conjunto de estados que um problema atravessa. Padronizar esses estados ajuda o time a entender rapidamente o que precisa de ação imediata.

Fluxo de Trabalho (Workflow)

Abaixo estão os estados padrão que utilizamos para gerenciar as falhas:

1. Novo (New): O bug foi reportado, mas ainda não foi analisado pelo time de desenvolvimento.

2. Em Análise (In Progress/Assigned): Um desenvolvedor está investigando a causa raiz do problema.

3. Corrigido (Fixed): O desenvolvedor aplicou a correção e o código já está em ambiente de teste (HML/Staging).

4. Pronto para Teste (Ready for QA): O bug está aguardando a validação oficial do QA.

5. Reaberto (Reopened): O QA testou a correção, mas o bug persiste ou gerou um novo problema.

6. Fechado (Closed): O bug foi validado com sucesso e não existe mais.

---

Estados de Exceção

Nem todo bug reportado segue para correção imediata. Existem casos especiais:

• Rejeitado (Rejected): O comportamento reportado não é um erro, mas sim o funcionamento esperado do sistema.

• Duplicado (Duplicate): O erro já foi reportado em outro ticket.

• Adiado (Deferred): O bug é real, mas por prioridade de negócio ou técnica, será corrigido em uma versão futura.

• Não Reproduzível (Not Reproducible): O time não conseguiu replicar o erro com as informações fornecidas.

---

Representação Visual do Fluxo

B[Em Análise] B --> C[Corrigido] C --> D[Pronto para Teste] D --> E{QA Validou?} E -- Não --> F[Reaberto] F --> B E -- Sim --> G[Fechado] B -- Não é bug --> H[Rejeitado] B -- Já existe --> I[Duplicado] ]]>

---

Boas Práticas ao Reportar um Bug

Para que o ciclo de vida seja ágil, todo bug reportado deve conter:

• Título Claro: Resumo direto do problema.

• Passo a Passo: Como chegar ao erro (Ex: 1. Abrir tela X; 2. Clicar em Y...).

• Resultado Esperado vs. Resultado Atual: O que deveria acontecer e o que aconteceu.

• Evidências: Prints, vídeos ou logs (essencial para bugs intermitentes).

• Ambiente: Onde o erro ocorreu (iOS, Android, Chrome, Produção, HML).

---

💡 Por que isso é importante?

• Métricas: Conseguimos medir quantos bugs são reabertos (indicador de qualidade da correção).

• Agilidade: Diminui o tempo de conversa "vai e volta" entre Dev e QA.

• Transparência: O PO consegue ver quantos bugs impedem o lançamento de uma funcionalidade.