L’état de l’art des équipes de tests logiciels
L'Agile a bouleversé les méthodes de développement traditionnelles, et avec elles les structures des équipes et les attentes des différentes parties prenantes.
Ces multiples changements ont de nombreux impacts positifs et négatifs, qui sont autant dus à la philosophie agile qu'à ses particularités opérationnelles liées au cycle en V. Les tests et les testeurs sont donc impactés.
Parmi les impacts positifs, la facilité de tester plus tôt, sa prise en considération ou son intégration au sein des équipes sont des exemples bien concrets. Il ne faut cependant pas négliger les contraintes engendrées !
Contraintes et impacts négatifs de l'Agile sur les testeurs
Les contraintes engendrées viennent principalement de deux points :
- Le testeur est souvent le seul membre de l'équipe et est généralement considéré comme un référent en matière de test et de qualité.
- L'équipe attend beaucoup de compétences et de connaissances de la part du testeur, afin de s'appuyer sur lui de la même manière que sur l'équipe de test en cycle en V.
Ces contraintes mènent les testeurs vers des impacts négatifs liés au passage aux méthodologies agiles. Je pense notamment à :
- Une demande de testeurs expérimentés au sein des équipes
Un testeur agile doit être capable de résoudre de nombreux problèmes tout en diffusant l’esprit qualité dans l’équipe. Afin d’y parvenir, l’équipe attend de lui une forte expérience en test, car il ne doit pas seulement savoir appliquer, mais aussi savoir adapter et faire comprendre !
Il n'est donc pas surprenant que les testeurs "juniors" aient du mal à trouver des missions dans ces équipes.
- Un besoin pour le testeur de maîtriser de très nombreux aspects du métier
Un testeur au sein d'une équipe Agile doit disposer d'un large éventail de compétences. Il est un "touche-à-tout", et devrait idéalement maîtriser de nombreux sujets, tels que : l'automatisation, le BDD, les tests d'API, la conception des tests, la virtualisation des environnements, la gestion des chaînes d'intégration continue... Ce n'est pas une coïncidence si tous ces sujets sont inclus dans la certification de testeur technique Agile.
- Un potentiel sentiment d’isolement du testeur
Ce point est très important. Un testeur logiciel dans une équipe Agile est souvent seul. Il est alors potentiellement complexe pour lui d’échanger avec ses pairs, de profiter de l’expérience de ces derniers pour résoudre des problèmes, de ne pas avoir à réinventer la roue. Ce sentiment d’isolement est d’ailleurs un élément qui peut encourager le turn-over.
Ces problématiques sont, en général, beaucoup plus faibles en cycle en V avec des équipes de testeurs. Les compétences d’automatisation, de conception, de planification… y sont partagées entre plusieurs personnes. Les juniors apprennent des testeurs expérimentés et les échanges entre pairs sont simplifiés.
Cela veut-il dire que passer en Agile revient à renoncer à ces points forts du cycle en V ? Heureusement non ! Il est évidemment possible de mettre en place l’équivalent d’une équipe de test dans des environnements agiles.
Les équipes de test logiciel en Agile
1. Les apports d’une équipe de test en Agile
La notion d’équipes de test résonne fortement avec le concept de cycle en V. Néanmoins elles ont montré leurs capacités et leur intérêt. Leur absence démontre également, dans de nombreux contextes agiles, qu’il y a un réel besoin d’équipe, de sentiment d’appartenance et de pouvoir échanger avec ses pairs.
La véritable question n’est donc pas de se demander s’il faut mettre en place des équipes de test en Agile mais surtout comment le faire dans des environnements et/ou entreprises avec un certain nombre de testeurs.
Ne vous inquiétez pas, il existe de nombreuses formes possibles et il est évidemment nécessaire de déterminer celle qui s’adapte le mieux à son contexte. La première étape est, comme pour toute mise en place, d'identifier ses objectifs.
Parmi ces objectifs communs, il est pertinent de citer :
- L’homogénéisation des pratiques (surtout en agile à l’échelle)
- La limitation du turn-over
- Permettre une veille et montée en compétence des testeurs
- Capitaliser la connaissance et les outils
- Limiter le travail superflu ou le temps perdu sur des problèmes déjà résolus dans d’autres équipes
- Optimiser les efforts de test
- En Agile à l’échelle : améliorer la connaissance du produit global par l’ensemble des testeurs
Il est également bon de savoir quel est le degré de "directivité" que vous souhaitez offrir.
2. La mise en place d’une équipe de test logiciel en Agile
Comme pour toute mise en place que cela soit de processus, d’outils ou de méthodologie, la création d’une équipe de test en agile ne se fait pas sans préparation ni sans une adaptation au contexte. Parmi les éléments essentiels de cette préparation, il y a le critère du “pouvoir” de cette équipe aussi appelé “degré de directivité”.
Le degré d'objectivité le plus bas peut se traduire par la création d'une (ou de plusieurs) "communauté(s) de pratique" de testeurs. Ces communautés de pratiques sont alors des espaces d’échanges de testeurs pour échanger et partager facilement leurs connaissances.
La limite de cette approche est qu’elle repose essentiellement sur des bonnes volontés et du « best effort ». Elle est donc fragile et souvent limitée en termes de capitalisation et/ou d’homogénéisation des pratiques.
Elle a cependant plusieurs avantages, de part sa grande flexibilité et un faible investissement nécessaire.
Le plus haut degré de directivité peut quant à lui se traduire par la création d'un "centre de test". L’ensemble des testeurs appartient alors au centre de test qui les affecte à des équipes agiles. Ce centre de test centralise alors la connaissance, les pratiques et les outils.
Une des limites de cette approche est la limitation des libertés au sein des équipes agiles. Des problématiques de temps de présence des testeurs dans leurs équipes agiles peuvent également apparaître. Un autre élément limitant est la structure de ce centre qui peut nécessiter plusieurs personnes pour le gérer.
Néanmoins cette approche offre de nombreux avantages comme un partage réel de connaissance ainsi qu’une capitalisation importante de ce qui est fait dans les différentes équipes. La possibilité de former les nouveaux arrivants avant leur affectation dans des équipes agiles est un autre atout à citer.
Il est évidemment possible d’avoir un degré de directivité plus mesuré, en proposant une solution prenant le meilleur des deux approches ou tout simplement en se créant sa propre solution. J’ai personnellement souvent vécu cet entre-deux en faisant partie de deux équipes. Une équipe Agile mais aussi une équipe de test. Un pourcentage maximum de mon temps était alors dédié à l’équipe de test. Ce temps servait pour faire des réunions de testeurs, des retours d’expérience ou travailler sur des processus ou des outils partagés. Cette disposition fonctionnait particulièrement bien dans mon contexte d’Agile à l’échelle.
Conclusion
L’agile a transformé l’industrie du logiciel. Comme toute transformation, il y a des points positifs et des points négatifs. Parmi les points négatifs liés au métier de testeurs, il y a la dispersion de ces derniers, engendrant l’accumulation de connaissances sans pour autant pouvoir facilement échanger avec ses pairs. Afin de répondre à la problématique de compétences, il est possible de proposer des outils qui facilitent certaines activités comme Agilitest pour l’automatisation. Malheureusement les outils ne peuvent répondre à toutes les problématiques, je pense notamment à celles liées à l’isolement et la limitation des échanges avec les pairs. Afin d’y répondre, la mise en place de nouvelles formes d’équipes de test dans un environnement Agile est très souvent une solution efficace et pérenne… À condition que cette dernière soit mise en place d’une manière qui corresponde au contexte de l’entreprise. Pour cela il est alors essentiel d’appliquer un savant dosage entre la directivité de l’équipe de test (qui peut porter différents noms) et la liberté essentielle à laisser aux équipes agiles.
.png)
