Livre CFTL – Organisation d’une équipe de test

Cet article a été écrit et est paru dans le livre du CFTL « Les tests en agile« . La qualité de la mise en plage est par conséquent nettement meilleur sur le livre. Néanmoins, le contenu reste le même

Introduction

Qui dit Agilité dit équipes agiles… Et donc équipe pluridisciplinaire. Le concept d’équipe de test n’a donc pas, au premier abord, sa place dans les projets agiles. 

Cela reste évidemment de la théorie pure et il est toujours bon, dans une entreprise ayant plusieurs testeurs, de pouvoir avoir une communauté, une équipe dédiée au test. De plus, un grand nombre d’entreprises éditrices de logiciels fonctionnait (et fonctionne toujours) sur des cycles de développement plus classiques, comme le cycle en V. De même, il n’est pas rare que, dans une même entreprise, il y ait des projets agiles et des projets en cycle en V. 

Le rôle d’une équipe de test 

Les équipes, tout comme les testeurs, doivent donc s’adapter à ces changements afin de continuer à être efficaces et apporter de la valeur à l’entreprise. 

Afin de savoir comment une équipe de test « agile » ou une équipe de test avec des projets agiles et des projets en cycle en V s’organise, il faut d’abord revenir au rôle d’une équipe de test. Ses rôles sont multiples : 

• Synchroniser les activités de test 
• Gérer les plannings de test des projets 
• Mettre en place des processus de test 
• Mettre en place des outils communs de test 
• Permettre aux membres de l’équipe de partager leurs expériences et leur savoir 

En détaillant ces rôles, on s’aperçoit qu’il y a des contradictions avec l’Agilité « pure ». En effet, voici des remarques que l’on peut se faire sur chacun des points précédents : 

• Synchroniser les activités de test 

En Agilité, les activités de tests sont déjà synchronisées dans chaque équipe agile. Il n’y a pas besoin d’avoir plus de synchronisation, chaque produit agile étant indépendant. 

De même, dans le cas où les équipes agiles ont des dépendances entre elles (avec du SaFe ou du Scrum of Scrum), ces dépendances doivent être gérées grâce à la priorisation du backlog, des fonctionnalités à développer. 

• Gérer les plannings de test des projets 

En Agilité, le concept de planning est très vague car les itérations sont courtes et il est impossible sur plusieurs mois de savoir exactement ce qui devra être développé. En effet, le développement étant axé sur le produit ainsi que sur le retour des (futurs) utilisateurs et/ou des clients, le périmètre évolue constamment. Il est bon de noter que le seul périmètre stable est ce qui est en cours de développement. En Scrum, ce périmètre stable est en fait le contenu du sprint en cours. 

• Mettre en place des processus de test 

Sur le papier, cela ne devrait pas être centralisé, chaque équipe agile devant adopter un processus qui correspond le mieux à ses besoins. 

• Mettre en place des outils communs de test 

Comme pour les processus, l’équipe agile est censée savoir ce qui lui correspond le mieux et donc quels sont les outils qui lui seront le plus utiles. 

• Permettre aux membres de l’équipe de partager leurs expériences et leur savoir 

L’ensemble de l’équipe est responsable de la qualité de l’application, ce sont donc les membres de l’équipe agile qui échangent et partagent leurs expériences. Le (ou les) testeur(s) de l’équipe sont évidemment le(s) membre(s) de l’équipe qui connaissent le mieux le sujet. 

• Travailler sur des projets communs ayant pour but d’améliorer les processus et les outils de test 

Un testeur dans une équipe agile est un membre de l’équipe agile à part entière. Il doit donc y consacrer 100% de son temps. 

L’équipe de test, qui s’avère devenir une équipe transverse, doit savoir s’adapter aux remarques ci-dessus mais aussi répondre à certaines interrogations. 

• Synchroniser les activités de test 

L’équipe de test perd en effet une grande partie de son utilité sur ce point. 

• Gérer les plannings de test des projets 

Comme pour la synchronisation des activités de tests, l’équipe de test n’agit que peu, voire pas du tout, sur les plannings de test de projets. L’équipe de test peut néanmoins, de manière ponctuelle, proposer un élément de son équipe afin d’aider une équipe agile si besoin. 

• Mettre en place des processus de test 

L’équipe de test peut proposer des processus communs aux équipes ainsi que des lignes directrices à suivre dans les équipes agiles. Cela réduit en effet la liberté des équipes agiles. Cela permet néanmoins d’assurer que la stratégie de test est bien suivie et permet également une facilitation des montées en compétence de n’importe quel testeur de l’équipe de test intégrant une équipe agile. 

• Mettre en place des outils communs de test 

Tout comme les processus de test, proposer des outils communs permet à l’équipe de test de proposer aux équipes agiles des outils fonctionnels, maîtrisés par les testeurs et donc avec du support. Cela permet aussi de centraliser des données et donc de partager/communiquer plus facilement. 

Une équipe agile pourra néanmoins utiliser d’autres outils supplémentaires, tout comme l’équipe de test peut proposer plusieurs outils différents pour une même activité (ex : UFT et Sélénium pour de l’automatisation des tests d’interface graphique). 

• Permettre aux membres de l’équipe de partager leurs expériences et leur savoir 

En termes de savoir, les équipes agiles ne peuvent pas remplacer toute une équipe de test. Les testeurs font régulièrement face à des difficultés et avoir une équipe de test avec des testeurs expérimentés permet de répondre à ces problèmes du quotidien de manière plus rapide et plus efficace. 

• Travailler sur des projets communs ayant pour but d’améliorer les processus et les outils de test 

L’amélioration des processus, le retour d’expérience sur les bonnes pratiques sont essentielles. Si une équipe agile améliore un outil, cela ne sert à rien qu’une autre équipe aux besoins identiques recrée un outil. 

Les testeurs peuvent remonter les besoins, les difficultés et travailler ensemble afin d’améliorer tous ces processus communs. Ces projets bénéficieront à l’ensemble des équipes agiles. 

Conclusion : 

Une équipe de test avec des testeurs dispersés dans des équipes agiles voit ses responsabilités diminuées. Néanmoins, il reste certains points importants qu’elle peut encore améliorer. Ces points sont la mise en place d’outils et de processus communs, les échanges et l’entraide entre testeurs ainsi que l’optimisation, la mise en place et l’amélioration des outils et processus existant. 

Sur l’ensemble de ces points transverses, l’équipe de test peut être d’un grand secours. Mais pour cela, elle doit faire face au défi de la dispersion et également faire quelques entorses aux règles théoriques de l’Agilité. 

Avoir une équipe de test transverse 

Il existe de nombreuses organisations avec des projets agiles et une équipe de test. Certaines méthodes ou organisations agiles ont d’ailleurs bien compris la plus-value d’une équipe transverse de test (ou de toute autre équipe). On peut entendre par exemple parler de « tribus » dans des entreprises agiles, ces « tribus » ont le même rôle qu’une équipe de test transverse. 

Nous avons vu les rôles que l’équipe transverse peut avoir dans des organisations agiles ou ayant une partie de ses produits développée de manière agile. 

Ces rôles sont principalement: 

• Mettre en place des processus de test communs afin de s’assurer que tout testeur changeant d’équipe agile (ou venant apporter son aide) puisse être efficace le plus rapidement possible. Ou encore s’assurer que la stratégie de test (au niveau entreprise) est bien suivie. 
• Mettre en place des outils de test communs et garantir une expertise de l’équipe sur ces produits. 
• Permettre aux membres de cette équipe d’échanger et de partager leurs expériences. Afin d’optimiser les résultats de l’ensemble des équipes, le savoir doit être partagé. 
• Travailler sur des projets communs ayant pour but d’améliorer les processus et les outils de test.  

On peut également ajouter qu’avoir une équipe de test transverse peut permettre d’assurer une meilleure indépendance des tests. En proposant, par exemple, des sessions de tests exploratoires (après l’exécution des tests de régression et de validation) à des membres de l’équipe de test qui ne font pas partie de l’équipe agile. 

Enfin, l’équipe de test transverse, comme nous l’avons précisé dans les 2 premiers points énoncés, peut permettre une meilleure gestion du turnover. Le testeur arrivant dans l’équipe agile ne devant « que » monter en compétence sur sa connaissance du produit et non sur le produit, les processus et les outils. 

Afin qu’une équipe comme celle-ci voie le jour et qu’elle soit efficace, il faut mettre en place une organisation spécifique pour permettre à ces testeurs de sentir qu’ils appartiennent tout autant à l’équipe agile qu’à l’équipe de test. Les testeurs font ainsi partie de 2 équipes !

Pour cela, l’équipe de test va devoir faire face à différents défis : 

• Le premier défi est justement d’arriver à avoir une équipe de testeurs considérée par les membres de l’équipe agile comme appartenant à leur équipe. 

Pour arriver à relever ce défi, il faut d’abord sortir du mode agile théorique et permettre aux testeurs de consacrer une partie de leur temps à l’équipe de test, ce qui revient à dire qu’ils ne seront plus à 100% dans leur équipe agile. Cela peut paraître un handicap pour l’équipe agile mais, à moyen terme, le retour sur investissement est évident avec la proposition de processus, du support sur des outils et surtout des solutions pragmatiques à des problèmes rencontrés par l’équipe agile. 

Consacrer du temps à l’équipe de test n’est pas suffisant. Pour développer un sentiment d’appartenance, il faut également que les testeurs travaillent ensemble, aient un ou des buts communs. Pour cela, rien de tel que des projets transverses (comme le travail sur l’amélioration des processus et des outils) mais aussi une disponibilité de l’ensemble des membres de l’équipe. Que chaque membre soit prêt à aider son équipier, à lui apporter ses conseils et à partager son expérience. 

• Un autre défi est d’optimiser le partage des connaissances 

Dans toute équipe, et encore plus dans les équipes dispersées, le problème du partage des connaissances est un point clé. 

Avoir des connaissances est un bon point, mais si ces connaissances ne sont détenues que par une personne, lors de son absence (départ, vacances, maladie…) ces connaissances sont indisponibles voire perdues. L’équipe de test transverse doit particulièrement faire attention à cela en proposant un espace de partage avec de la documentation à jour, une matrice de connaissance permettant de détecter les points à risque et donc une formation des membres de l’équipe sur ces points. L’équipe de test transverse peut également proposer des ateliers et des conférences afin de présenter des outils, des méthodes, des processus mis en place dans leurs équipes agiles. 

• Il est également important de ne pas être considéré par les équipes agiles comme une nuisance ! 

Ce point est très important. L’équipe de test, si elle est acceptée par les testeurs, ne l’est pas forcément par les équipes agiles. Il faut faire attention à ne pas être trop chronophage. Afin de limiter ces problèmes, il est possible de jouer sur 3 leviers. 

Le premier est d’avoir un temps dédié à l’équipe de test limité (entre 10 et 20%) mais aussi de permettre au testeur de l’équipe agile de pouvoir être absent à certains moments car l’équipe agile a impérativement besoin du testeur à ce moment-là. 

Le deuxième est de communiquer sur ce que fait l’équipe de test et ce que cela apporte aux équipes agiles. 

Enfin, le troisième levier est d’aller plus loin que la communication et de permettre à chaque équipe agile de « disposer » de plusieurs testeurs d’autres équipes, afin d’organiser des campagnes de tests exploratoires ou simplement de les aider sur de l’exécution de test, pour pouvoir livrer au moment souhaité. 

Conclusion : 

Une équipe de test transverse doit être une équipe ! Les membres de cette équipe doivent pouvoir compter les uns sur les autres. Malheureusement, si cela est nécessaire, ce n’est pas suffisant car cette équipe doit « prouver » son intérêt. Pour cela, elle doit adopter une bonne communication afin de faire la démonstration de ses résultats, mais aussi savoir s’adapter à différents contextes en permettant aux équipes agiles de s’appuyer sur toutes les compétences et les connaissances de l’équipe de test. 

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

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.