Que se passe-t-il avec un rapport de bug s'il n'a pas été corrigé?

Si un rapport de bug n’a pas été corrigé, il passe par les étapes suivantes dans son cycle de vie:

• Ouvert (Open): Le rapport de bug est créé et transmis à l’équipe de développement.
• Assigné (Assigned): La tâche de correction du bug est assignée à un développeur ou une équipe spécifique.
• Rejeté (Rejected / Declined): Le bug peut être rejeté pour diverses raisons:
  • Ce n’est pas un bug (Not a Bug): Le comportement décrit est conforme aux attentes.
  • Duplication (Duplicate): Le bug a déjà été enregistré précédemment.
  • Impossible à reproduire (Cannot Reproduce): Il est impossible de reproduire le bug avec les étapes fournies.
  • Ne sera pas corrigé (Will Not Fix): Le bug ne sera pas corrigé selon la décision de la direction (faible priorité, risque élevé de correction, manque de ressources, etc.).
  • Plus d’informations nécessaires (Need More Info): Des informations supplémentaires sont requises pour reproduire ou comprendre le problème.
• Différé (Deferred / Postponed): La correction du bug a été reportée à une version ou une itération ultérieure en raison de priorités plus élevées ou d’un manque de temps/ressources.
• Fermé (Closed): En cas de rejet ou de report, le rapport de bug passe finalement à l’état "Fermé", mais sans correction.

Le destin final d’un bug non corrigé dépend de son statut et de la décision prise:

• Si rejeté, le rapport de bug est simplement archivé. Des commentaires justificatifs peuvent être ajoutés.
• Si différé, il peut être rouvert à l’avenir lorsque la correction sera possible, ou définitivement fermé si la décision de ne pas le corriger devient définitive.

Il est important que le système de gestion des bugs ait un historique clair des changements de statut et des commentaires expliquant les raisons de chaque transition.