Que faire des bugs qui ne font pas de reproches?

J'ai un testeur qui pendant le test aura une erreur (ok jusqu'à présent), mais il le signale fréquemment immédiatement. Nous (les développeurs) constatons ensuite que le testeur n'a pas essayé de reproduire le problème et (lorsqu'on lui a demandé) ne peut pas trouver un moyen de le faire se reproduire.

Maintenant ce sont toujours des bugs, je ne veux pas les ignorer. Mais sans reproches, je suis un peu coincé. Parfois, il y a une trace de pile (bien que souvent elle ne soit pas utile car il s'agit d'un framework compact et il n'y a pas de numéro de ligne). Mais quand il y en a un, je peux prendre la trace de la pile et ouvrir le code et commencer à deviner, mais cela ne conduit pas à des "correctifs" testables.

Que faites-vous dans des scénarios comme celui-ci?

Un bug sans contexte n'est pas un bug, c'est un coup de chance. Le problème pourrait être votre code, ce pourrait être une bibliothèque tierce, ce pourrait être le matériel, ou ce pourrait être le rayonnement solaire provoquant un seul bit à basculer de lui-même. Si vous ne pouvez pas le reproduire avec au moins une certaine régularité (même si seulement "cela se produit une fois toutes les 10 ou 20 fois que je fais X"), ce n'est pas beaucoup mieux que votre testeur vous disant "Quelque chose a mal tourné quelque part - corrigez-le" .

Vous devrez peut-être expliquer à votre testeur que son travail ne consiste pas simplement à générer des entrées jusqu'à ce que quelque chose se casse. Si c'était le cas, vous pourriez le remplacer par un générateur de nombres aléatoires. Une partie de son travail consiste à identifier les bugs, ce qui implique d'identifier comment les produire.

En fin de compte, si ni le développeur ni le testeur ne peuvent reproduire le bogue, il doit être fermé mais marqué comme tel.

Cependant, le temps qu'il vous faut pour arriver à ce point est discutable.

Certaines personnes diraient que si ce n'est pas immédiatement reproductible, il devrait être fermé immédiatement.

Je m'efforce généralement d'essayer d'obtenir plus d'informations de la part de l'auteur du problème. Il y a peut-être quelque chose qu'ils ont oublié dans le rapport original. Une conversation sur les étapes requises peut souvent révéler les informations manquantes.

Une dernière pensée - fermée comme «sans reproches» ne signifie pas fixe. S'il y a un vrai problème, il se révélera tôt ou tard et avoir toutes les informations que vous pourrez vous aider lorsque vous pourrez enfin reproduire le problème.

Quelques suggestions supplémentaires:

1. Ajoutez la journalisation (et pas seulement un enregistreur de frappe:}) à votre code produit. Les bogues «sans reproches» peuvent être des bogues, mais il peut s'agir d'une corruption de mémoire ou d'état qui ne se produit que sur un système sale utilisé de manière imprévue (c'est-à-dire comme un ordinateur client). Les informations de journalisation ou de traçage peuvent vous aider à déterminer ce qui a pu être erroné lorsque le testeur a trouvé le coup de chance.

2. Analysez le reste des bogues «sans reproches» dans la base de données (ou tout ce que vous utilisez pour le suivi des bogues). Souvent, les douves s'agglutinent dans une zone du produit. S'il semble qu'un composant soit en faute, examinez le code du composant pour une éventuelle fragilité, ajoutez une journalisation supplémentaire à ce composant - ou les deux.

3. Prenez environ une demi-heure et regardez votre testeur. Leur approche peut vous donner une idée de ce qui n'a pas fonctionné (par exemple, "intéressant - je ne savais pas que vous pouviez accéder à ce dialogue de cette façon"). Vous pouvez également constater qu'ils sautent involontairement une étape de dialogue ou de configuration. Cela vaut la peine d'investir du temps pour se mettre un peu dans la tête.

Je fais de l'AQ sur un grand code commercial, ce scénario irritant revient trop souvent. Habituellement, cela indique qu'il n'y a pas de procédures à toute épreuve pour la construction du binaire sur toutes les plates-formes que nous prenons en charge. Donc, si le développeur crée son propre code (qu'il doit faire pour déboguer et corriger), et ne suit pas la même procédure de construction à la lettre, il y a une chance que les bogues dépendants du système semblent disparaître comme par magie (ou apparaître) . Bien sûr, ces choses sont généralement fermées avec "fonctionne pour moi" dans la base de données de bogues, et si elles échouent la prochaine fois que ce problème est exécuté, le bogue peut être rouvert. Chaque fois que je soupçonne qu'un bogue peut dépendre du système, j'essaie de le tester sur diverses plates-formes et de signaler dans quelles conditions il se produit. Souvent, un problème de corruption de mémoire apparaît uniquement si les données corrompues sont suffisamment importantes pour provoquer un crash. Certaines plates-formes (combinaisons HW et OS) peuvent se bloquer plus près de la source réelle de la corruption, ce qui peut être très précieux pour le pauvre gars qui doit la déboguer.

Le testeur doit apporter une valeur ajoutée, au-delà du simple fait de signaler que son système présente une défaillance. Je passe beaucoup de temps à éliminer les faux positifs - peut-être que la plate-forme en question était surchargée ou que le réseau avait un problème. Et oui, parfois, vous pouvez obtenir quelque chose qui est vraiment affecté par des événements de synchronisation aléatoires, les bogues matériels peuvent souvent être comme un exemple de proto: si deux demandes de données reviennent exactement à la même période d'horloge et que la logique matérielle pour gérer le conflit potentiel est défectueuse, alors le bogue n'apparaîtra que par intermittence. De même avec le traitement parallèle, à moins que, par une conception soignée, vous n'ayez contraint la solution à être indépendante du processeur qui s'est avéré être le plus rapide, vous pouvez obtenir des bogues qui ne se produisent qu'une seule fois dans une lune bleue, et leur imporbabilité statistique fait du débogage un cauchemar.

De plus, notre code est mis à jour, généralement plusieurs fois par jour, le suivi d'un numéro de révision de code source exact pour quand il est allé vers le sud peut être des informations très utiles pour l'effort de débogage. Le testeur ne doit pas être dans une relation contradictoire avec les débogueurs et les développeurs, il est là au sein d'une équipe pour améliorer la qualité du produit.

Il existe deux types de bogues non reproductibles:

1) Ceux qu'un testeur (ou un utilisateur) a vu une fois mais n'a pas pu ou pas tenté de reproduire.

Dans ces situations, vous devez:

• Vérifiez très brièvement le cours des actions de base qui a montré le défaut pour vous assurer qu'il n'est pas reproductible.

• Parlez au testeur / utilisateur pour voir si d'autres informations peuvent vous aider.

• Croisez-les avec d'autres défauts qui pourraient être liés pour voir si vous avez suffisamment d'informations pour les examiner en fonction de plusieurs instances. Vous constaterez peut-être que ce seul problème ne vous donne pas suffisamment d'informations pour continuer, mais lorsqu'il est associé à un certain nombre d'autres problèmes, il peut vous suggérer quelque chose de mal qui mérite d'être étudié.

• Si vous n'avez toujours pas assez pour continuer, vous devez expliquer à l'utilisateur / testeur que vous n'avez pas suffisamment d'informations. Expliquez-leur poliment à quoi ressemblerait suffisamment d'informations et pourquoi elles sont nécessaires.

2) Ceux où ils ne peuvent pas être reproduits de manière fiable, mais il existe suffisamment de preuves (en termes d'occurrences répétées) pour suggérer que le défaut existe, alors j'ai tendance à voir que ce sont des problèmes de développeur et que le développeur - pris en charge par le testeur / utilisateur - doit enquêter.

Cela risque d'être lent et douloureux, vous devrez probablement parcourir le code, ajouter plus de journalisation, consulter les données et parler en profondeur aux testeurs / utilisateurs, mais s'il y a suffisamment de preuves pour suggérer que c'est probablement là est un problème dont vous devez vous approprier et faire tout ce qui doit être fait pour y remédier.

Il semble que cela se produise relativement fréquemment - ce qui me fait me demander, est-ce parce que la plupart des bogues sont vraiment difficiles à reproduire, ou est-ce pour une autre raison qu'il n'essaie pas? Savez-vous pourquoi il n'essaie pas de reproduire le problème? Est-ce parce qu'il ne réalise pas à quel point c'est important pour vous? Ou est-ce peut-être qu'il a d'autres pressions - un gestionnaire de tests qui veut juste qu'il passe rapidement les tests alloués et jette les bugs sur le mur, par exemple? Ou peut-être qu'il ne sait tout simplement pas comment s'y prendre?

Je conviens avec d'autres que travailler sur une meilleure journalisation est une priorité. En attendant, si vous pensez que le manque de compétence / confiance des testeurs peut être un problème, alors j'aime vraiment cet article de Danny Faught sur l'isolement des bogues - vous pouvez le lui indiquer pour commencer.

Si le problème s'avère être dû à la pression de la direction - vous avez ma sympathie, car c'est difficile à résoudre, surtout si les testeurs et les programmeurs relèvent de différents gestionnaires et que les gestionnaires ne sont pas enclins à "aider" une autre équipe.

Généralement, je note qu'il n'est pas reproductible, mais laissez-le ouvert jusqu'à ce que ce lot de tests ou d'itérations soit terminé.

S'il n'a pas été reproduit à ce stade, il est fermé, mais peut être rouvert s'il est rencontré à nouveau.

collez un enregistreur de frappe sur la station de travail de ce testeur!

Eh bien, la première tâche est d'avoir un système de test reproductible. Votre testeur doit avoir un processus bien défini - automatique si possible.

Ont ces trois conditions:

• Même binaire
• Mêmes étapes
• Même machine

Si le bogue apparaît sporadiquement avec les 3 conditions ci-dessus, commencez à vous isoler davantage. Tenez compte de chaque niveau de la pile système et de sa configuration.

Une façon de détecter les erreurs de gestion de la mémoire consiste à exécuter le programme sur plusieurs systèmes d'exploitation avec plusieurs compilateurs. Valgrind peut également vous aider.

Cependant, les systèmes généralement parallèles sont susceptibles d'induire des bogues non reproductibles. Des choses comme les tailles de tampon et les vitesses de traitement, asynchrone, verrous de base de données, entrelacements d'écriture de mémoire variable; tous ces éléments peuvent générer des problèmes. Et ainsi de suite et donc pas.

Tout d'abord, vous devez avoir une procédure de test rigoureuse (mais je vous comprends, dans mon entreprise ce que vous avez décrit se produit fréquemment).

Selon la gravité du bogue, vous pouvez y consacrer du temps ou (mieux) l'ignorer jusqu'à ce que des étapes de repro soient fournies.