Toutes les bonnes stratégies pour traiter les bugs «non reproductibles»?

Question

Très souvent, vous obtiendrez ou soumettez des rapports de bogues pour des défauts qui ne sont pas reproductibles. Ils peuvent être reproductibles sur votre ordinateur ou votre projet de logiciel, mais pas sur le système d'un fournisseur. Ou l'utilisateur fournit des étapes pour reproduire, mais vous ne pouvez pas voir le défaut localement. Bien entendu, il existe de nombreuses variantes de ce scénario. Pour simplifier, j'essaie donc d'apprendre:

Quelle est la politique de votre entreprise à l’égard des bogues «non reproductibles»? Les étendre, les fermer, ignorer? Je vois parfois des bugs intermittents et non reproductibles dans les frameworks tiers, et ceux-ci sont pratiquement toujours fermés instantanément par le vendeur ... mais ce sont de vrais bugs.

Avez-vous trouvé des techniques permettant de résoudre ces types de bugs? Ce que je fais généralement, c’est d’obtenir un rapport d’informations système de la part de l’utilisateur, des étapes à suivre pour reproduire, puis une recherche sur les mots-clés et essayer de voir toute sorte de modèle.

Answer 1

• Vérifiez les étapes à suivre pour générer l'erreur

Souvent, les personnes signalant l'erreur, ou les personnes reproduisant l'erreur, feront quelque chose de mal et ne se retrouveront pas dans le même état, même si elles le pensent bien. Essayez de passer au travers avec la partie rapportante. J'ai eu un utilisateur INSIST que les privilèges d'administrateur n'apparaissaient pas correctement. J'ai essayé de reproduire l'erreur et je n'ai pas pu. Lorsque nous l'avons parcouru ensemble, il s'est avéré qu'il se connectait en tant qu'utilisateur régulier dans ce cas.

• Vérifier le système / l'environnement utilisé pour générer l'erreur

J'ai trouvé de nombreux bogues "imprescriptibles" et ce n'est que plus tard que j'ai découvert qu'ils étaient reproductibles sous Mac OS (10.4). Exécution de 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 RDP ou local, administrateur ou utilisateur, etc ... Assurez-vous que votre environnement est aussi proche que possible du leur avant de l'appeler irréproductible.

• Récupérer des captures d'écran et des journaux

Une fois que vous avez vérifié que l'utilisateur fait tout correctement, qu'il a toujours un bogue et que vous faites exactement ce qu'il fait, et que vous n'obtenez pas le bogue, il est temps de voir ce que vous pouvez réellement faire. il. Les captures d'écran et les journaux sont critiques. Vous voulez savoir exactement à quoi cela ressemble et ce qui se passait à ce moment-là.

Il est possible que les journaux contiennent des informations que vous pouvez reproduire sur votre système. Une fois que vous pourrez reproduire le scénario exact, vous pourrez peut-être extraire l'erreur de sa dissimulation.

Les

captures d’écran vous aident également dans cette tâche, car vous pourriez découvrir que & "X morceau a été chargé correctement, mais ne le devrait pas car il dépend de Y &"; et cela pourrait vous donner un indice. Même si l’utilisateur peut décrire ce qu’il fait, une capture d’écran pourrait aider encore plus.

• Recueillir une description détaillée de l'utilisateur

Il est très courant de blâmer les utilisateurs et de ne faire confiance à rien de ce qu'ils disent (parce qu'ils appellent un "contrôle utilisateur" un "objet") mais même s'ils ne savent peut-être pas le nom de ce qu'ils voient, ils continueront être en mesure de décrire certains des comportements observés. Cela inclut quelques erreurs mineures qui peuvent s’être produites quelques minutes AVANT que l’erreur réelle s’est produite, voire une lenteur dans certaines choses qui sont généralement rapides. Toutes ces choses peuvent être des indices pour vous aider à déterminer l’aspect à l’origine de l’erreur sur leur ordinateur et non le vôtre.

• Essayez d’autres méthodes pour générer l’erreur

Si tout échoue, essayez de regarder la section de code qui cause des problèmes et éventuellement refactoriser ou utiliser une solution de contournement. S'il est possible pour vous de créer un scénario dans lequel vous commencez avec la moitié des informations déjà présentes (espérons-le dans UAT), demandez à l'utilisateur d'essayer cette approche et de voir si l'erreur persiste. Préférez-vous créer des approches alternatives, mais similaires, qui donnent à l’erreur l’erreur sous un jour différent, afin de mieux l’examiner?

Answer 2

Réponse courte: effectuez une révision détaillée du code concernant le code présumé défectueux, dans le but de corriger les bugs théoriques et d'ajouter du code permettant de surveiller et de consigner toutes les pannes futures.

Réponse longue: Pour donner un exemple concret du monde des systèmes embarqués: nous fabriquons des équipements industriels, contenant des composants électroniques personnalisés et des logiciels embarqués s’exécutant dessus.

Un client a signalé qu'un certain nombre de périphériques d'un même site rencontraient le même défaut à des intervalles aléatoires. Leurs symptômes étaient les mêmes dans chaque cas, mais ils ne pouvaient pas identifier une cause évidente.

Évidemment, notre première étape a été d’essayer de reproduire la défaillance dans le même appareil de notre laboratoire, mais nous n’avons pas pu le faire.

Nous avons donc distribué le code présumé défectueux au sein du ministère pour essayer de recueillir le plus d'idées et de suggestions possibles. Nous avons ensuite organisé 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) a expliqué pourquoi nous n’avons pas été en mesure de le reproduire; et (c) conduit à des améliorations que nous pourrions apporter au code pour éviter que la faute ne se reproduise à l'avenir.

En plus des corrections de bugs (théoriques), nous avons également ajouté du code de surveillance et de journalisation. Ainsi, si le problème se reproduisait, nous pourrions extraire des données utiles de l'appareil en question.

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

Answer 3

Signaler les erreurs, les fichiers journaux et les demandes strictes à & "Contactez-moi immédiatement si cela se produit à nouveau. &";

Answer 4

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

Parfois, cela fonctionne (par exemple, un autre matériel, dual core vs hyperthreading, disque portable vs disque de station de travail, ...).

Parfois, ce n'est pas le cas. Si cela est possible, nous pouvons commencer le débogage à distance. Si cela ne vous 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 bugs en premier lieu:)

Answer 5

résolu " stérile " et & "Spooky &";

Nous avons deux catégories de bogues fermés pour cette situation.

stérile : impossible de se reproduire.

Spooky - il est reconnu qu'il existe un problème, mais il apparaît simplement par intermittence, n'est pas tout à fait compréhensible et donne à tout le monde un léger aperçu de la chair de poule.

Answer 6

Eh bien, vous faites de votre mieux pour le reproduire, et si vous ne le pouvez pas, réfléchissez longuement et réfléchissez à la manière dont un tel problème pourrait survenir. Si vous n'avez toujours aucune idée, vous ne pouvez rien y faire.

Answer 7

Certaines des nouvelles fonctionnalités de Visual Studio 2010 seront utiles. Voir:

• Débogueur historique et analyse d'impact de test dans Visual Studio Team System 2010
• Meilleur logiciel Qualité avec Visual Studio Team System 2010
• Test manuel avec Visual Studio Team System 2010

Answer 8

J'ajoute la journalisation au code de traitement des exceptions dans tout le programme. Vous avez besoin d’une méthode pour collecter les journaux (les utilisateurs peuvent l’envoyer par courrier électronique, etc.)

Les vérifications préemptives des versions de code et des environnements sains sont également une bonne chose. Avec la facilité des mises à jour logicielles, le code et l'environnement en cours d'exécution par l'utilisateur n'ont presque certainement pas été testés. Cela n'existait pas lorsque vous avez publié votre code.

Answer 9

Avec un projet Web que je développe actuellement, je fais quelque chose de très similaire à votre technique. Je construis une page vers laquelle je peux diriger les utilisateurs afin de collecter des informations telles que la version de leur navigateur et leur système d'exploitation. Je vais également collecter les informations du registre des applications afin de pouvoir jeter un coup d'œil à ce qu'elles ont fait.

Ceci est un problème très réel. Je ne peux parler que du développement Web, mais j'estime que les utilisateurs sont rarement en mesure de me fournir les informations de base dont j'ai besoin pour examiner la question. Je soupçonne qu'il est tout à fait possible de faire quelque chose de similaire avec d'autres types de développement. Mon plan est de continuer à travailler sur ce système pour le rendre de plus en plus utile.

Mais ma politique est de ne jamais fermer un bogue simplement parce que je ne peux pas le reproduire, peu importe à quel point il peut être agaçant. Et puis il y a les cas où ce n'est pas un bug, mais l'utilisateur est simplement devenu confus. Ce qui est un type de bug différent, je suppose, mais tout aussi important.

Answer 10

Vous parlez de problèmes reproductibles mais uniquement sur certains systèmes. Celles-ci sont faciles à manipuler:

Première étape: en utilisant un type de logiciel distant, vous laissez le client vous dire quoi faire pour reproduire le problème sur le système qui l’a rencontré. Si cela échoue, fermez-le.

Deuxième étape: essayez de reproduire le problème sur un autre système. Si cela échoue, faites une copie exacte du système client.

Troisième étape: s'il échoue toujours, vous n'avez pas d'autre choix que d'essayer de le déboguer sur le système client.

Une fois que vous pouvez le reproduire, vous pouvez le réparer. Peu importe sur quel système.

Ce qui est délicat, ce sont des problèmes véritablement non reproductibles, c’est des choses qui ne se produisent que par intermittence. Pour cela, je devrai me mêler des rapports, des journaux et de la sévérité des attitudes. :)

Answer 11

Parfois, le bogue n’est pas reproductible, même dans un environnement de pré-production qui est la copie exacte de l’environnement de production. Les problèmes de concurrence sont notoires pour cela.

La raison peut être simplement due à l’effet Heisenberg, c’est-à-dire que l’observation change le comportement. Une autre raison peut être que les chances sont très faibles d’atteindre la combinaison des événements qui déclenchent le bogue.

Parfois, vous avez de la chance et vous disposez de journaux d'audit que vous pouvez lire, ce qui augmente considérablement les chances de recréer le problème. Vous pouvez également stresser l'environnement avec des volumes de transactions élevés. Cela compresse efficacement le temps. Ainsi, si le bogue survient, dites-le une fois par semaine, vous pourrez le reproduire de manière fiable en 1 jour si vous soumettez le système à 7 fois la charge de production.

Le dernier recours est le test de la boîte blanche: vous parcourez le code un par un en écrivant des tests unitaires au fur et à mesure.

Answer 12

La journalisation est votre amie!

Généralement, lorsque nous découvrons un bogue que nous ne pouvons pas reproduire, nous demandons au client d'activer davantage de journalisation (s'il est disponible) ou publions une version avec journalisation supplémentaire ajoutée autour de la zone qui nous intéresse. De manière générale, la journalisation que nous avons est excellente et a la capacité d’être très verbeuse, et la publication de versions avec une journalisation supplémentaire ne se produit pas souvent.

Vous devriez également envisager l’utilisation de dumps de mémoire (l’OMI relevant également de la journalisation). Produire un mini-vidage est si rapide que cela peut généralement être fait sur des serveurs de production, même sous charge (tant que le nombre de vidages produits est faible).

La façon dont je vois les choses: être capable de reproduire un problème est agréable, car cela vous donne un environnement où vous pouvez déboguer, expérimenter et jouer plus librement, mais - reproduire un bogue n’est nullement essentiel pour déboguez-le ! Si le bogue ne se produit que sur un autre système, vous devez tout de même diagnostiquer et corriger le problème de la même manière, c’est que cette fois, vous devez être plus intelligent sur la façon de le faire.

Answer 13

Il est important de catégoriser ces bogues (rarement reproductibles) et de les traiter différemment de ceux qui sont souvent reproductibles en fonction d'actions spécifiques de l'utilisateur.

1. Une description claire du problème ainsi que les étapes à suivre pour reproduire le comportement observé : la génération de rapports sans ambiguïté permet de comprendre le problème de la part de toute l'équipe en éliminant les conclusions erronées. Par exemple, l'écran vide de rapport utilisateur est différent du gel de l'IHM sur l'action de l'utilisateur. La séquence des étapes et le temps approximatif d’intervention de l’utilisateur sont également importants. L’utilisateur at-il immédiatement sélectionné l’option après la transition de l’écran ou at-il attendu quelques minutes? Un bug intéressant concernant le chronométrage est une voiture allergique à la glace à la vanille qui a dérouté les ingénieurs de l’automobile.

2. Paramètres de configuration et de démarrage du système : Parfois, même la configuration matérielle et la version du logiciel d'application (y compris la version des pilotes et du micrologiciel) peuvent faire l'affaire. Une non-concordance de version ou de configuration peut entraîner des problèmes difficiles à reproduire dans d'autres configurations. Ce sont donc des détails essentiels à saisir. La plupart des outils de rapport de bogue ont ces détails comme paramètres obligatoires à signaler lors de la journalisation d'un problème.

3. Journalisation étendue : cela dépend des fonctions de journalisation suivies dans les projets concernés. Lorsque nous travaillons avec des systèmes Linux intégrés, nous fournissons non seulement des journaux de diagnostic généraux, mais également des journaux de niveau système tels que dmesg ou les journaux de commandes top. Vous ne saurez peut-être jamais que la mauvaise partie n'est pas le flux de code, mais l'utilisation anormale de la mémoire / du processeur. Identifiez le type de problème et signalez les journaux pertinents pour enquête.

4. Revue de code et visite guidée : les équipes de développement ne peuvent pas attendre éternellement pour reproduire ces problèmes et prendre des mesures. Le rapport de bogue et les journaux disponibles doivent être examinés et diverses possibilités doivent être identifiées sur cette base à partir de la conception et du code. Le cas échéant, ils doivent préparer un correctif sur les causes fondamentales possibles et le diffuser parmi les équipes, y compris le testeur qui l’a identifié, pour voir si le bogue reproduit ce bogue.

5. Ne fermez pas ces problèmes en vous basant sur l'observation d'un seul testeur / équipe une fois qu'un correctif a été identifié et archivé : la partie la plus importante est peut-être l'approche suivie pour résoudre ces problèmes. Une fois la résolution de ces problèmes vérifiée, toutes les équipes de test / validation de différents sites doivent en être informées pour l'exécution de tests intensifs et l'identification d'éventuelles erreurs de régression. Seules la quasi-totalité d'entre elles (pratiquement la plupart d'entre elles) indiquent qu'elles ne sont pas reproductibles. La direction doit procéder à une évaluation de la fermeture.

Answer 14

S'il n'est pas possible de reproduire les journaux, effectuez des captures d'écran des étapes exactes à reproduire.

Answer 15

Il existe une nouvelle fonctionnalité intéressante dans Windows 7 qui permet à l’utilisateur d’enregistrer ce qu’il fait et d’envoyer un rapport - il est transmis sous forme de doc avec des captures d’écran de chaque étape. J'espère que cela aidera dans les cas où l'utilisateur interagira avec l'application dans un ordre auquel le développeur ne penserait pas. J'ai souvent vu de nombreux bugs, dont la logique selon laquelle le développeur utilise l'application ne correspond pas à la façon dont les utilisateurs finaux le font réellement ... ce qui entraîne de nombreuses erreurs subtiles.

Answer 16

La réponse acceptée est la meilleure approche générale. À un niveau élevé, il convient de peser l'importance de corriger le bogue par rapport à ce que vous pourriez ajouter en tant que fonctionnalité ou amélioration qui bénéficierait à l'utilisateur. Un bogue "non reproductible" pourrait-il prendre deux jours pour être corrigé? Une fonctionnalité pourrait-elle être ajoutée à ce moment-là, offrant aux utilisateurs plus d'avantages que ce correctif? Peut-être que les utilisateurs préféreraient la fonctionnalité. En tant que développeur, je suis parfois préoccupé par les imperfections que je peux voir. Les utilisateurs sont ensuite invités à faire part de leurs commentaires. Aucun d'entre eux ne mentionne réellement le ou les bugs que je peux voir, mais le logiciel manque une fonctionnalité qu'ils souhaitent vraiment !

Parfois, une simple persistance à essayer de reproduire le bogue pendant le débogage peut être l'approche la plus efficace. Pour que cette stratégie fonctionne, le bogue doit être «intermittent» plutôt que «non reproductible». Si vous pouvez répéter un bogue, même une fois sur 10, et que vous avez une idée de l'endroit le plus susceptible de se produire, vous pouvez placer des points d'arrêt à ces points, puis tenter de façon répétée de répéter le bogue et voir exactement ce qui se passe. J'ai constaté que cela était plus efficace que la journalisation dans un ou deux cas (bien que la journalisation soit mon premier contact en général).