Bug rouvert contre nouveau

55

Un bug a été ouvert, corrigé, vérifié et fermé. Un mois plus tard, il réapparut dans une version ultérieure après plusieurs itérations sans aucune régression.

A condition que les caractéristiques de bugs sont les mêmes, ce que vous rouvrez l'ID de bogue ou d' ouvrir un nouveau un avec un lien vers le bogue fermé?

project-management agile issue-tracking

— KMoraz
source

86

Les caractéristiques ne sont pas égales aux causes. Le nouveau bogue pourrait avoir une raison sous-jacente différente, même s'il semble être le même. Donc, ouvrez un nouveau bogue et dirigez-le vers l'ancien pour aider le développeur.

— Dibbeke
source

23

+1 il y a beaucoup de differnt maladies avec des traitements différents qui partagent communs symptômes.

— FrustratedWithFormsDesigner

Serait-il juste de déduire que si le bogue s’avérait avoir la même cause, vous le rouvriez?

— KMoraz

@KMoraz: Je pense que oui, mais ce n'est que quelque chose à considérer après que l'enquête prouve que c'est exactement la même cause. Étant donné que les symptômes ont disparu pendant un certain temps, il est peu probable qu'il s'agisse du même bogue, bien qu'il s'agisse d'un bogue introduit dans une autre partie du système, mais codé de la même manière que le bogue d'origine, causant ainsi des symptômes similaires.

— FrustratedWithFormsDesigner

1

@KMoraz je dirais non. Supposons qu'il soit corrigé dans la version 1.0, la version 1.1 ne l’avait pas, mais elle est réapparue sur la version 1.2. À moins que votre outil de suivi des problèmes ne vous permette de l'associer à plusieurs versions à la fois, vous perdrez l'historique qui a été trouvé et corrigé dans la version 1.0. Ouvrez juste un nouveau bogue.

— Andy

1

@Andy Ne pensez pas que cela change quoi que ce soit, mais peut-être que 1.1 l'avait et que personne ne l'avait remarqué ...

— joshuahedlund Le

35

Si cela a été vérifié et fermé, et a fonctionné pendant un certain temps, puis est réapparu après que quelque chose ait changé, alors ce n'est pas le même bogue. Il peut se manifester de la même manière que l'ancien bug, mais sa cause peut être différente. Ce n'est donc pas le même bug. J'en ouvrirais donc un nouveau, avec un lien vers le bogue fermé.

— Joonas Pulakka
source

16

Ouvrez un nouveau bogue, toujours. Pourquoi? Supposons qu'il soit identique au bogue précédent et que vous ayez publié le correctif pour le bogue précédent. Vos notes de publication indiqueront que "Corriger le bogue XXX". Du point de vue du suivi des problèmes et de la clarification des notes de publication, il est préférable de faire référence au nouveau bogue "Fix Bug XXX + 1 (dont la cause et l’effet était similaire à celui de Bug XXX)" plutôt que de dire "Corriger les bogues." XXX (encore) "ou quelque chose de similaire.

— James McLeod
source

2

Citer les identifiants de bogues dans les notes de correctif est très ... très désagréable.

— Thomas Bonini

3

@krelp Lorsque vous travaillez avec un fournisseur, il est utile de résoudre un problème. Vous pouvez également suivre l'ID de bogue que vous avez reçu avec un ID de bogue dans les notes de publication.

— Darryl Braaten

1

@Krelp Je me suis demandé pourquoi cette idée était mauvaise, alors j'ai posé la question suivante: programmers.stackexchange.com/questions/142258/… Peut-être avez-vous des commentaires à ce sujet? :)

— Travis Northcutt

C'est un bon point

— KMoraz

4

De manière générale, ouvrez un nouveau bogue.

Cependant, si vous êtes autorisé à faire une enquête au préalable, je vérifierai votre historique dans le code source .

Si vous travaillez dans un environnement d'équipe, il est possible que quelqu'un ait l'ancien code sur son système (c'est-à-dire qu'il n'a pas effectué de lecture de la dernière après l'enregistrement du correctif d'origine), a apporté des modifications, puis a procédé à l'enregistrement sans diff. Mauvaise pratique, bien sûr, mais cela arrive "tout le temps".

Regarder l'historique du ou des fichiers où le bogue a été corrigé confirmera ou éliminera rapidement cette possibilité.

— Wonko le sain d'esprit
source

1

"(c’est-à-dire qu’ils n’ont pas procédé à une dernière mise à jour après l’enregistrement du correctif initial), qu’ils ont apporté des modifications, puis qu’ils ont été

— archivés

@ JoelFan - pas nécessairement. Parfois, la fusion automatique ne fonctionne pas correctement, et parfois, la fusion manuelle ne fonctionne pas correctement non plus. Ou bien, il se peut qu’ils aient simplement manqué le changement lorsqu’ils ont procédé au diff, etc. Tout ce que je dis, c’est que ça sent les erreurs humaines et qu’une vérification de 2 minutes de l’historique de contrôle de la source peut économiser beaucoup de choses. tracas.

— Wonko the Sane

1

De toute façon, vérifier l’historique en vaut la peine… parce que si votre système de contrôle de source est en panne, vous voulez le savoir.

— Mjfgates

2

Si cela se produit all the time, ce n'est pas le SCM qui est en panne, c'est votre équipe de développement ...

— Daenyth

1

Je suis d'accord avec la suggestion des précédentes affiches d'ouvrir un nouveau bogue car il pourrait ne pas être la même cause.

Ma recommandation supplémentaire est de vous assurer que vous ajoutez toujours des tests unitaires et d’intégration couvrant le bogue afin que, dans les versions futures, vous détectiez immédiatement le problème avant qu’il ne soit envoyé à vos clients. Rien ne semble pire pour un client qui voit le même bogue revenir.

— Mike Parkhill
source

1

Ce n'est pas la meilleure analogie - Ce n'est pas parce que les symptômes de deux personnes sont identiques que la maladie ou la cause de la maladie est la même.

De wikipedia:

Un bogue logiciel est une erreur, une faille, une défaillance ou une défaillance dans un programme informatique ou un système qui en résulte en un résultat incorrect ou inattendu, ou en un comportement imprévu. La plupart des insectes proviennent de .....

Un bug est une faille dans le code et entraîne des symptômes / effets. Un bug n'est pas le symptôme. Un bug est l'erreur dans le code. Le fait que les symptômes soient les mêmes ne signifie pas nécessairement que le même défaut est à l'origine des symptômes.

Si j'ai bien compris, vous devriez rouvrir un bogue si vous êtes certain qu'un bogue est dû au même morceau de code. Cela peut se produire lorsque le code se comporte correctement dans tous les scénarios de test / cas de test, mais pas dans un nouveau cas de test ou un cas de test auquel vous n'aviez pas pensé plus tôt. Ce genre de scénario peut ne pas être commun.

L'autre scénario est que les mêmes symptômes sont causés par de nouvelles failles, par exemple de nouveaux bogues dans d'autres parties du même code ou même dans d'autres systèmes affectant ce code.

Donc, le pari le plus sûr est d'ouvrir un nouveau bogue lorsque les mêmes symptômes se manifestent. Si vous voyez que le même ancien code est responsable du bogue, fermez le nouveau bogue et rouvrez-le. Sinon, laissez le nouveau bogue rester et liez-le à l'ancien.

— BugBot
source