Blog RIA

Pièges à éviter, conseils rédactionnels et retour d’expérience, voici les sujets que nous aborderons dans cet article concernant la remontée d’un bug.

Il ne faut pas oublier que la personne qui va devoir corriger le problème n’est pas la personne qui l’a observé et généralement ils n’utilisent pas le même langage (développeurs vs testeurs/utilisateurs).

Le scénario de reproduction

« Il y a un bug ! » Qui n’a jamais entendu cette phrase ? Personnellement, c’est la phrase que nous utilisons quand nous avons envie de faire monter en pression un développeur. La réponse du développeur ressemble généralement à : « C’est toi le bug ! ». Traduction faite : comment veux-tu que je corrige ce bug si je ne sais pas dans quelles conditions il se produit? En résumé ce qui l’intéresse c’est de savoir où? quand? comment? se produit le bug.

Il est donc important lors de la détection d’un bug de repérer le triptyque suivant :

• Où : Dans quelle partie de l’application le bug a été détecté ?
• Quand : A quel moment de l’utilisation de l’application le bug se produit-il ?
• Comment : Quel est le scénario permettant de reproduire le bug à tous les coups ?

Quels sont les impacts de la non-détermination de ces informations ?

• Incompréhension du problème : correctifs inadaptés
• Reproduction impossible : correctifs irréalisables
• Bouclage entre le développeur et le testeur : perte de temps et d’efficacité

C’est le rôle du scénario de reproduction de mettre en lumière ces trois informations et d’éviter de tels impacts. L’écriture d’un bon scénario de reproduction est donc indispensable lors de la saisie d’un bug.

L’importance des représentations visuelles

Les représentations visuelles sont un moyen d’illustration qui permettent d’économiser beaucoup de temps en explications, cependant il faut rester prudent : un commentaire peut toujours être utile pour expliquer le contexte ou détailler ce qui se passe sur la représentation visuelle.

Sans explication une représentation visuelle ne permet pas forcément d’identifier le problème. A l’inverse, il n’est pas forcément évident de se représenter le problème lorsque celui-ci n’est pas illustré. Il faut donc déterminer, en fonction de la complexité du problème, le savant mélange composé des représentations qui parleront le plus au correcteur : explications, screenshots, vidéos, logs, traces, …, ou tout en même temps.

Aide à la saisie dans votre bug tracker préféré

Nous allons essayer de décrire dans cette section l’ensemble des informations devant être renseignées lors de la création d’une demande de correctif d’un bug sans tenir compte du bug tracker utilisé (nous utilisons Jira de l’éditeur Atlassian en interne, un bug tracker très souple et pratique d’utilisation).

Voici la liste des informations que nous considérons comme essentielles lors de la rédaction d’un bug :

• un titre : Ce titre doit être suffisamment explicite pour pouvoir repérer une demande parmi d’autres. Il s’agit d’un résumé de la description du problème. Il peut se suffire à lui même lorsque la demande est triviale et facilement compréhensible (ex : le bouton « Valider » devrait être vert)
• une description : Il s’agit de l’explication du problème. Elle doit être la plus détaillée possible afin de rendre la compréhension du problème facile. On pourra donc y retrouver une description générale du problème, un (ou plusieurs) scénario de reproduction, les informations de connexion (si il existe différents types d’utilisateur), …
• la criticité : Elle permet de signifier la gravité du problème. Cette donnée est essentielle afin de déterminer les actions à mener (ex : empêcher la livraison d’un produit qui contient un problème bloquant, déterminer les correctifs principaux à intégrer dans une roadmap)
• la version sur laquelle le problème se produit : elle permettra de retrouver facilement les nouveaux bugs et ceux causés par des régressions
• l’environnement (surtout dans le cas d’un problème lié au socle technique) : il permet de cibler le contexte technique dans lequel le bug se reproduit
• les données d’enrichissement de la demande : Il s’agit de toutes les représentations permettant au correcteur de cibler le problème. Il peut s’agir de fichiers de logs, de traces, de screenshots, de vidéos,…

Quelques règles supplémentaires

Ci-dessous un ensemble de règles que nous essayons d’appliquer au quotidien :

1. Rédiger correctement le bug : Outre les informations à décrire dans cette remontée de bug (Se reporter aux paragraphes précédents), il est important de s’exprimer dans un langage clair et compréhensible par tous.

2. Fournir un scénario de reproduction : Il arrive souvent qu’un bug se produise sans savoir vraiment quelle en est la cause. Il est du devoir du testeur de fournir un scénario de reproduction à ses développeurs. Notre politique par rapport à cette problématique est de ne pas diffuser le bug tant que celui-ci n’est pas reproductible. On nuancera cette approche lors de la détection de bug très critique afin d’avoir un avis extérieur.

3. Simplifier les étapes de reproduction : Moins il y a d’étapes, plus il sera facile pour le développeur de reproduire le problème et d’en trouver la cause.

4. Décrire et Numéroter vos étapes de reproduction : On part du constat qu’il est plus facile de lire un scénario en séquentiel plutôt que de le lire à plat. On préfèrera donc un scénario décrit de la manière suivante :

1. Lancer l’application
2. Cliquer sur le lien « Accéder à la recherche »
3. Choisir « Voiture » dans le type de recherche
4. Lancer une recherche -> KO aucun résultat n’est remonté

à

Lorsque je cherche des voitures, aucun résultat n’est remonté.

5. Agrémenter vos demandes : En plus du scénario de reproduction, il est important de préciser ce qui est observé lors de l’apparition du bug et le résultat qui est attendu. Dans le cas contraire, vous vous exposez à des remarques du type « Ce n’est pas un bug, c’est une feature ! » et à devoir reboucler avec le développeur sur le sujet.

6. Préférer l’utilisation du bug tracker à l’email : Le bug tracker simplifiera le suivi pour tous et se chargera par la même occasion de prévenir automatiquement les personnes concernées par email.

7. Cibler vos problèmes : Plusieurs techniques permettent de spécifier la provenance du problème :

• Définir le contexte dans le titre de la demande (ex: [Ecran de recherche] Aucune voiture remontée)
• Préciser le composant technique mis en cause (certains bugs trackers autorisent la création de composants)
• Préciser l’environnement technique dans lequel le bug se produit (de la même manière que les composants, certains bug trackers permettent la saisie de cette donnée)

8. Affecter des demandes au Chef de Projet : Le chef de projet est en charge du bon déroulement du projet : c’est lui qui gère la roadmap (feuille de route). Pour se faire, il doit garder en permanence un œil sur toutes les composantes de la réalisation et c’est donc à lui que doivent revenir toutes les tâches afin qu’il puisse les dispatcher en fonction des priorités, des disponibilités de chacun et de la criticité des demandes qui lui sont remontées.

9. Gérer les doublons : Dans l’idéal, la personne qui constate le bug vérifie qu’un bug similaire n’a pas déjà été créé. Il peut arriver cependant qu’un bug soit saisi en double (exemple : 2 testeurs différents OU un testeur et un client). Comme vu précédemment, le chef de projet à une vision globale des demandes, il saura donc quelles sont celles qui sont en double et fermera les demandes inutiles. Certains bug tracker permettent de lier des demandes entre elles, il est alors possible de lier 2 bugs similaires entre eux.

Il est important de noter que ces bonnes pratiques ne sont pas exhaustives et qu’il n’est pas forcément nécessaire d’utiliser ces techniques dans tous les cas. Il ne faut pas considérer une remontée de bug comme parfaite lorsque celle-ci est surpeuplée de diverses représentations du même problème. Au contraire, le plus important est de rester le plus simple possible et de se concentrer sur les informations nécessaires et suffisantes.