Comment signaler des bugs de manière intelligente [fermé]

Question

Je souhaite rédiger (ou trouver) un guide de rapport de bogues efficace dans un style similaire à celui d'ESR Comment poser des questions de manière intelligente

Quels sont vos meilleurs conseils pour des rapports de bogues efficaces?

Answer 1

• Instructions pas à pas pour recréer le bogue
• Assurez-vous que vous avez tenté d'isoler le bogue pour lequel vous écrivez un bogue, au lieu de quelque chose qui pourrait en être la cause.
• La liste tente d’isoler le bogue avec un logiciel autre que le logiciel sur lequel vous écrivez un bogue
• Soyez disponible pour répondre aux questions et aidez-nous à résoudre / recréer le bogue

En bout de ligne, vous devez engager un certain niveau de réflexion critique lorsque le bogue est rencontré. Une fois que vous avez épuisé toutes les possibilités que cela puisse être de votre faute, écrivez un bogue. Si vous trouvez que c'est votre faute, mais que le logiciel que vous utilisez / testez aurait pu faire quelque chose de plus utilisable pour indiquer que c'était votre faute, écrivez quand même un bogue.

En outre, pour être vraiment un excellent rapporteur de bogues, vous devez faire appel à ceux qui testent le bogue pour les aider à le recréer. Il est probable que vous veniez de "maîtriser" & pour recréer ce bogue et il peut y avoir des étapes dont vous n'êtes pas conscient. Vous ne pouvez pas simplement vous plaindre et vous en aller, participer au processus et aider l'équipe en testant, recréant et dépannant.

Answer 2

Signalez les faits observables , puis votre interprétation de ces faits.

Parfois, les meilleurs rapports de bogues incluent quelque chose qui donne l'impression de comprendre le problème. Les rapports de bogues basés sur des faits mettent à jour cette précieuse ressource humaine.

Answer 3

• Procédure utilisée pour recréer le bogue, y compris ce qui était fait, quelle partie de l'application était utilisée et quel événement se produisait à ce moment-là.
• Déclaration de reproductibilité (fiable, non) - aide le développeur à comprendre à quel point il devrait être difficile de reproduire pour ne pas abandonner trop vite
• Captures d'écran ou documentation du message d'erreur / trace de la pile produite
• Criticité / Priorité du bogue (peut-il être évité, étapes d'évitement, est-il catastrophique, a-t-il un impact commercial, quel est le risque commercial, etc.)
• Environnement - dans quel environnement le bogue a-t-il été trouvé. À distance, local, etc.

Trop souvent, nos responsables de l’assurance-qualité pensent qu’ils peuvent simplement mettre un ticket en disant: voici mon exception sans documentation de sauvegarde. Il est presque impossible à reproduire et encore moins à résoudre le problème sans plus d'informations.

Answer 4

Ne supposez pas que le lecteur de votre rapport de bogue connaît le logiciel aussi bien que vous . Même la personne qui a écrit le logiciel peut ne pas savoir de quoi vous parlez s'il s'est écoulé suffisamment de temps depuis sa rédaction. Ecrivez-le pour que n'importe qui puisse comprendre et reproduire le problème.

Answer 5

Recommandez cet article: Comment signaler efficacement les bugs

Answer 6

Pour toutes les personnes qui ne regarderont pas quelque chose sans des étapes pour se reproduire:
Lors de mon premier travail coopératif en programmation, on m'a attribué un bogue qui était essentiellement une condition de concurrence aléatoire rendant le système instable. Cela se produisait à n'importe quel moment de l'exécution du système, et nous n'avions que quelques traces de pile pointant vers une section de code parfaitement correcte. Quelque part, un autre fil de discussion débordait de données, cela ne devrait pas être et si ce fil était au bon moment, il planterait. Notre QA a des accidents environ une fois par mois. Il a fallu deux semaines de fouille dans le système pour trouver le coupable (oui, un accès non contrôlé aux ressources partagées, un correctif à deux lignes) et le réparer. Il n’ya jamais eu d’étapes décentes à reproduire car il n’existait aucun moyen général de le reproduire (à moins de placer un paquet de rendement () au bon endroit). Si vous travaillez sur un système multithread, vous devez être prêt à traiter les bugs qui ne peuvent pas être reproduits de manière fiable, peuvent ne pas avoir d'étapes stables à reproduire, et pas seulement se plaindre du contrôle qualité car vous ne pouvez pas reproduire le bogue. .

Notez que ce qui précède n’est pas une excuse pour le contrôle de la qualité de ne pas inclure autant de détails que possible, mais il suffit de souligner que ce n’est pas toujours possible avec un logiciel moderne.

Answer 7

Écrivez les étapes pour reproduire le bogue. Si vous ne pouvez pas le reproduire, il ne sera pas réparé.

Answer 8

• Toujours signaler le numéro de version du logiciel testé
• Signalez toujours les versions de tout autre logiciel (navigateur, système d'exploitation, etc.)
• Toujours répertorier tout le matériel
• Étapes pour reproduire
• Symptômes du bogue
• Captures d'écran, traces, journaux, autres pièces jointes (le cas échéant)
• Quelle est leur importance - crash, interface utilisateur, etc.
• Indiquez si vous pouvez reproduire
• Tout ce qui a été essayé, qui reproduit ou non le bogue