La série « Les petits trucs de testeur » a pour but de vous présenter rapidement et succinctement des points qui semblent être du détail mais aident fortement le testeur dans son quotidien.
Pour son premier numéro, nous nous attardons sur la fiche de bug.
Introduction
Récemment, lors d’une rétrospective d’une équipe avec laquelle je travaille depuis quelques années, un point positif en particulier est remonté:
« Marc, les fiches de bugs que tu crées sont super, on reproduit tout de suite et tout le temps le bug. »
Petite remise dans le contexte:
Ce retour, après plusieurs années s’explique car il y a eu une multiplication des ouvertures de fiches d’anomalie ces derniers temps. La raison n’est pas une baisse de la qualité mais lié à du temps qui a été dégagé ce qui m’a permis de faire de la supervision et des vérifications/tests en production… Et donc la découverte d’anomalies encore inconnues et généralement mineures.
A noter: je travaille à distance de l’équipe de développement et ne suis présent qu’à mi-temps!
Revenons en à la fiche d’anomalie
Suite à la multiplication des découvertes d’anomalies j’ai du écrire de nombreuses fiches de bug, tout en sachant que l’équipe de développement commencerait probablement à travailler sur ces anomalies pendant mon absence (mi-temps oblige!).
Afin d’assurer une détection et une reproduction rapide par l’équipe j’ai donc du créer des fiches très claires permettant de:
- Repérer l’anomalie et comprendre la différence entre ce qui se passe et ce qui devrait arriver
- Expliciter les conditions pour arriver à l’anomalie (dans mon cas: l’environnement, les composants intervenants dans l’anomalie, le type de fichier ayant causé l’erreur, quelle caractéristique du fichier a causé l’erreur)
- Donner un scénario pour reproduire l’erreur (scénario assez précis pour ne pas être sujet à interprétation… Un peu comme une écriture de cas de test mais sans obligatoirement l’attendu après chaque action)
- Décrire l’impact sur les utilisateurs
- Fournir des documents nécessaires à la reproduction (ex: proposer un objet/fichier à utiliser pour reproduire facilement l’erreur) et les documents montrant (ex: Screenshot) ou engendrant l’erreur (ex: fichier à importer générant l’erreur)
Il est vrai que la construction de ce type de fiche d’anomalie demande beaucoup de travail en amont mais cela permet de diminuer l’effet de distance, un meilleur archivage, une plus grande facilité pour créer un cas de test lié à l’anomalie mais surtout un meilleur taux de correction lors des retest!
Conclusion
Une fiche d’anomalie est un livrable sur lequel d’autres acteurs du projet vont travailler. Pour avoir un travail de qualité des autres acteurs il faut constituer des fiches d’anomalies de qualité
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.
6 réponses
Entièrement d’accord !
Même si cela peut paraître chronophage, ce point est primordial. Car ce document s’adresse généralement aux personnes qui devront « revoir leur copie » mais aussi… à son rédacteur.
En effet, au moment de la rédaction, les idées sont claires et il peut être tentant de faire des raccourcis sur certains détails qui semblent évidents sur le moment. Mais quand on doit vérifier à nouveau quelques semaine plus tard que l’anomalie a été traitée, il ne doit pas y avoir d’ambiguïté ! Quoi de plus râlant que dire « qu’est ce j’ai bien voulu dire en déclarant cette ano ? ».
Autre point capital selon moi (et si cela est techniquement possible) :
– Ajouter à la fiche d’anomalie une copie d’écran ou une photo de l’élément testé !
Parfois « la pseudo anomalie » vient du testeur qui se méprend sur la partie à tester ou se trompe de cible. (le testeur est un humain…)
Dans ce cas là une simple copie d’écran permet de vite lever le doute.
De plus, comme indiqué dans l’article, une simple capture d’écran peut vite contenir plusieurs données intéressantes (navigateur exploité, données périphériques visibles sur la copie, nom de l’utilisateur, date et heure, etc)
Bref, une fiche d’anomalie bien renseignée est un investissement qui doit rapporter tôt ou tard…
😉
Une astuce que j’ai chopée sur le blog LyonTesting : parfois j’utilise LiceCap, qui permet de faire des captures vidéo des bugs. Un bon complément et qui provoque toujours un petit effet « waw » ! 🙂
L’article en question : https://lyontesting.fr/fr/interview-dune-testeuse-4-maria-kedemo/
Bonjour,
Tout à fait d’accord. Il est très important de bien écrire sa fiche anomalie et pas uniquement lorsqu’on est à distance de l’équipe de développement durant mon expérience j’ai pu observer que c’est un gain de temps énorme pour les développeurs surtout lorsqu’on teste des applications assez complexes où lorsqu’on fait des tests interapplicatifs et je dois rajouter qu’un minimum d’analyse doit être effectué par le testeur afin de guider directement le développeur pour retrouver l’erreur j’encourage tout le temps cela c’est pour quoi dans les best practices qu’on intègre dans le process du test on le mets comme un élément indispensable à respecter même on mettons des check lists à vérifier pour ce fait. Merci pour cet article.
Bonjour je suis testeur mais je pense que vous avez tout à fait raison et je vais inclure cela dans ma méthode de travail.
Merci
Bonjour je suis testeur moi aussi je pense que vous avez tout à fait raison.
Avez vous un exemple d’une de vos fiches d’anomalie a partager pour mieux comprendre la forme que vous utilisez car pour le font tous est claire.
Merci
Bonjour
Désolé, le fiches d’anomalie auxquelles j’ai accès ne peuvent pas être partagées :s