Les testeurs, comme tout le monde, ont des réflexes acquis suite à leurs diverses expériences professionnelles. Certains de ces réflexes sont spécifiques aux tests… Parmi ceux-ci il y en a qui peuvent rapidement devenir handicapant pour l’efficacité du travail de testeur.
Voici certains mauvais réflexes auxquels on doit faire attention en tant que testeur :
Ouvrir un bug dès que l’on rencontre une anomalie
C’est une habitude et cela parait naturel. On exécute les tests et lorsque ceux-ci sont en échec, on ouvrir une fiche d’anomalie.
Néanmoins ce comportement peut vite s’avérer contre-productif. La première chose à faire lorsqu’un test est en échec est une analyse. Il peut avoir de nombreuses raisons pour qu’un test soi en échec sans que cela soit une anomalie de l’application.
Un test peut être en échec car il est mal écrit, non stable (ex : une recherche qui ne fonctionnerait que dans certaines circonstances : chercher un vol à une date où il n’existe pas), ou non maintenu. Un testeur doit être capable de se remettre en question. S’il y a des anomalies dans le code, il peut aussi y en avoir dans son test !
Un test peut également être en échec suite à un problème d’environnement ou des données (des vols étant ouverts disponibles uniquement sur 1 mois alors que l’on veut faire une réservation pour dans 2 mois).
Le bon réflexe est donc de toujours vérifier certains points avant d’ouvrir une fiche d’anomalie. Le problème peut venir des tests et dans ce cas ouvrir une fiche donne du travail inutile aux développeurs (ou toute autre membre d projet) et fait perdre du temps à l’ensemble du projet avec des allers-retours de cette fiche de bug ouverte.
Ré-exécuter manuellement un cas de tests automatisé en échec sans le maintenir
Un test automatisé est en échec ? Pas grave, je l’exécute manuellement et considère qu’il est en « succès ».
Cela semble du bon sens et fait gagner beaucoup de temps sur le moment. Dans certains cas il faut donc le faire mais… Dans tous les cas il ne faut pas oublier que ce test doit être mis à jour et le maintenir aussitôt que possible.
Exécuter manuellement les tests automatisés en échec car ils ne sont pas à jour revient à ne pas avoir de tests automatisés. Si la maintenance n’est pas faite régulièrement on se retrouve avec une « dette » de test trop importante et c’est souvent le début de l’échec des projets de tests automatisés.
Si l’on manque de temps pour la maintenance des tests automatisés, il faut faire un tri dans les tests et sélectionner un nombre de test qui est maintenable.
Toujours vouloir remettre en place les mêmes processus
« Ça a marché sur mes 2 dernières missions, ça marchera donc sur celle-là ! » Cette phrase ressemble beaucoup à une phrase qui est lancée aux testeurs quand ces derniers disent qu’il faut industrialiser les tests. On nous dit souvent « Ca a toujours marché comme ça, pourquoi faire différemment ? ».
Les testeurs ne supportent pas la seconde phrase… Cela n’empêche pas de pencher vers la première si l’on ne fait pas attention !
Les tests dépendent du contexte, les projets sont tous différents, les stratégies dépendent du produit. Certains processus très efficaces sur des projets peuvent être superflus voir même contre-productifs dans certains cas. Il faut savoir s’adapter
En tant que testeur on doit toujours se poser les bonnes questions, il n’y a pas de solution miracle qui fonctionne partout… Si c’était le cas nous serions déjà automatisés et nous ne parlerions pas de test automatisés mais bien de testeurs automatisés !
Ne pas prendre en compte le contexte (vouloir toujours faire tous les tests)
Pareil que pour le réflexe précédent. On peut le voir avec les processus mais aussi avec les campagnes de tests ou à tout autre moment de notre métier.
Selon les besoins les stratégies, les tests, les testeurs, les processus, les outils… changent. Ce n’est pas parce que cela fonctionnait bien sur le projet X à l’instant T1 que cela sera le cas sur le projet Y à l’instant T2.
Une contrainte récurrente est le temps. On doit pouvoir s’adapter au temps dont nous disposons. S’il n’est pas possible d’exécuter tous les tests prévus il faut choisir ceux que l’on exécutera et ceux que l’on n’exécutera pas.
Ne pas prendre le temps d’analyser ce qui n’a pas fonctionné
Si l’on veut évoluer, s’améliorer mais aussi rendre nos actions plus efficaces il faut prendre le temps d’analyser ce qui a été fait, et surtout ce qui ne s’est pas bien passé (comme la présence de bugs majeurs non détectés en test en production ou des problèmes de communication).
Je sais que l’on est souvent pris par le temps avec des timings serrés, des campagnes qui s’enchainent. Néanmoins, prendre le temps de se poser, d’analyser les erreurs, de savoir comment faire pour s’améliorer (en fait c’est de l’amélioration continue) est particulièrement efficace et le retour sur investissement est souvent très rapide.
Considérer certaines notions comme connues et ne pas prendre le temps de les expliquer
Je parle toujours de test, de nouveaux outils, de processus… Ce qui me semble la base ne l’est pas forcément pour les autres personnes avec qui je travaille.
En restant chez les testeurs (et donc sans tomber sur les différences développeurs/testeurs), de nombreuses notions ont des définitions différentes selon les expériences.
Il n’est pas rare qu’un testeur considère qu’un plan de test est juste une batterie de test à exécuter comme c’est le cas dans de nombreux ALM. Cette définition n’est pas la définition ISTQB et les incompréhensions arrivent vite dans ce cas.
Considérer que tout va bien et ne plus chercher à s’améliorer
Il y a toujours des choses à améliorer… Et ce même si tout est parfait à l’instant t. En effet nous vivons (ainsi que le logiciel sur lequel on travaille) dans un environnement mouvant. Il faut donc s’adapter !
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
