Introduction
Depuis le début de ma carrière il m’est trop souvent arriver de tomber sur des cas de test que je comprenais de travers ou une campagne qui passait à côté d’un test très important.
Je ne vais pas le cacher, le problème venait souvent des anciens tests ou de tests fait par les autres mais aussi des miens!
Nous nous trouvons alors sur des problèmes d’écriture de cas de test (pas assez précis) ou de conception de ces derniers.
Par rapport à l’écriture, le problème tient souvent au fait que celui qui exécute n’est pas celui qui écrit (ou au temps important entre l’écriture et l’exécution) et donc que ce qui semble évident pour l’un ne l’est pas pour l’autre.
Pour la conception, le problème est différent. il peut y avoir des oublis, on peut ne pas penser à certains scénarios qui s’avèrent importants ou tout simplement ne pas avoir une connaissance suffisante.
Afin de remédier à ces 2 problèmes il existe une solution simple, efficace, un petit truc de testeur: La revue des tests!
La revue des tests
Il est vrai qu’une revue peut souvent paraitre rébarbative et sembler une perte de temps. Elle peut même être vue (et parfois utilisée) comme une inspection visant à montrer le mauvais travail de l’auteur du livrable révisé.
Il faut évidemment éviter ces dérives car ces dernières empêchent les revues de bien fonctionner!
Une revue qui fonctionne c’est:
- Des tests effectués plus tôt (vive le principe du test et le ROI!)
- Une communication fluidifiée et des échanges plus réguliers
- Une meilleure compréhension de ce qui est revue par l’ensemble des réviseurs
Bon, ça, c’est pour les revues en général. Lors d’une revue de test (formelle ou non) le livrable à réviser c’est les tests et même si cela peut sembler surprenant, il est important de tester les tests!
Concrètement, lors d’une revue de test on peut vérifier plusieurs points, les principaux que je recommande sont:
- Assurer une bonne compréhension du test par l’ensemble des acteurs (pas de « flou » ou de place à l’interprétation)
- Assurer le suivi des bonnes pratiques d’écriture afin d’avoir un patrimoine de test homogène
- Assurer que l’ensemble des tests créés pour une exigence/US/fonctionnalité couvre bien ce qui doit l’être (notamment avec des objectifs de test définis)
- Assurer que les tests qui doivent l’être seront facilement maintenables (normalement couvert en partie par les bonnes pratiques)
- Assurer, si besoin, que l’automatisation sera facilement réalisable sans avoir à ré-écrire le test
Conclusion
Faire l’économie des revues de test s’avère, à moyen terme (et même parfois court terme), très coûteux.
Une revue des tests permet aux tests d’être plus efficaces puis d’avoir une meilleure durée de vie, notamment en survivant au départ de son auteur ou en améliorant sa maintenabilité.
Les revues de test ne sont pas forcément très courantes, pourtant comme pour les autres revues (code et spécifications), les tester c’est les adopter!
Vous souhaitez vous aussi proposer un article dans la série « Trucs de testeur » afin de partager ce que vous faites au quotidien pour améliorer votre qualité de vie au travail et la qualité du logiciel testé ? Contactez la taverne pour le proposer et être publié en tant qu’invité!
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.
2 Responses
Hello Marc, Merci pour l’article !
c’est une pratique que je vais proposer chez nous à AXA. A suivre … 😉
Avec peut-être des critères de sélection des « projets » à prevoir : maturité des testeurs, enjeu des tests, …
Aurais-tu des pistes ? Re-merci
Bonjour Étienne,
Je dirais que le critère de sélection serait la volonté des testeurs de s’améliorer et potentiellement des anomalies trouvées tardivement. En général je fais cette revue à 2: l’auteur et 1 réviseur.
Il est également important de noter que plus le sujet est complexe (environnement, technologie, fonctionnel… voire même faible séniorité (ce qui rend un sujet plus complexe)) plus l’intérêt se fait sentir.
Je le fais maintenant toujours avec les équipes avec lesquelles je travaille. Cela améliore et homogénéise les tests que cela soit avec des tests issu du BDD ou d’autres tests (je l’ai même fait sur des chartes de tests exploratoires).
Si on veut « former » il faut un testeur expérimenté qui fera la revue avec le testeur qui doit monter en compétence mais c’est également faisable entre 2 testeurs ou juste un testeur et un autre membre de l’équipe.
Dans un cas plus usuel la séniorité n’est pas si importante du moment que l’état d’esprit et le souhait de s’améliorer soit présent (on peut néanmoins perdre en vitesse d’amélioration).
J’ai également un ami qui est allé encore plus loin dans son équipe. Les tests, tout comme le code sont sur une branche (GIT je crois) projet et font l’objet de commit qui doivent être acceptés.