Pourquoi un simple « ça ne fonctionne pas » ne suffit-il pas ?

Quiconque a déjà travaillé dans l'IT a sûrement rencontré des problèmes de communication entre les programmeurs et les testeurs, ou dans d'autres cas. En parlant aux programmeurs, vous pouvez entendre de nombreuses anecdotes concernant les rapports de bogues et les commentaires qu'ils ont reçus. Travaillant en tant que testeur dans une agence Drupal, je vois ce problème de l'autre côté, mais je comprends l'équipe de développement. Lorsque je renvoie une tâche des tests, je me retrouve souvent à vouloir écrire simplement : “Ça ne fonctionne pas !”. Cependant, les situations dans lesquelles rien ne fonctionne réellement sont assez rares. Vous devez croire que si un programmeur a décidé de pousser son code en test, il est certain que cela fonctionne pour lui et il a vérifié au moins certains des chemins de base dans son environnement. C'est pourquoi nous devrions essayer et donner au développeur le plus d'informations possible sur l'erreur ou le bogue que nous avons réussi à trouver.

“Ça ne fonctionne pas !”

Un rapport ou un ticket qui ne contient pas suffisamment d'informations est inutile car il ne permet pas au développeur de recréer le bug et donc il ne leur permet pas de résoudre rapidement le problème. En général, je recommanderais de respecter le principe selon lequel il vaut mieux écrire trop que pas assez. Bien sûr, il est également important d'avoir une certaine modération et d'éviter d'aller trop loin. Ci-dessous, je vais vous présenter plusieurs éléments qu'il vaut la peine d'inclure dans un rapport de bogue.

Titre 

Une description courte mais précise de la nature de l'erreur, par exemple, validation incorrecte dans le formulaire de contact.

ID

Un numéro ou une série de caractères permettant à chacun de se référer sans ambiguïté à un ticket donné. De nos jours, grâce à l'utilisation de suivi de bogues, nous n'avons souvent pas à nous en inquiéter, car il est généré automatiquement pour chaque tâche et ticket.

Nom 

Fournir le nom et les coordonnées de la personne qui a trouvé le bogue permet à tous de discuter et de clarifier tout doute concernant le rapport (espérons qu'il n'y en aura pas beaucoup).

Version du code 

Une indication de la version du code sur laquelle la tâche a été testée. Selon la politique de l'entreprise, il peut s'agir par exemple d'un nom d'une version donnée du programme, du nom de la branche ou de la date de test. Il est important de préciser quelle version contient le bogue, car toutes les versions ne l'ont peut-être pas.

Priorité 

Dans la plupart des cas, la priorité signifie la période dans laquelle une erreur donnée doit être corrigée. Elle est souvent présentée à l'aide d'une échelle, telle que “critique, haute priorité, priorité normale, et basse priorité”. Vous pouvez estimer la priorité d'un bug donné en prenant en compte plusieurs facteurs:

• à quelle vitesse le bug doit-il être corrigé,
• dans quelle mesure cela affecte-t-il le fonctionnement de l'ensemble du projet,
• à quelle fréquence le bug se produit-il,
• ce bogue concerne-t-il une nouvelle fonctionnalité ou quelque chose déjà utilisé par vos utilisateurs. 

Dans ce cas, la priorité du bogue sera le résultat de ces facteurs, présentée sur une échelle, telle que erreur critique, erreur sérieuse, normale, basse priorité, suggestion. Bien sûr, nous pouvons également attribuer une catégorie distincte à chacun de ces facteurs et les décrire dans les tickets – cela varie d'une entreprise à l'autre. Cependant, il est crucial de catégoriser les bogues signalés.

Prérequis 

S'il y a des actions qui devaient être entreprises avant le test, ou s'il y a des conditions qui doivent être remplies avant que la recréation du bogue soit possible, vous devez les inclure dans votre ticket. Par exemple, le bogue apparaît uniquement si vous créez un compte utilisateur et lui assignez le rôle d'éditeur.

Environnement de test 

Il existe des situations dans lesquelles un bogue donné n'apparaîtra que sur une configuration matérielle spécifique. C'est pourquoi il est crucial de fournir des détails exhaustifs concernant le matériel sur lequel le bogue a été trouvé, votre système d'exploitation, votre navigateur, tous les logiciels qui pourraient affecter le fonctionnement du programme, la résolution de l'écran, etc.

Description du bogue/étapes pour recréer le bogue 

Bien sûr, la courte description d'un bogue dans le titre ne suffira pas; vous devez également décrire le problème de la manière la plus claire et précise possible. Vous pouvez commencer par une courte introduction expliquant le bogue; cependant, le plus important ici est de décrire toutes les étapes qui nous ont conduits à trouver le bogue. Vous ne devez pas utiliser de descriptions telles que “J'ai changé les fenêtres” ou “J'ai entré certaines données”, mais plutôt décrire précisément ce que vous avez cliqué et quelles données vous avez saisies dans les champs, car cela pourrait être l'entrée de certaines données qui provoque le bogue. Si vous testez une application web, vous devez fournir les URL des sites qui vous ont conduits à trouver le bogue.

Résultat actuel 

Tout ce qui s'est passé après avoir terminé toutes les étapes qui vous ont permis de trouver l'erreur doit également être décrit de manière fiable. Gardez à l'esprit d'éviter d'écrire des choses comme “Et puis une fenêtre d'erreur est apparue”. Bien sûr, vous devez inclure ces informations si cela s'est produit, mais n'oubliez pas d'ajouter quel type d'erreur cela contenait. Même si cela ne vous dit rien, cela peut en fait donner un indice au développeur pour trouver la source du problème.

Résultat attendu

Vous avez décrit les étapes qui vous ont conduit à trouver le bogue, vous avez décrit ce que vous avez vu et il semblerait que rien d'autre ne puisse être ajouté. En effet, très souvent, cela suffit; cependant, il y a des situations dans lesquelles les attentes liées au problème ne sont pas si évidentes. C'est pourquoi vous devriez toujours vous souvenir de déclarer clairement ce que vous attendez d'une tâche donnée. Cela permet à chacun d'expliquer les éventuelles différences dans la compréhension du fonctionnement du système et montre clairement ce qui doit être corrigé.

“Présentation – meilleure qu'un millier de mots...”

Indubitablement, l'une des meilleures méthodes de rapport de bogues est de les montrer directement au développeur. Faites-le s'installer devant votre écran et montrez-lui pas à pas comment recréer le bogue. En tant qu'auteur du code, il sait quoi chercher lorsque le bogue apparaît et où rechercher des informations supplémentaires sur ce qui s'est passé. Outre un message d'erreur, il devrait aussi être capable de remarquer d'autres indicateurs montrant que quelque chose ne fonctionne pas comme prévu. Bien sûr, souvent nous n'avons tout simplement pas l'opportunité de montrer directement les bogues, mais vous pouvez toujours essayer de trouver une alternative attrayante, qui facilitera notre travail même si elle n'est pas une présentation directe. Si vous savez que le bogue que vous avez trouvé n'est pas facile à décrire et plutôt complexe, essayez d'enregistrer votre écran pendant le test. Cela aidera certainement à comprendre le problème. Si le bogue n'est pas très complexe, essayez d'au moins inclure une capture d'écran et de marquer où le bogue se produit. De nombreuses personnes dans le monde sont des apprenants visuels et elles comprendront mieux le bogue en le voyant. Grâce à cela, même si elles ne parviennent pas à recréer l'erreur sur leur machine, elles sauront à quoi il ressemblait dans votre environnement.

Outils qui soutiennent le rapport de bogues

Tous les éléments ci-dessus peuvent être rapportés de nombreuses manières différentes : verbalement, dans un berceau de calcul, par e-mail, etc. Cependant, il est également important de suivre ce problème par la suite. Par conséquent, la plupart des entreprises utilisent des logiciels pour soutenir cela. Ci-dessous une courte liste de solutions à considérer lors du choix d'un tel outil:

• Jira (commercial),
• Bugzilla (open source),
• Mantis (open source),
• Redmine (open source),
• Trac (open source),
• Stryka (commercial),
• LeanTesting (gratuit mais des composants sont payants),
• FogBugz (commercial).

Résumé

Pour résumer, je vais vous donner quelques règles et principes de base qui doivent être observés lors du rapport de bogues:

• rappelez-vous de vous exprimer de manière claire et précise, afin que le développeur puisse recréer facilement le bogue,
• décrivez tous les symptômes indiquant que quelque chose ne fonctionne pas correctement, même si vous savez exactement quel est le problème,
• rapporter les bogues le plus rapidement possible,
• essayez toujours de reproduire le bogue deux ou trois fois, si vous n'y parvenez pas, mentionnez-le dans votre ticket,
• si vous avez l'opportunité de montrer l'erreur directement, faites-le,
• n'omettez jamais les faits qui vous semblent évidents dans votre ticket,
• si vous en avez l'opportunité, vérifiez si le bogue ne survient que dans une situation donnée ou sur une configuration matérielle donnée.