Comment faire face à un bug qui semble s'être corrigé? [fermé]

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement de réponses.

Vous souhaitez améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 4 ans .

Je suis développeur d'applications Web pour un système interne. Un utilisateur signale un bogue.

Le bug était que certains mots ne pouvaient pas être affichés. Le rapport contient une capture d'écran qui montre clairement le bug. Mais le rapport a presque un mois et le bug ne peut plus être reproduit dans notre environnement de production.

Comment dois-je répondre au client et à l'utilisateur?

issue-tracking defect

— Ben Cheng
source

Nous avons plusieurs questions connexes ici sur les programmeurs: Éliminer un bogue si aucun cas de test reproductible n'existe? Comment isoler les bogues difficiles à reproduire? Comment déboguer le code le plus efficacement possible? Bugs non explicables? Que faire des bugs qui ne font pas de reproches?

— Thomas Owens

Découvrez comment le rendre reproductible.

— Wyatt Barnett

Combien de temps pouvez-vous consacrer à cette enquête? À quel point le bogue était-il critique et ses effets négatifs? Si les réponses sont très petites et négligeables, je dirais que le marquer comme corrigé avec une note des circonstances dans lesquelles il n'est pas vraiment fixe et attendre qu'il revienne est une utilisation parfaitement acceptable des ressources de votre entreprise.

— Newtopian

Cela demande simplement une réponse standard standard: " Cher [utilisateur], Le problème avec X que vous avez signalé le Yth semble avoir été résolu avec la dernière version de Z. Veuillez marquer le problème comme résolu si c'est effectivement le cas Si ce n'est pas le cas, veuillez me le renvoyer avec des détails sur la façon dont vous l'avez rencontré. "

— Lilienthal

@Lilienthal Ce n'est pas parce qu'un bogue ne peut pas être reproduit qu'il a été résolu. Vous ne savez même pas qu'il y a même eu une nouvelle version au cours du dernier mois.

— paparazzo

Réponses:

Rétablissez votre environnement de développement à la version dans laquelle le bogue a été remarqué et vérifiez que le bogue existe.

S'il est là, vous pouvez enquêter sur le bogue et vous assurer que la version actuelle ne l'a pas. Ensuite, fermez le rapport de bogue avec le commentaire qu'une modification sans rapport l'a corrigé. Ajoutez un test de régression si nécessaire.

Si vous ne pouvez pas reproduire le bogue dans cette version, les stratégies énoncées dans de nombreuses autres questions ici seront utiles (merci Thomas pour la liste initiale):

— monstre à cliquet
source

D'après mon expérience, la plupart des équipes vérifient simplement l'option "ne peut pas reproduire" dans le système de billetterie et la ferme. Tester le code «alors» et «maintenant» pour vous assurer que le problème existe et ne l'est plus semble être une meilleure solution. Mais cela prend aussi plus de temps que de dire "ne peut pas se reproduire" et de le fermer, donc ce n'est peut-être pas une option pour chaque bogue.

— Paul J Abernathy du

Cela dépend de la gravité du bug. S'il ne s'agit que d'une mise en page, alors un tampon de repro ne pourrait pas être fait, mais si cela pouvait être plus sinistre, quelques heures pour se retrouver avec un test de régression peuvent valoir la peine.

— ratchet freak

@ratchetfreak Alternativement, cela dépend de la gravité de ce client particulier. S'ils financent à eux seuls vos chèques de paie, cela vaut peut-être la peine de les humilier ;-)

— Cort Ammon - Rétablir Monica

Les problèmes qui disparaissent d'eux-mêmes reviennent d'eux-mêmes.

— Pete Becker,

Tout est une question de charge de travail. Si vous avez un bogue qui était reproductible il y a un mois et qui ne l'est plus, et un autre bogue qui est reproductible maintenant , vous corrigez d'abord celui qui est reproductible. Si jamais vous arrivez dans un état où vous vous ennuyez totalement, vous pouvez alors enquêter. Et quand le problème revient de lui-même, alors bien sûr, c'est un bug reproductible et vous commencez à le corriger :-)

— gnasher729

Je vais supposer que vous avez vraiment fait tout ce que vous pouviez pour reproduire le bogue, mais que vous ne pouvez pas.

Dans un cas comme celui-ci, il est souvent préférable d'ajouter du code autour de la zone de l'application qui n'a pas réussi à enregistrer le travail en cours, afin que vous ayez, espérons-le, plus de données à travailler si cela se reproduit. Réfléchissez aux informations dont vous avez besoin et que vous ne disposez pas actuellement. Par exemple, il se produit peut-être uniquement lorsqu'un ensemble particulier de paramètres d'entrée est envoyé et que vous les enregistrez donc à chaque exécution du processus. Vérifiez auprès de votre patron avant de le faire, en fonction de l'importance du bug et de la fréquence à laquelle il s'est produit, il peut ne pas vouloir passer du temps à le faire.

Ensuite, vous allez à la personne qui a signalé le bogue (vous pouvez le faire dans l'application de suivi des bogues si vous en avez un, vous n'avez pas à y aller en personne) et dites que vous n'avez pas pu reproduire le bogue mais avez ajouté quelques la journalisation pour obtenir plus de détails sur ce que fait le processus au cas où le bogue se reproduirait. Fermez ensuite le bug.

Si vous ne pouvez pas effectuer de journalisation supplémentaire. signalez simplement que le bogue n'était pas reproductible et que s'ils le rencontrent à nouveau, ce sont les informations dont vous aurez besoin pour le reproduire et dites-leur ce dont vous avez besoin. Nous leur demandons souvent de nous dire exactement quels paramètres d'entrée ils introduisaient lorsqu'ils ont eu l'erreur. Le simple fait d'avoir une capture d'écran de l'erreur aide, mais il est plus utile de savoir exactement quelles mesures ils prenaient et quelles informations ils ont essayé d'utiliser au moment où l'erreur s'est produite. Donc, fondamentalement, vous leur imposez le fardeau de vous donner plus d'informations lorsqu'ils signalent l'erreur si elle se reproduit.

Dans votre outil de suivi des bogues, assurez-vous d'expliquer les étapes que vous avez essayées, afin que si le bogue se reproduise, la personne qui le gère ait des informations sur ce qui a été fait auparavant.

— HLGEM
source

Les sacs non reproductibles sont les pires! Il peut avoir été corrigé entre-temps, ou il peut toujours être là, mais il est sporadique ou les étapes de reproduction ne sont pas suffisamment spécifiées. Vous devez vous prononcer sur le niveau de risque élevé du bogue et sur l'ampleur de vos recherches. Êtes-vous en train de créer un gestionnaire de recettes en ligne ou un logiciel de contrôle de direction pour les missiles nucléaires?

S'il s'agit d'un bogue à faible impact et que vous savez que des modifications ont été apportées qui auraient pu entraîner la correction involontaire du bogue, il peut être acceptable de fermer le bogue avec la note qu'il n'est pas reproductible et vous supposez qu'il a été corrigé .

Si vous êtes plus concerné, vous pouvez faire quelques théories sur ce qui a causé le bogue en premier lieu, et parcourir le journal des modifications et l'historique des sources pour voir si vous pouvez repérer où il a été corrigé.

Pour un bogue plus grave, vous devrez restaurer la source jusqu'au point de la dernière version, puis essayer de reproduire. Si vous reproduisez avec succès, vous pouvez écrire des tests pour vous assurer qu'il est corrigé dans les validations ultérieures.

— JacquesB
source