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 :
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.
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é.
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 ?😊