PanTesting

Qu'est-ce que le PanTesting ?

"PanTesting" est un modèle de test agile à l'échelle. Il est composé avec [Moustier 2020] :

• de la Testabilité : fournir des moyens techniques et sociaux pour permettre les tests [Bach 2015a] [Meaney 2018a] [Meaney 2018b] [MoT 2019], car cela contribue à la transparence de la chasse.
• la théorie des contraintes (TdC) permet le flux au niveau du système [Goldratt 1984] [Goldratt 1990] [Stein 1997] [Cox III 2010].
• la panarchie est un modèle d'interaction entre les sous-systèmes [Gunderson 2002] et conduit à une norme de maturité évolutive vers une organisation sans silos.
• l'apprentissage en double boucle propose des boucles de rétroaction entrelacées [Argyris 1977] [Smith 2001] qui conduisent à un "bon produit" (les "variables directrices" décrites dans la théorie d'Argyris) au lieu d'un "produit conforme" puisqu'il y a une compréhension de ce qui doit être testé.

‍

La combinaison de ces quatre composants peut être utilisée à n'importe quelle échelle de l'organisation grâce à la compréhension de la panarchie et de la ToC, tandis que la testabilité et l'apprentissage en double boucle permettent d'adapter les tests à pratiquement n'importe quelle partie de l'organisation, le cas échéant :

• le domaine des affaires
• l'aspect technique de la solution
• le processus de développement
• la collaboration entre les équipes internes et externes
• la gestion du budget
• l'outillage
• le système de gestion de la qualité
• la gestion des connaissances
• la culture au sein de l'entreprise

La compréhension des deux Panarchies aidera à briser les silos entre les sous-systèmes (le terme utilisé en Panarchie est "écocycles") en exploitant les phases de changement d'écocycle α, r, K et Ω et en intégrant progressivement les taux de changement des écocycles liés dans votre propre écocycle jusqu'à ce qu'ils soient synchronisés.

‍

‍

En ce qui concerne les taux de changement, l'application de la ToC permet d'intégrer les changements en gérant les écarts de synchronisation au moment opportun, que ce soit lorsque ces écarts deviennent un goulot d'étranglement insupportable ou dans une approche juste-à-temps, notamment grâce au cadencement et à la synchronisation [SAFe 2021-7].

Impact du PanTesting sur la maturité des tests

L'introduction du PanTesting devient inévitable puisqu'il permet intrinsèquement de livrer un bon produit construit à partir de plusieurs équipes et de la qualité à l'échelle de chaque sous-système de l'organisation qui pourrait influencer la qualité du produit. 

En fait, une fois qu'une organisation est capable de tester le produit, éventuellement de manière agile, l'entreprise se heurtera sûrement à un plafond de verre qui limitera l'efficacité des tests : le système entier doit être amélioré en appliquant la pensée systémique [SAFe 2021-2].

Pour permettre cette vision systémique, il est fondamental de se concentrer sur l'ensemble de la solution, notamment en adoptant les X-Teams pour insuffler un langage omniprésent et en visant une organisation centrée sur le client. Toutefois, cela nécessite un grand nombre de dépendances (c'est-à-dire des écocycles liés), comme l'organisation autour de la valeur, le déblocage de la motivation intrinsèque des collaborateurs, etc.

La PanTesting fournit à la fois un modèle de maturité vers des écocycles fusionnés et un chemin pour les gestionnaires de diffuser le modèle en tant que jardiniers. Le diagramme ci-dessous montre les connexions gérées existantes entre les écocycles (flèches simples) et les prochaines connexions à commencer à gérer pour améliorer la qualité au sein de l'organisation. Pour les connexions nouvelles et anciennes, le chemin vers la fusion des écocycles présenté ci-dessus peut ensuite être utilisé pour suivre la progression en termes de maturité.

Les Managers peuvent utiliser un backlog priorisé pour l'amélioration des anciennes connexions ou la mise en place de nouvelles connexions, notamment grâce à la méthode de priorisation Weighted Shorter Job First (WSJF) [SAFe 2021-35] et au WIP.

‍

Pour faciliter cette progression, trois rôles sont impliqués [Moustier 2020a] :

• les équipes qui utilisent et anticipent les tiers des changements d'écocycles grâce à l'utilisation de pratiques telles que X-Team ou Yokoten et accélèrent la vitesse des cycles de changement de leurs écocycles quand c'est possible [SAFe 2021-4] avec une forte testabilité de leurs livrables.
• les gestionnaires qui favoriseront l'organisation apprenante en tirant parti de la voie de la fusion des écocycles, des opportunités d'apprentissage en double boucle dans le respect des lois sur les ToC.
• les communautés qui feront office de pôles de connexion et faciliteront ainsi les liaisons et le Yokoten.

Le point de vue d'Agilitest sur PanTesting

L'automatisation des scripts de test est confrontée à de nombreux défis, comme la préparation au développement du produit.

Lorsque le développement de scripts vient après le développement de produits, le cahier des charges s'applique clairement, car il ressemblera inévitablement à un goulot d'étranglement pour la livraison de logiciels. Cela conduit à synchroniser progressivement les écocycles du développement de produits et du développement de scripts. C'est précisément ce qui se passe dans une Task Force US.

Cet exemple simple illustre l'utilisation de deux composants du PanTesting. Quelle que soit votre organisation, l'approche #nocode du script [Forsyth 2021] avec Agilitest raccourcit les temps de script et de débogage ; ainsi, l'effet de goulot d'étranglement est réduit et pourrait sortir du chemin critique de livraison si les deux activités étaient effectuées en parallèle.

La testabilité fait également partie de PanTesting. Celle-ci est en fait vitale pour le scripting. Sans aucune testabilité, le script ne serait pas en mesure de vérifier les exigences. Supposons qu'une fonction soit mise en œuvre et que personne ne soit en mesure de voir un retour d'information sur le succès ou l'échec de l'exécution de la fonction, alors comment un script pourrait-il faire ? Cependant, il y aurait une solution à condition qu'une certaine testabilité intrinsèque ait été ajoutée dans une partie interne du produit (disons une API REST, cachée de l'utilisateur final, mais qui pourrait être atteinte à partir du script). C'est pourquoi Agilitest fournit certaines fonctionnalités de l'API REST pour permettre de telles vérifications.

Enfin, l'apprentissage de la double boucle est également inévitable en matière de scripting. Il serait surtout stupide de scripter un test sans savoir :

• l'objectif du test que le script doit vérifier
• les composants impliqués par le script et sur lesquels le script s'appuie

Le scripteur est naturellement poussé vers ces éléments pour réaliser le script. Cependant, afin de fournir une certaine tolérance aux pannes sur la partie la plus versatile du script (c'est-à-dire les composants graphiques également surnommés "widgets"), Agilitest incorpore quelques heuristiques pour maximiser la probabilité de capturer des widgets à partir de critères fournis lors de la conception du script.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍