Les entreprises adoptant depuis plusieurs années une organisation de plus en plus agile, plusieurs modèles de gestion de la qualité au sein d'une entreprise émergent lorsque celles-ci disposent d'un service QA historique. Nous vous proposons ici d'en aborder deux, le premier orienté sur l'intégration complète des testeurs dans les squads, l'équipe QA devenant une "guilde" au sens communauté de partage de méthodes et bonne pratiques, et un second qui tend à faire perdurer le service QA comme un service transverse à part entière. Les deux modèles présentés ci-dessous ont été expérimentés dans des services QA de taille similaire d'environ 10 personnes dans des directions Retail :
- Dispatcher les testeurs dans les squads / équipes projets agile
Dans ce premier modèle, ce sont finalement les équipes projets qui dimensionnent leurs besoins en terme de staffing auprès du manager QA, celui-ci jouant principalement un rôle transverse d'animateur / support sur la méthodologie et processus. Il aide à fluidifier les échanges, fait monter en compétence sur le métier du test l'équipe QA et peut prendre le rôle de defect manager afin de s'assurer du bon suivi des anomalies de manière transverse. Son rôle de management reste quant à lui plus diffus, l'opérationnel étant géré par les responsables de squad. Enfin, dans le cadre des tests E2E / systèmes, le QA Manager peut prendre un rôle central en coordonnant les différents testeurs de chaque équipe concernée pour l'organisation de ces tests.
- Avantages :
- Le testeur est entièrement intégré à l'équipe projet agile et participe à l'ensemble des cérémonies agiles. Il se sent impliqué directement dans la réussite du projet
- Sur son périmètre, le testeur devient facilement expert fonctionnel
- Les échanges sont fluidifiés au sein d'un projet, une vraie relation de confiance est en place avec l'équipe de dev.
- La QA représente un coût "fixe" pour l'équipe projet
- Inconvénients :
- Le testeur reste éloigné des autres sujets de l'équipe QA
- Le départ ou l'absence du testeur dans une squad représente un risque projet pour celle-ci
- Une ambiguïté existe dans le management hiérarchique du testeur entre le responsable de squad et le QA manager
- Le positionnement du QA Manager est encore difficile à trouver
- Il y a peu de flexibilité pour absorber des pics de charge sur un projet en particulier du fait des ressources dédiées
- Dans les projets ayant une forte intégration de systèmes, les tests E2E restent complexe à organiser et plus coûteux du fait du silotage des équipes
- Il y a plus de difficulté à faire avancer les priorités interne à la QA, chantiers transverses et amélioration continue quand chaque testeur est dédié à un projet
Maintenir une équipe QA transverse
Ce modèle conserve pour sa part son rôle de service transverse de QA. Le management de l'équipe reste géré par le QA manager et les membres de l'équipe QA peuvent travailler sur une multitude de projets différents. La gestion des tâches de l'équipe s'appuie généralement sur un tableau Kanban. Le partage de connaissance et de bonnes pratiques entre chaque membre est grandement facilité, mais l'implication des testeurs dans les projets est moins forte, parfois au détriment de l'expertise fonctionnelle que peut avoir un testeur dédié sur un sujet. Enfin, pour les tests E2E / systèmes, l'équipe QA est rapidement autonome dans la réalisation de ceux-ci et l'effort de coordination reste modéré.
- Avantages :
- Toute l'équipe QA a une vision 360° des sujets en cours
- Le partage des connaissances dans l'équipe QA est facilité
- Il y a un réel esprit d'équipe entre testeurs
- Le respect des méthodes et bonnes pratiques est également facilité
- La rotation des testeurs sur d'autre sujets est possible, leur conférant de la polyvalence, une meilleure connaissance du SI dans son ensemble et une adaptabilité renforcée
- Le QA manager dispose de flexibilité dans la gestion du plan de charge
- L'équipe QA peut être autonome dans la réalisation de tests E2E / systèmes
- Inconvénients :
- Il y a moins de communication entre les équipes projets et l'équipe QA
- L'expertise fonctionnelle sur une application est plus longue à atteindre
- Il existe un risque sur la qualité lorsque les testeurs changent trop souvent de sujets
- Beaucoup de cérémonies agiles peuvent être concentrées sur le QA manager
- La méthode Kanban pour la gestion d'un service QA est parfois difficile à concilier avec la multiplication des projets Scrum et différentes temporalités de sprints
- La gestion budgétaire et la refacturation sur les projets peuvent être complexes et chronophages suivant les organisation
Ces deux modèles présentent tous deux des avantages certains suivant l'organisation que souhaite prendre l'entreprise, et bien entendu chacun des deux a ses travers.
Dans une DSI ayant adopté pour organisation un modèle type Spotify réparti en tribus / squads, nous pouvons que conseiller le premier modèle dans le sens où la force de cette organisation dépend de l'intégration de toutes les disciplines au sein des tribus et squads. Les problématiques que nous pouvons identifier dans ce type de modèle ne sont pas insurmontables et sont très dépendantes de la taille de la direction IT, le plus gros sujet restant le positionnement du QA Manager qui peut varier très fortement suivant la place qui lui est donnée dans l'organisation.
A l'inverse, si l'organisation IT conserve des projets en cycle en V en parallèle et/ou n'a pas souhaité adopter une structuration agile complète orientée produit, le second modèle propose plus d'avantages et de flexibilité pour permettre de gérer la diversité des projets possibles, effectuer des tests E2E, gérer la fluctuation de la charge et éviter l'effet silo sur la connaissance fonctionnelle de chaque testeur. Attention, dans ce type d'organisation et pour les projets qui sont gérés en agile, il reste essentiel que l'équipe QA soit intégrée dans les sprints et cérémonies agiles majeures (sprint planning / grooming / retro) par le biais du QA Manager ou d'un Test Lead en délégation, au risque de devenir un frein à l'avancement de ces projets, voire de rejet par ces équipes.
Et vous, quel modèle avez-vous adopté dans votre organisation ?😊
