Lorsque l’on est dans une grande entreprise il n’est pas rare de se retrouver avec des équipes spécialisées dans le test. Ces équipes ne sont composées que de testeurs (en incluant les test manager et les tests coordinateurs).
Pour ces équipes, la mise en place de process agiles tels que le Scrum est un vrai challenge qui se doit d’être relevé afin que cette « équipe de test » reste une équipe à part entière. Un grand nombre de ces difficultés est également partagés par les équipes de développeurs et de business analystes.
Les défis du mode Scrum :
- Comment faire pour que le sentiment d’appartenir à l’équipe de test perdure alors que chaque testeur est potentiellement seul et à plein temps dans une équipe Scrum ?
- Comment faire pour partager son savoir et ses expériences ?
- Comment faire pour maintenir l’indépendance des tests (l’indépendance des tests est un principe simple partant du principe que celui qui développe un logiciel n’est pas celui qui test) ?
- Comment faire pour remplacer efficacement un membre qui quitte l’équipe ?
Tous ces problèmes ne se posent pas ou de manières très différente dans un cycle en V ou tous les testeurs sont dans la même salle à travailler ensemble en changeant de projet régulièrement.
Le sentiment d’appartenance à l’équipe :
C’est un problème récurrent que j’ai rencontré dans toutes les équipes de test qui avaient des testeurs dans des équipes de test.
Lorsque l’on est testeur dans une équipe Scrum et que l’on est également dans une équipe de test, on se retrouve à faire partie intégrante de deux équipes. Comment faire, alors que l’on est à 100% dans son équipe Scrum pour continuer de se sentir membre de l’équipe de test ?
La réponse n’est jamais simple, néanmoins il me semble indispensable que le testeur ne soit pas 100% de son temps dans l’équipe Scrum. Je sais que cela est contre « l’esprit Scrum », mais pense sincèrement que cela est un mal pour un bien, notamment car cela permet de palier en partie à d’autres défis posés avec le mode Scrum.
En effet un testeur en mode Scrum et membre d’une équipe de test, pour se sentir appartenir également à l’équipe de test doit travailler avec les autres testeurs, par exemple sur des problèmes transverses (mise en place de nouveaux outils, présentations) ou faire des points réguliers avec les autres testeurs sur leur travail, demander des conseils… Attention je ne parle pas ici de réunions quotidiennes ni même hebdomadaire. Une réunion ou deux par mois peuvent être suffisante.
Sans cela, sans communication ni projets communs à l’équipe alors le sentiment d’appartenance à l’équipe de test se perd très vite et elle devient une équipe que d’un point de vue administratif, ce qui peut être dommageable d’un point de vue de la qualité du travail de l’ensemble des membres de l’équipe de test.
Partager ses expériences et son savoir :
Toute équipe est constituée de différentes individualités. Toutes ses individualités ont leur point forts, point faibles et expériences. Si je fais face à une difficulté dans mon équipe Scrum (ex : difficulté à mettre en place une batterie de tests vitaux à exécuter à chaque livraison de code) il est fort probable qu’un autre membre de l’équipe de test ai déjà dû faire face à cette difficulté. Aller à sa rencontre et savoir comment lui a réussi à résoudre ce problème permet de répondre à ce problème plus rapidement. En test comme en développement on ne nous demande pas de réinventer la roue ! Il faut savoir aller chercher l’information là où elle se trouve. Cela tombe bien une équipe de test est une mine à informations, il serait dommage de s’en priver.
Pour cela encore les réunions préconisées pour garder le sentiment d’appartenance à l’équipe de test sont très utiles (mais dans certains cas pas suffisantes). De plus en aider ou se faire aider par un membre de son équipe renforce les liens de l’équipe.
Maintenir l’indépendance des tests :
Cela peut sembler être une inquiétude mineure mais ce sujet est selon moi très important car l’indépendance des tests peut dans certains cas, éviter bien des soucis. C’est à dire pour un projet informatique, des bugs qui auraient été évitables !
Ici on touche à un point qui peut potentiellement être problématique en Scrum. Le fait de regrouper toutes les compétences dans une seule équipe réduite a de nombreux avantages (le principal étant une meilleure communication et une compréhension du métier des autres membres) mais a aussi des inconvénients, notamment l’effet de groupe.
Le testeur en équipe Scrum n’est pas responsable de la qualité du produit, c’est l’équipe. Néanmoins il est garant des bonnes pratiques et doit insuffler la philosophie du test et de la qualité. Malheureusement il peut arriver que dans le feu de l’action certaines de ces bonnes pratiques ne soient pas bien suivies.
Il se peut également que le testeur ait aidé à développer une fonctionnalité et se retrouve à la tester. Dans ce dernier cas la « qualité » des tests ne sera peut-être pas au rendez-vous car on trouve plus difficilement des erreurs dans son travail que dans celui des autres (il suffit de prendre les fautes d’orthographes, j’en vois régulièrement dans des articles de journaux ou sur Linkedin mais en laisse des énormes dans les miens… Et ce malgré plusieurs relectures !).
Là encore pouvoir être accompagné par d’autres membres de l’équipe de test est un plus et les réunions permettant de garder un sentiment d’appartenance à l’équipe de test s’avèrent une fois encore un outil intéressant.
Remplacer efficacement un membre qui quitte l’équipe :
Lorsque l’on est testeur dans une équipe Scrum et appartenant également une équipe de test et que l’on décide de partir (changer de mission, poste ou simplement partir en vacances), l’équipe Scrum est généralement dans l’attente que l’on soit efficacement remplacé, par un autre testeur et que ce remplacement ne se fasse par trop ressentir sur la Vélocité (l’efficacité et la rapidité) de l’équipe Scrum.
Pour cela il faut que notre travail soit facilement récupérable et compréhensible par un autre membre de l’équipe. Encore une fois des réunions régulières permettent de faire une partie du travail mais pas seulement. Il faut selon moi, et encore une fois au détriment de « l’esprit Scrum », avoir une base de travail et des process communs entre les membres de l’équipe de test. Ces process communs permettent potentiellement à n’importe quel autre testeur de l’équipe de reprendre notre travail sans avoir à apprendre, en plus du fonctionnel, à apprendre la méthode de travail dans l’équipe Scrum. Il faut cependant faire très attention avec ces process. Ils ne doivent pas être trop restrictifs car doivent pouvoir être appliqués dans un grand nombre d’équipes Scrum mais surtout ils ne doivent pas être vécus par les membres des équipes Scrum comme un fardeau supplémentaire imposé par l’équipe des testeurs !
Encore une fois l’art du compromis est au cœur du métier de testeur.
Conclusion :
Les défis à relever avec la méthode Scrum pour une équipe de test sont nombreux (je n’ai cité que les principaux auxquels j’ai été confrontés). Néanmoins s’ils sont correctement relevés le fait d’appartenir à une équipe de testeur en plus de son équipe Scrum est une force. Une force qu’il serait dommage de ne pas utiliser surtout qu’encore une fois pour y avoir accès une bonne communication (avec les équipes Scrum et au sein de l’équipe de test) est la clé.
