Introduction
Depuis plusieurs années je travaille constamment dans de grandes organisations qui sont en Agile à l’échelle (ou en transformation à l’agile à l’échelle).
Le sujet de la gestion des tests et plus particulièrement de la stratégie de test est une question qui revient régulièrement.
Parmi les sujets il y a évidemment la place des testeurs et celle des test managers.
Les testeurs et test manager dans un cycle « traditionnel »
Dans les cycles de développements traditionnels (généralement cycle en V) il y a une équipe composée de testeurs avec à sa tête un test manager.
Les testeurs travaillent par projet et testent des services numériques au fur et à mesure de leurs livraisons. Le test manager a alors un rôle de « chef d’orchestre ». Il s’assure d’avoir une activité aussi « lisse » que possible et assigne les testeurs sur différentes tâches.
Dans ce contexte, la stratégie de test donne :
- les personnes (en fonction des rôles) en charge de gérer les différents types de tests
- les approches et techniques communes aux différents projets
- les indicateurs communs entre les projets…
Dans une organisation en agile à l’échelle les testeurs ne sont plus regroupés dans une même équipe qui partage ses connaissances et avec un test manager pour organiser les activités.
Les testeurs se retrouvent éparpillés dans les équipes agiles (qui n’ont pas forcément toutes un testeur). De son côté le test manager n’a en général (quasiment) plus de testeurs directement à ses côtés…
Ces changements radicaux engendrent de nombreuses interrogations et des challenges importants.
Les problèmes de la « vraie vie » du test manager ?
Les interrogations soulevées par l’organisation en agile à l’échelle sont :
- Quelles activités pour le test manager s’il n’y a plus de gestion d’équipe à proprement parler ?
- Comment apporter une démarche qualité qui assure un niveau minimum sur l’ensemble des équipes ?
- Qui fait les tests ? Qui automatise ?
- Comment gérer les dépendances inter-équipes ?
- Quels sont les référents des testeurs ?
- Comment gérer les pics et les baisses de charge ?
Comme vous vous en doutez il n’y a pas une réponse unique à chaque question… Et comme vous vous en doutez, je n’ai pas non plus de réponse immédiate à donner à ces équipes.
Néanmoins, avoir la réponse à ces questions est essentiel si l’on veut s’assurer d’avoir un bon processus qualité.
Je vais donc vous proposer dans cet article quelques réponses usuelles à ces problèmes dans des organisations d’agile à l’échelle.
1 – Quelles activités pour le test manager s’il n’y a plus de gestion d’équipe à proprement parler ?
On a souvent tendance à restreindre le rôle de « test manager » à un rôle « manager de testeur ».
Il est vrai que de ce point de vue, la charge du test manager va être fortement réduite (même s’il peut reste des équipes transverses pour les tests de bout en bout) dans le sens où il n’est plus en charge de gérer l’activité des testeurs dans les équipes agiles.
Dans le cas où il reste responsable hiérarchique des testeurs il y a du suivi de carrière et d’autres échanges mais cela reste nettement inférieur à celle d’un cycle en V.
La charge des activités du test manager s’en trouve fortement modifiée. Le test manager continue néanmoins à être fortement sollicité. En agile à l’échelle on va souvent attendre d’un test manager (cela dépend aussi de la taille de l’organisation) :
- d’assurer un lien entre les équipes et de proposer une vision d’ensemble de gestion de la qualité
- de faire un suivi qualité de ce qui est livré par les équipes et du produit dans son ensemble
- de contribuer fortement (voir animer) à une communauté test / qualité afin de permettre entraide et capitalisation des connaissances
- d’être référent méthodologique pour les équipes dont il a la responsabilité
- d’accompagner les testeurs qui font face à des difficultés
- d’accompagner les équipes sans testeurs pour délivrer une qualité suffisante
- d’assurer l’accès aux outils et environnements
- de concevoir les plan de test maitre (souvent appelés stratégie de test produit)…
2 – Comment apporter une démarche qualité qui assure un niveau minimum sur l’ensemble des équipes ?
L’agile fait le pari de la confiance et de la décentralisation.
Les effets sont bénéfiques lorsque cela est bien fait. Néanmoins, cette décentralisation peut créer une forte disparité au niveau de la qualité.
Si cela ne pose pas de problème pour des équipes agiles indépendantes qui maitrisent totalement leur produit, ce n’est pas le cas pour des équipes dépendantes les unes des autres en agile à l’échelle.
Dans le cas de l’agile à l’échelle il est nécessaire que les équipes partagent un socle commun de pratiques, indicateurs et critères qualité. De même, il est aussi préférable d’avoir autant que possible des outils communs.
Un des moyens les plus efficaces pour répondre à ces challenges est d’avoir une stratégie de test (ou stratégie de test produit) partagée et appliquée.
Au delà d’un document et de pratiques communes, il est également important de s’assurer que chaque équipe a l’ensemble des compétences nécessaires pour assurer l’atteinte du niveau de qualité attendu. Dans le cas contraire il faut renforcer les équipes avec ces compétences. Cela peut être par le renfort d’un testeur mais aussi par de la formation.
3 – Qui fait les tests ? Qui automatise ?
Je n’ai qu’une seule réponse: ça dépend!
Dans une équipe agile avec un ou plusieurs testeurs, c’est généralement le(s) testeur(s) qui « fait » les tests.
Mais les équipes n’ont pas forcément toute un testeur (ou le testeur peut être en congés)! Dans ce cas cela doit être une autre personne de l’équipe qui s’en charge. Rappelez vous, l’important n’est pas le rôle mais bien la présence de compétences dans une équipe agile.
De même, un testeur peut avoir de la surcharge (notamment sur les fin d’itération). Dans ce cas il est nécessaire d’avoir des renforts pour exécuter les tests.
De « manière générale », si l’équipe a un testeur, alors ce dernier s’occupe de la conception des tests. La partie exécution est moins dépendante et peut être assurée par toute personne de l’équipe.
Je n’ai parlé « que » des tests « intra-équipe ». La question peut aussi se poser pour les tests « inter-équipes ». Dans ce cas, cela va dépendre de comment l’organisation souhaite gérer ses tests bout en bout.
Enfin, je pense qu’il est important de préciser que si un testeur se retrouve en « sous-charge » au niveau des activités de test, qu’il est important qu’il se saisisse d’autres tâches. Ce qui est attendu des non testeurs (faire du test quand nécessaire) est aussi attendu du testeur (faire autre chose que du test quand cela est nécessaire).
4 – Comment gérer les dépendances inter-équipes ?
La gestion des dépendances se fait principalement avec les tests de bout en bout.
Néanmoins, attendre les tests de bout en bout pour gérer les dépendances est un pari risqué. L’idéal est de détecter ces dépendances aussi tôt que possible (c’est d’ailleurs un des objectifs du PI planning en SAFe).
Cette détection peut se faire de différentes manières. Je pense notamment à :
- des réunions entre testeurs
- une démarche d’ATDD avec une vision des parcours macro impliquant plusieurs équipes agiles.
Au delà de la détection il y a aussi la gestion de ces dépendances. Là encore, la communication (dont la forme peut varier) est un élément clé dans la gestion des dépendances. Cela peut se faire entre PO et/ou testeurs.
Enfin, les dépendances peuvent aussi se « tester » avec la mise en place d’environnements pour faire des tests d’intégration « 2 à 2 » en amont des tests de bout en bout.
5 – Quels sont les référents des testeurs ?
Le test manager est souvent le premier référent des testeurs dans les équipes agiles.
Néanmoins, le test manager est souvent un référent méthodologique ou sur la stratégie. Du point de vue plus opérationnel il peut être amené à rediriger vers un autre testeur dans une autre équipe.
J’ai donc envie de dire « par défaut » le test manager mais de manière générale il est mieux de lister des sujets (comme certains outils, certains produit, certaines fonctionnalités…) et d’identifier un référent sur chacun de ces sujets.
6 – Comment gérer les pics et les baisses de charge ?
J’ai déjà en partie répondu à cette question dans la question 3.
Quand on est testeur dans une équipe agile on est avant tout membre d’une équipe. Dans une équipe on fait, à l’instant t, ce à quoi on est le plus utile à ce moment là.
Les testeur va alors principalement faire du test. Lorsque la charge est trop faible, le testeur va alors prendre d’autres tâches ou proposer son aide à d’autres membres de l’équipe. De même, quand la charge est trop importante il peut attendre de l’aide de ses équipiers.
Si on se penche sur le foot (comme dans cet article), un défenseur va principalement défendre. Néanmoins, on a attendre de lui, dans certains cas, de monter pour attaquer et éventuellement marquer (comme Pavard en 2018 ou encore Laurent Blanc ou Lilian Thuram en 1998) ! De même, les attaquants se doivent de participer à l’effort défensif. Dans une équipe agile c’est pareil. L’ultra spécialisation n’a plus vraiment sa place.
