Introduction
Si vous êtes dans l’IT depuis quelques années vous n’avez pas pu échapper au traditionnel « le test c’est pour les testeur » ou encore le « il y a un bug en production c’est la faute du testeur ». Même s’il est vrai que l’on voit cet écueil de moins en moins souvent (merci l’Agile) il persiste et se ressent à travers:
- Des vérifications/validations tardives dans le cycle de développement
- Des pyramides de test inversées: c’est à dire beaucoup de tests IHM et pas ou peu de test unitaires
- Des silos empêchant la collaboration entre les testeurs et les autres acteurs du logiciel
- Des remarques envers les testeurs comme: « Pourquoi y a-t-il ce bug en production ? »
Cette notion, certes de moins en moins importante, m’insupporte car elle va à l’encontre du bon sens, des principes du test et bien sûr de la qualité!
Analyse du concept de laisser les tests aux testeurs:
Laisser tous les tests aux testeurs c’est:
- Tester tard et donc ne découvrir que très (trop) tard des anomalies
Cela engendre des coûts de correction particulièrement importants, des retards ou des abandons de corrections.
- Se priver de points de vue complémentaires
Le testeur n’a que sa vision de testeur et son expérience de testeur. Un développeur apporte un point de vue technique, un profil métier apporte sa connaissance des utilisateurs et des besoins… Bref, ce n’est pas pour rien que la réunion des « 3 amigos » soit autant mise en avant ou encore que des professionnels comme Benjamin Butel écrivent des articles parlant de la complémentarité nécessaire entre testeurs et développeurs pour atteindre une bonne qualité.
- Empêcher toute collaboration en créant des silos et des processus néfaste pour la satisfaction de tous les acteurs
L’absence de communication régulière, et je parle là en connaissance de cause, entre testeurs et développeurs engendre des freins énormes sur les correctifs d’anomalies. La correction de certaines anomalies peut prendre 30 minutes avec une bonne communication et des échanges réguliers. Cette même anomalies peut prendre 2 semaines à être corrigées avec des aller-retours entre un développeur qui dit que « ça marche sur sa machine » et un testeur pour qui cela ne fonctionne pas…
Ces échanges sont délétères pour le moral car développent une défiance et une sentiment d’adversité plutôt qu’une confiance et un sentiment d’équipe.
- Diminuer fortement la qualité
Laisser les tests au testeur c’est aussi se priver de phases de synchronisation comme des revues ou des échanges précoces (ex: BDD). Ces phases sont essentielles afin de livrer un produit de bonne qualité mais aussi et surtout afin de livrer le bon produit! De même laisser le test axu testeurs c’est dire adieu aux tests unitaires (adieu les concept de TDD et de Software Craftsmanship).
Conclusion
Au final on est sur un concept anti-agile et une vision qui a fait beaucoup de mal au cycle en V! Le test au testeur c’est oublier que la qualité est l’affaire de tous. Que la qualité se construit avec des équipes soudées et heureuses. Je remercie énormément les méthodes Agile et le travail de l’ombre des testeurs qui ont permis de rendre minoritaire cette conception du test. J’espère que cet article contribuera à continuer de faire reculer cette « croyance ».
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.
