Pourquoi les systèmes de suivi des problèmes ont-ils généralement des statuts distincts "Ouvert" et "Réouvert"?
Les problèmes ouverts sont généralement la première occurrence de tout problème.
Les problèmes qui sont rouverts sont 1) réapparus et / ou 2) mal résolus. Il peut y avoir un certain nombre de raisons à cela - une clé peut souvent être liée à la description originale du problème à l'utilisateur final.
Je ne pense pas qu'un magasin sensé l'utiliserait comme une mesure pour juger le personnel technique [seul] mais il est utile comme mesure pour identifier l'efficacité des réponses, et peut également signifier des problèmes sous-jacents qui doivent être résolus.
Mon ancienne entreprise a utilisé ces statuts pour suivre le nombre de fois où votre problème est passé à "Réouvert" pour voir à quel point vous étiez "mauvais" d'un développeur. Ils pensaient qu'il existe une corrélation entre le nombre de fois qu'un élément de travail est "rouvert" et votre valeur en tant que programmeur.
Je n'y travaille plus.
La durée de vie d'un bug est souvent:
c'est à dire.
Quelqu'un trouve un bug et l'ouvre dans le tracker. Le développeur le corrige du mieux qu'il peut avec sa compréhension du problème. Le testeur refait des tests pour vérifier que le correctif a fonctionné et rouvre s'il peut vérifier qu'il n'a pas fonctionné. Si le correctif est vérifié, le bogue est fermé.
L'autre scénario est qu'un correctif ailleurs a provoqué une régression et que le bogue doit être corrigé. Ainsi, il est rouvert.
la source
Il peut également s'agir de rendre plus évident que le problème nécessite une attention plus étroite ou plus rapide, car il continue d'être un problème après que le problème aurait été résolu.
la source
Ouvert signifie qu'il s'agit d'un nouveau problème. La réouverture de la signifiance ti était un problème qui a été ouvert-> fermé, puis à nouveau ouvert.
Pourquoi a-t-il été rouvert? Peut-être que le développeur et le testeur pensaient que ce problème était résolu, mais il n'était pas vraiment résolu. Ou peut-être que le problème a été vraiment résolu, mais d'autres modifications de code ultérieures ont provoqué la réapparition du problème. Peu importe comment, mais un problème rouvert est un mauvais signe et il est donc classé différemment.
la source
La façon dont nous l'utilisons ici:
Nouvelle tâche: créée au début du projet pour montrer tout le travail à faire. Il est ouvert jusqu'à ce que quelqu'un le code, puis il est résolu. Il n'est rouvert que si quelque chose n'a pas été implémenté, ou si la fonctionnalité a changé et que le développeur doit revenir en arrière et passer beaucoup de temps à y travailler.
Bogue / Défaut: ouvert par quelqu'un dans le contrôle qualité ou un autre développeur vérifiant le produit global. Si un bogue vous est attribué, vous le corrigez puis le résolvez et il revient dans les tests. Si le contrôle qualité estime qu'il n'a pas été corrigé, il le rouvrira et y joindra toute autre information dont il dispose. Le cycle Resolved / Reopened peut aller jusqu'à ce que QA soit convaincu que le bogue a été corrigé, puis il ferme le ticket.
Donc, en gros, vous utilisez Reopen pour dire qu'un ticket a déjà été examiné et que quelqu'un a fait un travail sur ce qu'il pensait résolu, mais ce n'était pas le cas.
la source
Il s'agit essentiellement d'un type de cohérence: un bogue (ou un problème en général) est "ouvert" s'il a été créé à partir de zéro. Il est "rouvert" s'il a été créé après qu'un traitement précédent a été effectué.
Pour un développeur (ou toute personne traitant le problème), cela ne devrait faire aucune différence. Une émission a été levée et devrait maintenant être traitée.
Cependant, un statut distinct de «réouverture» peut toujours être utile pour un certain nombre de scénarios:
Tout d'abord, il peut être utilisé comme un moyen de suivre si votre processus d'assurance qualité fonctionne ou non. Si le contrôle qualité a tout fait correctement, un bogue ne devrait jamais se produire après avoir été corrigé. Donc, vous pourriez dire que le nombre de fois qu'un bogue a été mis dans l'état "rouvrir" est le nombre de fois que le contrôle qualité n'a pas tout à fait fait son travail correctement. Cela implique bien sûr qu'un bon processus d'AQ est établi et que les utilisateurs participent activement au processus et savent quand «ouvrir» et quand «rouvrir» un problème.
Une autre utilisation est que, lorsqu'un bogue se reproduit, vous n'avez pas besoin de soulever un autre problème, mais vous pouvez ajouter les informations à un problème déjà existant (et donc conserver des informations importantes comme l'historique des problèmes, les fichiers supplémentaires qui ont été téléchargés, les commentaires précédents et ainsi de suite) mais toujours indiquer "hé, cela s'est reproduit" .
la source
L'une des principales raisons du suivi de la "réouverture" est qu'il peut vous donner une indication des problèmes routés profonds, plutôt que de simples erreurs et une surveillance des détails. Si un module ou un élément de fonctionnalité particulier a de nombreux «réouvertures», cela indique une faiblesse qui doit être corrigée. Un grand nombre de points d'ouverture uniques à un travail précipité et / ou une pratique bâclée.
la source