Comment gérer les bugs que je pense avoir corrigés, mais je ne suis pas tout à fait sûr

13

Il existe certains types de bugs qui sont très difficiles à reproduire, se produisent très rarement et apparemment au hasard. Il peut arriver que je trouve une cause possible, la corrige, teste le programme et ne puisse pas reproduire le bogue. Cependant, comme il était impossible de reproduire le bug de manière fiable et que cela arrivait si rarement, comment puis-je l'indiquer dans un bugtracker? Quelle est la manière courante de procéder?

Si je définissais le statusfixe et le solutionfixe, cela signifierait quelque chose de complètement fixe, n'est-ce pas?

Est-il courant de régler le statussur fixe et le solutionsur l'ouvrir, pour indiquer aux testeurs que "c'est probablement fixe, mais qu'il faut plus d'attention pour s'en assurer"?

Edit: la plupart (sinon tous) des bugtrackers ont deux propriétés pour le statut d'un bug, peut-être que les noms ne sont pas les mêmes. Par statusje veux dire nouvelle, affecté, fixe, fermé, etc. , et par solutionje veux dire ouvert (nouveau), fixe, sans solution, non reproductible, dupliquer, pas un bug , etc.

testing issue-tracking vsz
la source
3
Ceci est quelque peu spécifique à votre traqueur de bogues. Quelles autres valeurs pouvez-vous attribuer au statut et à la solution ?
scarfridge
Dans certains trackers de bogues, il y a un statut résolu et un autre statut fermé. Seules les personnes chargées de l'assurance qualité sont autorisées à définir l'état sur fermé, mais les développeurs peuvent définir l'état sur résolu.
Brian

Réponses:

8

Est-ce une pratique courante de définir le statut à fixe et la solution à ouvrir, pour indiquer aux testeurs que "c'est probablement fixe, mais qu'il faut plus d'attention pour s'en assurer"?

Commun ou non, c'est la bonne chose à faire de toute façon, et vous avez expliqué pourquoi vous-même: peu importe comment, c'est une bonne approche pour

indiquer aux testeurs que "c'est probablement corrigé, mais qu'il faut plus d'attention pour s'assurer"

Remarque latérale, même si un tracker de bogue particulier n'a pas de champ comme celui que vous décrivez solution, le développeur peut au moins ajouter un commentaire de forme libre expliquant ci-dessus.

... et si le traqueur de bogues ne permet pas d'ajouter des commentaires au problème, il doit être remplacé par un autre. La possibilité d'ajouter des clarifications sous forme libre est une caractéristique extrêmement importante car les problèmes varient trop pour tenir dans une forme prédéfinie.

moucheron
la source
6

L'équipe de test décidera si le problème a été résolu et s'il peut être résolu. S'il y a d'autres régressions, effets secondaires du correctif ou si le correctif lui-même n'est pas efficace dans un autre scénario, le problème sera rouvert. Mais si vous avez fait suffisamment de tests pour les développeurs, mieux vaut le marquer comme corrigé.

éminence
la source
+1 - C'est la réponse la plus simple. Si vous avez fait de votre mieux et que la suite de tests des équipes de test est suffisamment puissante, que pouvez-vous faire de plus?
ozz
3

Il existe des types de bogues très difficiles à reproduire, qui se produisent très rarement et apparemment de manière aléatoire. Il peut arriver que je trouve une cause possible, la corrige, teste le programme et ne puisse pas reproduire le bogue.

En fait, s'il n'y a pas de scénario de test reproductible, je n'essaierais même pas de corriger un tel bug au préalable. Si vous souhaitez que le testeur y prête plus d'attention, donnez-lui la possibilité de créer un scénario reproductible.

Par exemple, disons que vous modifiez le programme et qu'un testeur investit 1 heure pour essayer de reproduire le bogue, et que le bogue n'apparaît pas - était-ce une heure suffisante? Ou est-ce que tester davantage est une perte de temps car le bug a déjà été corrigé?

D'un autre côté, lorsque vous ne changez pas le programme et que le bogue n'apparaît pas en 1 heure, le testeur devrait probablement consacrer une autre heure à essayer différentes choses. Et lorsque le testeur investit un jour et ne peut plus reproduire le bogue - cela vaut-il vraiment la peine d'essayer de le corriger alors?

Cela dit, vous pouvez penser à la façon dont vous modélisez ce processus dans votre système de suivi des bogues: ne pas essayer de le corriger et le remettre aux testeurs peut être un statut de bogue comme "ouvert". Si les testeurs ne peuvent pas le reproduire, il est évidemment "non reproductible". Espérons que cela ne se produise pas, ils trouvent un scénario reproductible, vous pouvez trouver la cause première de votre bogue, le corriger et définir le statut sur "corrigé". Essayez d'éviter d'entrer dans quelque chose comme "je ne sais pas si c'est réparé".

Doc Brown
la source
4
Pour certains types de bogues, un scénario de test reproductible n'existe tout simplement pas. Par exemple, un bug lié au timing peut se produire 1 fois sur un million en moyenne - mais il est impossible de prédire s'il sera sur la 3e ou la 532454e manche. Néanmoins, ces bogues sont des bogues et doivent être corrigés.
Joonas Pulakka
3
@Joonas Pulakka: Je suis d'accord. Et ces bogues peuvent dépendre de circonstances externes. En cas d'incorporation, elles peuvent dépendre de surtensions provoquées par quelque chose hors de votre contrôle. Ne pas essayer de le réparer n'est pas toujours la meilleure solution, surtout si je trouve une odeur de code que je soupçonne que cela peut être une cause de ce bogue. Dans ce cas, pourquoi ne devrais-je pas le réparer?
vsz
2
@JoonasPulakka: d'après mon expérience des scénarios reproductibles, dans la plupart des cas où les gens disent "ce n'est pas possible", ils manquent juste la bonne idée pour rendre les choses possibles. Dans votre exemple, on pourrait mettre en place un scénario avec une boucle "10 millions d'exécutions", ce qui rendrait au moins très probable l'apparition du bogue dans un délai raisonnable.
Doc Brown
2
@vsz: vous devez le corriger, bien sûr, mais ce que je suggère, c'est que l'on doit d' abord créer un test (ou donner aux testeurs un indice sur ce qu'il faut tester), puis le corriger, et non l'inverse.
Doc Brown
2
@DocBrown a raison, une autre façon de penser est que parfois les bugs nécessitent une approche statistique pour les "reproduire". Il se pourrait très bien qu'il existe un ensemble très spécifique d'entrées / circonstances qui reproduit le bogue, mais vous pourriez ne PAS avoir une idée de ce que sont ces entrées et l'ensemble des entrées possibles peut être trop énorme pour être itéré. Dans ces cas, une approche consiste à collecter des statistiques sur la survenue d'un bug à chaque fois que vous essayez de le résoudre. Cela peut prendre beaucoup de temps et les résultats peuvent ne pas vous donner 100% de «confiance» au sens statistique, mais parfois tout ce que vous avez.
Angelo
0

Parfois, la seule preuve dont vous disposez est purement statistique, par exemple, elle se produit une ou deux fois par mois, mais autrement sans rapport avec quoi que ce soit. Il s'agit dans l'ensemble du pire type de bogue à diagnostiquer et à résoudre que j'aie jamais rencontré, car vous ne pouvez pas savoir avec certitude si vos correctifs ont un effet. Le dernier de ceux que j'ai dû résoudre s'est terminé par une correction statistique: la fréquence du symptôme est descendue à 10% avec laquelle nous avons commencé. La dernière pièce n'a jamais été trouvée, ou peut-être qu'elle l'était, mais personne n'avait aucun moyen de le savoir.

Deux conseils que j'ai: (1) supposent que plusieurs causes pourraient être en vigueur jusqu'à ce que vous sachiez le contraire, et (2) émettez l'hypothèse que les symptômes pourraient éventuellement exister, puis déchirez chaque ligne de logique qui est même impliquée à distance. Les procédures pas à pas profondes sont parfois le seul moyen de parvenir à une fin satisfaisante.

Chris Cochran
la source