Coup de gueule: arrêter avec « le test c’est pour les testeurs »!

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.

Publié par

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s