Faites des développeurs la première ligne de test

Cinq minutes du temps des développeurs peuvent tout changer

Voici une stratégie simple mais redoutablement efficace : impliquez les développeurs dans le test du code de leurs collègues avant qu’il n’arrive chez les testeurs. Cette approche réduit les bugs évidents, laisse aux testeurs le temps de se concentrer sur les problèmes complexes et allège la charge administrative du suivi des anomalies.

J’ai mis cette idée en pratique pour la première fois il y a des années, alors que je pilotais les tests pour une entreprise qui fournissait des équipes de développement logiciel sur mesure. Le défi ? Les clients ne voulaient en général payer que des développeurs, pas des testeurs. J’ai donc dû apprendre aux développeurs à tester et construire un processus de test adapté à leur façon de travailler. L’équipe était formidable, et les résultats ont été très instructifs !

Le changement qui a fait la plus grande différence ? Une règle toute simple : pour chaque pull request, les développeurs devaient faire deux choses – une revue de code et un rapide test manuel du nouveau code de leur collègue, avant toute livraison sur la branche principale. Le but n’était pas de passer des heures à tester. En règle générale, les développeurs devaient plutôt consacrer cinq minutes à vérifier l’essentiel et à utiliser leur intuition et leurs connaissances pour repérer les défauts évidents. S’ils passaient effectivement plus de cinq minutes à tester, c’est qu’ils avaient trouvé quelque chose qui allait faire gagner bien plus de temps par la suite.

Voici ce qui s’est passé :  

1. Les problèmes évidents ont été détectés tôt – exactement comme les fautes de frappe que nous laissons tous passer dans nos propres textes, mais que les autres repèrent tout de suite. Le temps jusque-là consacré à l’administration des bugs a été libéré, puisqu’un correctif pouvait être fait immédiatement, avant la livraison.  

2. La collaboration s’est nettement améliorée. Au lieu de se cacher derrière leur code, les développeurs discutaient ouvertement des fonctionnalités, des exigences et des solutions alternatives. Ces échanges ont donné de meilleures conceptions, des spécifications plus claires et même un développement plus rapide.

Ma théorie de départ était que les développeurs vérifieraient deux fois leur travail pour ne pas passer pour des incompétents, puisque le collègue assis à côté allait le tester. Ce n’est pas du tout ce qui s’est passé ! Ce que je n’avais pas prévu, c’est à quel point ce petit investissement de temps ouvrait l’espace à un vrai dialogue. Sous la pression des livraisons, il n’est pas rare que les équipes fassent l’impasse sur ces discussions. En imposant une pause pour tester, nous avons déclenché une collaboration qui a diffusé les connaissances, aligné les priorités et soudé l’équipe. Au final, il ne s’agissait plus d’éviter de mal paraître, mais de créer ensemble quelque chose de remarquable.  

J’ai obtenu les mêmes résultats dans une autre organisation de développement, où j’ai animé un atelier sur quelques jours. Plusieurs équipes de développement s’y partageaient une poignée de testeurs, submergés de bugs simples et évidents, sans plus aucun temps pour des tests approfondis. Dès que les développeurs ont pris en charge le premier test, les testeurs ont pu se concentrer sur ce qu’ils font le mieux : mettre à profit leurs compétences en conception de tests pour révéler des problèmes complexes. En outre, certains problèmes qui exigeaient une connaissance technique pointue du code étaient désormais détectés très tôt. Selon leur retour, c’était le changement le plus marquant qu’ils aient jamais apporté à leur processus de développement, alors qu’il comptait parmi les moins coûteux.

Et pourtant, étonnamment, beaucoup d’organisations semblent résister à ce mode de travail, alors même que de nombreuses approches modernes de développement, de l’Extreme Programming aux différentes pratiques agiles, prônent des démarches similaires. J’ai eu un jour un débat animé avec un responsable du développement qui soutenait que les développeurs ne devaient pas tester leur code, JAMAIS ! Ce projet a végété pendant huit mois, enfermé dans un cycle où la courbe des bugs critiques ne tendait jamais vers zéro. Il a finalement été réduit à une fraction de son périmètre initial pour pouvoir être livré tout court.  

Pourquoi est-ce que ça marche ?

• Un regard neuf repère ce qui vous échappe. L’effet tunnel est naturel – nous sommes tous humains.
• Les développeurs ont des connaissances techniques spécifiques. Certains problèmes sont plus efficacement détectés par des développeurs qui connaissent intimement les aspects techniques du code.  
• La collaboration s’épanouit quand on lui laisse de la place. Ce test de cinq minutes ne sert pas qu’à trouver des bugs : c’est l’occasion de discuter des exigences, de partager des connaissances et de s’aligner sur les objectifs.  

Le message à retenir est donc simple : faites des développeurs la première ligne de test. C’est un changement peu coûteux et à fort impact, qui améliore la qualité, soulage les testeurs et réduit le casse-tête d’une administration des bugs fastidieuse. Et en prime ? Votre équipe pourrait bien se mettre à mieux travailler ensemble.  

Essayez. Même cinq minutes peuvent transformer la qualité et la collaboration au sein de votre équipe.