O que acontece com o relatório de bug se ele não foi corrigido?

Se um relatório de erro não for corrigido, ele passa pelas seguintes etapas no seu ciclo de vida:

• Aberto (Open): O relatório de erro é criado e entregue à equipa de desenvolvimento.
• Atribuído (Assigned): A tarefa de corrigir o erro é atribuída a um desenvolvedor ou equipa específica.
• Rejeitado (Rejected / Declined): O erro pode ser rejeitado por várias razões:
  • Não é um erro (Not a Bug): O comportamento descrito é funcional esperado.
  • Duplicado (Duplicate): O erro já foi registado anteriormente.
  • Impossível de reproduzir (Cannot Reproduce): Não é possível reproduzir o erro com os passos fornecidos.
  • Não será corrigido (Will Not Fix): O erro não será corrigido por decisão da direção (baixa prioridade, alto risco de correção, falta de recursos, etc.).
  • Mais informações necessárias (Need More Info): São necessárias informações adicionais para reproduzir ou entender o problema.
• Adiado (Deferred / Postponed): A correção do erro foi adiada para uma versão ou iteração posterior devido a prioridades mais altas ou falta de tempo/recursos.
• Fechado (Closed): Em caso de rejeição ou adiamento, o relatório de erro passa finalmente para o estado "Fechado", mas sem correção.

O destino final de um erro não corrigido depende do seu estado e da decisão tomada:

• Se rejeitado, o relatório de erro é simplesmente arquivado. Comentários justificativos podem ser adicionados.
• Se adiado, pode ser reaberto no futuro quando houver possibilidade de correção, ou fechado definitivamente se a decisão de não corrigir se tornar definitiva.

É importante que no sistema de gestão de erros exista um histórico claro de mudanças de estado e comentários que expliquem as razões de cada transição.