Une fiche de bug ?
Quand on est testeur et que l’on parle de bug, on pense très vite à la fiche de bug.
Cet outil très utile a plusieurs utilité. La première est de donner une information qui va permettre de reproduire le bug, de potentiellement le corriger et de suivre son processus de résolution. La seconde utilité de la fiche de bug est de constituer une base de connaissance et d’aider à l’amélioration continue (par exemple avec des indicateurs).
Ces deux usages ont une vraie valeur ajoutée qui ne peut être atteinte qu’avec un minimum d’informations. On retrouve souvent des éléments comme ceux-ci dans une fiche de bug:
- Un titre qui décrit très rapidement le problème
- Une criticité pour l’impact sur le service
- Une priorité pour l’impact business (à ne pas confondre avec la criticité)
- Une description du bug
- Un scénario pour reproduire le bug avec le résultat final comparé à celui attendu
- L’environnement sur lequel on a produit le bug
- Les tests liés et/ou impactés
- Les fonctionnalités liées et/ou impactées
- Le type de bug (régression, fonctionnel, sécurité, performance, accessibilité, UX…)
- La version du logiciel
De même, chaque fiche de bug a un cycle de vie entre le moment où le bug et découvert et celui où il est résolu.
La fiche de bug n’est pas toujours présente!
La fiche de bug est très utile et a une vraie plus-value dans de nombreux contextes… Néanmoins vous avez sûrement remarqué qu’il n’existe pas forcément une fiche de bug pour chaque bug détecté.
Je pense notamment à des contextes comme:
- les bugs trouvés lorsque que le développeur développe une fonctionnalité
- des bugs trouvés lors des tests dans une équipe agile
- des bugs liés à du paramétrage
- des bugs « éphémères », qui arrivent rarement sans que l’on sache pourquoi…
Le manque à gagner avec l’absence de fiche de bug
Pour le point 1, on peut estimer qu’il est normal de ne pas tracer les bugs directement liés à l’activité de développement. La question se pose plus pour des bugs qui seraient découverts et corrigés lors de ce développement mais étant indépendant. Ne pas avoir de fiche de bug sur ce point revient à perdre de l’information sur une faiblesse de l’application mais aussi, si manque de communication dans l’équipe, un manque de connaissance des acteurs de l’équipe.
Pour le point 2, les bugs trouvés lors des tests dans une équipe agile, la perte d’information est criante. Si le bug n’est pas corrigé suffisamment rapidement on peut vite « oublier » des éléments liés à ce bug. De même, cela peut être dommageable pour la partie amélioration continue lorsque l’on veut identifier des potentielles faiblesses du produit. Enfin cela limite la capacité à montrer l’apport du test avec sa capacité à détecter des bugs avant leur arrivée en production.
Pour le point 3, c’est des éléments souvent rapidement corrigés, l’absence de fiche de bug a toute fois tendance à « invisibiliser » ce type de problème.
Pour le point 4, on est plus ici sur une incapacité de reproduction, l’absence de fiche de bugs ne permet pas d’évaluer le niveau d’instabilité du produit. De même, cela limite la capacité d’investigation qui aurait potentiellement permis de reproduire de manière sûre (même si avec un autre scénario) le bug.
On peut alors se demander pourquoi on ne fait pas de fiche de bugs ?
Les raisons pour lesquelles on ne fait pas de fiche de bug
La principale raison, quelle que soit le contexte énoncé auparavant, pour laquelle on ne fait pas de fiche de bug est une raison de temps.
Dans le contexte du développement, le développeur ne va pas sortir de son travail pour décrire un bug qu’il va ensuite corriger dans la foulée. Non, il va directement le corriger!
Dans le contexte des équipes agiles, la communication peut être très fluide dans l’équipe. Il en est de même avec les correctifs qui peuvent être très rapides. Si l’on fait du pair-testing avec le développeur, il n’y a d’ailleurs pas besoin de fiche pour expliquer comment se produit le bug, le développeur a participé au déclenchement du bug!
Pour le paramétrage, cela peut souvent être lié à un oubli ou une inattention. Dans certains cas il est plus rapide de corriger le bug que d’écrire la fiche de bug.
Enfin, pour le bug éphémère. On est souvent sur une sensation de perte de temps avec un fiche qui va rester ouverte jusqu’au moment où un ménage sera fait et qu’elle sera fermée.
Alors, fiche de bugs ou pas fiche de bugs ?
J’ai envie de dire que cela dépend énormément du contexte.
Il faut être capable de peser le pour et le contre. L’investissement de l’écriture d’une fiche de bug est-il remboursé par ce qu’il apporte ?
Je dirais néanmoins, que plus on est avancé dans le processus de développement, plus il est intéressant d’avoir une fiche de bug notamment pour des délais de correction et d’éloignement entre la personne qui détecte le bug et la personne qui la corrige.
Voici une proposition de présence ou non de fiche de bug qui est assez générique:
| Phase de développement / test | Fiche de bug ? |
| Conception / design | Non possibilité d’avoir un rapport de revue avec la liste des défauts et actions à effectuer |
| Développement | Non |
| Tests dans l’équipe | Oui / Non cela dépend vraiment de comment fonctionne l’équipe. Dans le cas où l’on veut travailler sur certains indicateurs cela devient obligatoire |
| Tests métiers | Oui lorsqu’il y a un problème détecté à ce niveau là c’est souvent lié à une incompréhension de l’attendu de l’équipe. |
| Production | Oui |
A noter: la contenu et la précision de la fiche de bug peut (doit ?) également varier en fonction des besoin et de ce qui est attendu. Un bug détecté en production doit avoir une fiche avec beaucoup d’informations alors qu’un bug détecté lors des tests de l’équipe peut ne contenir qu’un titre… Notamment si l’on souhaite s’en servir juste pour des suivis d’indicateurs comme le First Pass Yield.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
