Reproduire un problème¶
On ne peut pas résoudre un problème si l'on n'a pas le problème en premier lieu. Par conséquent, la reproduction du problème est une condition préalable à sa résolution. Dans le domaine des logiciels, les problèmes sont communément appelés "bogues", et les questions sont souvent appelées "rapports de bogues".
Quelqu'un a fourni un rapport de bogue. Vous devez vous assurer que les étapes décrites par le rapporteur aboutissent au bogue signalé. Pouvez-vous reproduire le même résultat en faisant exactement ce qui est décrit dans le rapport ? Si ce n'est pas le cas, vous devez comprendre pourquoi.
Pour commencer à reproduire un problème, vous devez disposer d'un environnement de développement configuré.
Bugs dans le code¶
Dans une situation idéale, vous aurez la même configuration que la personne qui a signalé le bogue, vous suivrez les étapes et vous serez en mesure de reproduire le bogue tel qu'il est décrit. Dans de nombreux cas, cependant, ce ne sera pas aussi simple. De nombreux rapports de bogues ne contiennent que de vagues explications et un vague ensemble de conditions. Le problème est que de nombreux bogues varient en fonction de l'ensemble des conditions impliquées, y compris la manière dont ils sont utilisés, diverses conditions préalables, le système d'exploitation, la version du système d'exploitation, l'architecture du processeur ou le fait que la machine de l'utilisateur soit ancienne et lente ou nouvelle et rapide. Plus nous disposons d'informations sur la situation entourant le bogue, mieux c'est. Essayez de reproduire l'ensemble des conditions fournies par le rapporteur. Si vous n'y parvenez pas, la prochaine étape consistera peut-être à demander plus d'informations à la personne qui a signalé le bogue.
La meilleure façon de reproduire un bogue est d'utiliser le plus petit exemple possible qui présente encore le problème. La plupart du temps, les rapporteurs ne fourniront pas d'exemple minimum viable ; s'ils fournissent un exemple, il sera copié directement à partir de leur application "réelle". Votre objectif est de réduire le rapport à la forme la plus simple possible qui présente le problème. Le meilleur cas de reproduction est le plus petit programme possible. Cette réduction est elle-même utile car elle permet de déterminer quel est le problème réel. N'importe qui peut prendre l'exemple minimal, l'exécuter et observer le bogue décrit.
Bugs dans la documentation¶
Les bogues dans la documentation peuvent se manifester de différentes manières. Il y a des problèmes de formatage qui entraînent des problèmes de rendu. Parfois, il ne s'agit même pas d'un bogue ; la personne peut avoir mal lu la documentation ou avoir commis une véritable erreur. Cela ne signifie pas nécessairement qu'il n'y a pas de problème avec la documentation. Le contenu peut être peu clair ou imprécis, laissant place à la confusion ou à une mauvaise interprétation. Il est possible qu'un concept qui devrait être discuté ne le soit pas, parce qu'il n'est pas du tout documenté.
Lorsqu'un bogue est signalé pour un problème de documentation, vous devez vérifier que le problème signalé existe toujours. Dans le cas des problèmes de rendu, vous devrez construire la documentation pour voir si vous pouvez reproduire le problème. Pour les problèmes de contenu, il suffit de vérifier que personne n'a soumis de mise à jour.
Mise à jour de la question¶
La dernière étape du processus de triage consiste à documenter vos conclusions en laissant un commentaire sur le problème.
Si vous êtes en mesure de reproduire le problème exactement comme il est décrit, c'est tout ce que vous avez à dire. Laissez un commentaire indiquant que vous avez confirmé que vous rencontrez le même problème, de la manière exacte décrite par le rapporteur original.
Si vous êtes en mesure de fournir un contexte supplémentaire, donnez-en les détails. Il peut s'agir de la possibilité de reproduire le problème sur un système d'exploitation différent, ou avec une version différente de certains des logiciels concernés, ou tout autre élément différent du rapport original.
Si le rapport original ne contient pas les détails dont vous avez besoin pour reproduire le rapport, incluez ces détails. Il peut s'agir de fournir des détails sur le système d'exploitation ou la version que le rapport original ne mentionnait pas, des journaux plus complets ou des traces de pile, ou des instructions plus claires sur la séquence exacte des opérations nécessaires pour reproduire le problème. Si vous avez développé une méthode plus simple pour reproduire le problème (ou si le rapport original n'a pas fourni de cas de reproduction), vous pouvez inclure les détails de cette méthodologie de reproduction.
Si vous ne parvenez pas à reproduire le problème, laissez également un commentaire détaillant ce que vous avez essayé. Savoir où un problème n'existe pas est presque aussi important que savoir où il existe, car cela permet de réduire les causes possibles. Si vous avez des hypothèses sur les raisons pour lesquelles vous ne parvenez pas à reproduire le problème (par exemple, si vous pensez qu'il s'agit d'une erreur d'utilisation ou que le problème a été résolu par une récente mise à jour du système d'exploitation), incluez ces spéculations dans votre commentaire.
Enfin, vous pouvez faire part de vos recommandations à l'équipe centrale. Si vous pensez que le rapport original est erroné, suggérez que le problème soit clos ; si vous avez une théorie sur la cause du problème, vous pouvez également la suggérer. Vos commentaires aideront l'équipe centrale à déterminer comment faire passer le problème à l'étape suivante.
À ce stade, vous pouvez choisir d'essayer de résoudre le problème que vous venez de reproduire ; vous pouvez également noter vos conclusions et essayer de reproduire un autre problème.