12 – Rally Test Game, validation opérationnelle applicative

Le Rally Test Game se présente comme une activité de qualification épisodique, mais le plus souvent unique et finale. L’avantage recherché se matérialise par la détection au plus tôt de tout dysfonctionnement du produit.

L’objectif de cette communication, plus courte que les précédentes, se limite à une technique de validation de l’application à livrer. L’organisation de la technique décrite s’est vue "gamifiée" récemment sous l’appellation de RTG (Rally Test Game), ou encore de "Game of Bugs". Il n’en demeure pas moins que son principe demeure le plus souvent indispensable à la qualité du produit et à la performance de sa réalisation.

Note : ce douzième et dernier cartouche de connaissances composant la proposition "Continuous Sprint 0 et au-delà" se situe dans sa partie "au-delà" et traite de la vérification "finale" du produit. Il se situe avant une livraison, éventuellement en site pilote, et précède la mise en production (MEP). Une synthèse finale de la mise en œuvre de cette boîte à outils méthodologiques sera proposée dans une prochaine publication début 2020.

Le Rally Test Game (RTG)

Un développement réellement Agile implique une "spécification détaillée – codage – test – validation" dite permanente. Les bénéfices attendus de ce type de mise en œuvre nécessitent en revanche la collaboration régulière ou "à la demande" du métier. Dans ce monde agile idéal où la programmation se base sur le comportement attendu de la fonctionnalité (Behavior Driven Development, BDD), une vérification additionnelle comme le RTG n’aurait théoriquement pas lieu d’être puisque toutes les fonctionnalités seraient préalablement testées avant leur acceptation par le métier "DONE". Dans la réalité, surtout lorsque les utilisateurs significatifs et finaux ne participent pas systématiquement au développement, les démos de fin de Sprint s’avèrent insuffisantes et le RTG devient alors l’assurance indispensable d’une qualité fonctionnelle, ergonomique, technique et plus largement de la qualification du comportement applicatif. Lors de cette activité, la présence des développeurs s’avère primordiale. Même si le contexte ne permet pas la correction immédiate des bugs et anomalies détectées, le RTG permet à ceux-ci d’avoir un ressenti de l’usage concret de leur production par des utilisateurs réels. Parfois cette vision créée de l’étonnement, même pour les représentants significatifs du métier dont les activités se trouvent souvent très éloignées de la manipulation des écrans.

Note : Le principe de la validation finale des chemins fonctionnels existe depuis des décennies. C’est par contre récemment que Jean-Pierre Bonafous l’a popularisé dans le monde Agile en le "gamifiant" sous l’appellation de RTG (Rally Test Game). A sa présentation lors d’un SCrumDay le Feeback fut le suivant : "RTG est un moyen immédiat de répondre à la problématique projet des cas de tests non couverts par les longues semaines de qualification et de recette. Le RTG permet de paralléliser les tests (anciennement nommés de qualification et de recette) avec les sprints réalisés. L’objectif étant de remonter très vite tout dysfonctionnement pour anticiper sa correction. Avec une population la plus représentative possible des utilisateurs, l’ensemble des cas de tests sont plus susceptibles d’être couverts". Selon Aurélien Morvant (Game of Bugs) : "pendant cette courte période de temps, les équipes sont focalisées sur un seul sujet : les bugs".

Mise en pratique

Lors d’un RTG, en termes de participation, le niveau de représentativité s’organise en regard de la structure impliquée et sont recherchés les profils utilisateurs les plus larges. Un autre aspect consistera en l’organisation d’une couverture fonctionnelle optimale englobant l’ensemble des cas de figures-métiers se présentant dans l’activité (y compris ceux n’ayant pas été décrits lors de la rédaction des Users Stories). Concernant métiers et utilisateurs, un RTG réussi nécessite, outre leur motivation affirmée, une large expérience associant aussi bien la connaissance des processus à mettre en œuvre que de l’usage concret du produit développé. En pratique, il faut mobiliser le maximum de "parties prenantes" de l’applicatif à tester, puis les répartir en petites équipes (ou binômes), comme par exemple un métier par équipe associé à des développeurs ne travaillant généralement pas ensemble sur la partie du produit qu’ils testeront (notion d’œil neuf). Un RTG s’organise structurellement comme un projet (sa durée se limite généralement d’une à trois journées dépendant de la taille de l’application). L’atelier peut s’orienter vers des formes particulières de vérifications "utilisateurs" :

par cheminement de process formalisés,
par thèmes fonctionnels,
sur la base de l’expérience pratique des utilisateurs finaux,
de manières aléatoires ou improvisées impliquant des néophytes ou d’autres parties prenantes.

Un mixte de ces techniques est fortement recommandé car il offre une meilleure couverture des cas d’utilisation qu’ils soient standards ou extrêmes. Des données réelles seront utilisées. Dans tous les cas, l’exécution du processus de test se découpe en thèmes et surtout en sprints (dans la durée). Les bugs techniques et anomalies fonctionnelles font l’objet de la rédaction d’un post-it dont la position où la couleur dépendra de la gravité du sujet (classifié généralement en : critique, majeur, mineur). Ce reporting mural s’organise visuellement sous la forme d’un tableau de post-it d’anomalies où lignes et colonnes représentent thèmes testés et sprints de découverte (exemple figure suivante).

Une restitution générale, sous la forme d’un stand-up permettant l’explication détaillée des découvertes, s’organise à la fin de chaque Sprint devant le radiateur d’information. Une rapide rétrospective de fin de sprint basée sur l’expérience immédiate permettra d’améliorer ou d’optimiser les activités du sprint suivant.

L’objectif d’un RTG est de sortir les développeurs comme les métiers des tests classiques en invitant les participants à faire du test exploratoire. Si l’environnement technique le permet, les développeurs corrigeront immédiatement tout ce qu’il sera possible de traiter en direct. Cela requiert évidemment une organisation de test parfois complexe (cas des processus impliquant des communications), ou lourd à restaurer entre chaque sprint (cas de bases de données altérées). Si possible, les corrections s’accompagneront de tests de non régression automatisés.

Logistique d’animation

Prévoir le café, des viennoiseries le matin. Tenter d’obtenir un budget pour des plateaux repas, car cela permet de gagner beaucoup de temps et s’avère hautement rentable par rapport aux fréquents retards liés à une dispersion aléatoire des ressources durant le déjeuner. Il est aussi recommandé une "gamification" assez forte de l’événement. Des animations avec bruitage pour signaler une anomalie détectée ou un correctif validé représentent une bonne émulation, dédramatisent la situation et détendent l’atmosphère. A certains niveaux d’avancement, ou simplement pour le plaisir, il sera éventuellement offert des petites récompenses genre gadgets ou simplement des friandises (… les Chamallows au chocolat…).

Compléments utiles

Dans le cas du RTG final, on ne s’arrête que lorsque toutes les anomalies critiques et majeures sembleront traitées. Généralement la suite consistera en une mise en production, de préférence en site pilote. La solution sera alors à nouveau testée en condition réelle. Cette phase contribue généralement à rassurer et à motiver l'ensemble des utilisateurs, et permet par ailleurs d'ajuster le dispositif avant la phase de déploiement généralisé. La notion de site pilote et les détails organisationnels suivants sont régulièrement oubliés des méthodes de développement (actuelles ou du passé). En voici deux aspects généraux mais non détaillés ici :

Au niveau des Ressources Humaines : vérification de la pertinence des formations réalisées en préalable au déploiement et du niveau d’accompagnement mis en œuvre.
Au niveau des Processus : validation opérationnelle de la nouvelle organisation ainsi que de la couverture des réponses offertes par l’outil déployé.

Note : ne pas confondre la validation applicative finale des chemins fonctionnels couverts par le produit, avec la Qualification initiale des nouveaux Processus Métier (QPM).

Conclusion

Au final, à part quelques détails, rien de totalement nouveau pour ceux qui connaissaient déjà le principe. Mais encore fallait-il l’appréhender dans sa forme gamifiée. Voila bien le moyen de conclure en beauté une nouvelle production applicative porteuse de valeur pour l’Organisation.