Avez-vous de bonnes stratégies pour faire face aux bogues "non reproductibles" ?

Question

Très souvent, vous recevrez ou soumettrez des rapports de bogue pour des défauts qui ne sont pas reproductibles. Ils peuvent être reproductibles sur votre ordinateur ou votre projet logiciel, mais pas sur le système d'un fournisseur. Ou bien l'utilisateur fournit les étapes de la reproduction, mais vous ne pouvez pas voir le défaut localement. Il existe bien sûr de nombreuses variantes de ce scénario. Pour simplifier, je suppose que ce que j'essaie d'apprendre est le suivant :

Quelle est la politique de votre entreprise à l'égard des bogues "non reproductibles" ? Les mettre à l'abri, les fermer, les ignorer ? Je vois occasionnellement des bugs intermittents et non reproductibles dans des frameworks tiers, et ils sont presque toujours fermés instantanément par le fournisseur... mais ce sont de vrais bugs.

Avez-vous trouvé des techniques qui aident à corriger ces types de bogues ? En général, je demande à l'utilisateur de me fournir un rapport d'informations sur le système et de m'indiquer les étapes à suivre pour reproduire le problème, puis j'effectue une recherche par mots-clés et j'essaie de trouver un modèle quelconque.

Answer 1

• Vérifier les étapes utilisées pour produire l'erreur

Souvent, les personnes qui signalent l'erreur ou celles qui la reproduisent font une erreur et ne se retrouvent pas dans le même état, même si elles le pensent. Essayez d'en discuter avec la personne qui a signalé l'erreur. J'ai eu un utilisateur qui insistait sur le fait que les privilèges d'administrateur n'apparaissaient pas correctement. J'ai essayé de reproduire l'erreur, mais je n'y suis pas parvenu. Lorsque nous avons examiné le problème ensemble, il s'est avéré qu'il se connectait en tant qu'utilisateur normal dans ce cas.

• Vérifiez le système/environnement utilisé pour produire l'erreur.

J'ai trouvé de nombreux bogues "irreproductibles" et je n'ai découvert que plus tard qu'ils étaient reproductibles sur Mac OS (10.4), avec la version X de Safari. Et cela ne s'applique pas seulement aux navigateurs et au rendu, cela peut s'appliquer à n'importe quoi ; les autres applications en cours d'exécution, que l'utilisateur soit ou non RDP ou local, administrateur ou utilisateur, etc... Assurez-vous que votre environnement soit aussi proche que possible du leur avant de le qualifier d'irreproductible.

• Recueillir des captures d'écran et des journaux

Une fois que vous avez vérifié que l'utilisateur fait tout correctement et qu'il obtient quand même un bug, et que vous faites exactement ce qu'il fait et que vous n'obtenez PAS le bug, il est temps de voir ce que vous pouvez faire. Les captures d'écran et les journaux sont essentiels. Vous voulez savoir exactement à quoi cela ressemble, et ce qui se passait exactement à ce moment-là.

Il est possible que les journaux contiennent des informations que vous pouvez reproduire sur votre système, et une fois que vous pouvez reproduire le scénario exact, vous pourriez être en mesure de faire sortir l'erreur de sa cachette.

Les captures d'écran sont également utiles à cet égard, car vous pouvez découvrir que "la pièce X s'est chargée correctement, mais elle n'aurait pas dû car elle dépend de Y" et cela peut vous donner un indice. Même si l'utilisateur peut décrire ce qu'il fait, une capture d'écran peut s'avérer encore plus utile.

• Recueillir la description étape par étape de l'utilisateur

Il est très courant de blâmer les utilisateurs et de ne pas faire confiance à ce qu'ils disent (parce qu'ils appellent un 'usercontrol' un 'thingy'), mais même s'ils ne connaissent pas les noms de ce qu'ils voient, ils seront toujours capables de décrire certains comportements qu'ils observent. Cela inclut des erreurs mineures qui peuvent s'être produites quelques minutes AVANT que la véritable erreur ne se produise, ou encore la lenteur de certaines choses qui sont habituellement rapides. Tous ces éléments peuvent être des indices pour vous aider à déterminer quel aspect provoque l'erreur sur leur machine et non sur la vôtre.

• Essayez d'autres approches pour produire l'erreur

Si tout le reste échoue, essayez d'examiner la section du code qui pose problème, et éventuellement de la remanier ou d'utiliser une solution de contournement. S'il vous est possible de créer un scénario dans lequel vous commencez avec la moitié des informations déjà présentes (si possible en UAT), demandez à l'utilisateur d'essayer cette approche et voyez si l'erreur se produit toujours. Faites de votre mieux pour créer des approches alternatives mais similaires qui présentent l'erreur sous un jour différent afin que vous puissiez mieux l'examiner.

Answer 2

Réponse courte : Réaliser une revue de code détaillée sur le code suspecté d'être défectueux, dans le but de corriger tous les bogues théoriques, et d'ajouter du code pour surveiller et enregistrer toute défaillance future.

Longue réponse : Pour donner un exemple concret tiré du monde des systèmes embarqués : nous fabriquons des équipements industriels, contenant de l'électronique personnalisée, et des logiciels embarqués fonctionnant dessus.

Un client a signalé qu'un certain nombre d'appareils sur un même site présentaient la même défaillance à des intervalles aléatoires. Les symptômes étaient les mêmes dans chaque cas, mais il ne pouvait pas identifier une cause évidente.

Évidemment, notre première étape a été d'essayer de reproduire la panne sur le même appareil dans notre laboratoire, mais nous n'y sommes pas parvenus.

Au lieu de cela, nous avons fait circuler le code suspecté d'être défectueux au sein du département, pour essayer d'obtenir autant d'idées et de suggestions que possible. Nous avons ensuite tenu un certain nombre de réunions de révision du code pour discuter de ces idées et déterminer une théorie qui : (a) expliquait la cause la plus probable des défauts observés sur le terrain ; (b) expliquait pourquoi nous n'étions pas en mesure de les reproduire ; et (c) conduisait à des améliorations que nous pouvions apporter au code pour éviter que le défaut ne se reproduise à l'avenir.

Outre les corrections de bogues (théoriques), nous avons également ajouté un code de surveillance et d'enregistrement, de sorte que si le défaut devait se reproduire, nous pourrions extraire des données utiles du dispositif en question.

À ma connaissance, ce logiciel amélioré a ensuite été déployé sur le site, et semble avoir été un succès.

Answer 3

Signalement des erreurs, fichiers journaux, et demandes sévères de "contactez-moi immédiatement si cela se reproduit".

Answer 4

Si cela se produit dans un contexte, et pas dans un autre, nous essayons d'énumérer la différence entre les deux, et de les éliminer.

Parfois, cela fonctionne (par exemple, autre matériel, double cœur ou hyperthreading, disque d'ordinateur portable ou disque de station de travail, ...).

Parfois, ce n'est pas le cas. Si c'est possible, nous pouvons commencer à déboguer à distance. Si cela n'aide pas, nous pouvons essayer de mettre la main sur le système du client.

Mais bien sûr, nous n'écrivons pas trop de bogues en premier lieu :)

Answer 5

Vous faites de votre mieux pour le reproduire et, si vous n'y parvenez pas, vous réfléchissez longuement à la manière dont un tel problème pourrait survenir. Si vous n'en avez toujours aucune idée, il n'y a pas grand-chose que vous puissiez faire.