Dans le monde agile, le principe adjacent majeur de chaque équipe est de bien satisfaire le client final tout en assurant la livraison d'un produit de qualité et sans anomalies et bugs, hors parfois on se trouve dans des situations critiques quand l'utilisateur final détecte une ou plusieurs anomalies en production, même si on a validé à l'avance l'ensemble des fonctionnalités concernées soit lors de tests de qualification, la validation des parties prenantes, ou pendant les tests de recette.
Dans certains articles que j'ai déjà publié avant, j'ai présenté certaines bonnes pratiques de tests quand peut déployer et utiliser au sein des projets, qui sont basées sur la collaboration régulière et permanente de tous les acteurs de l'écosystème. À travers cet article je vais essayer de vous présenter une autre pratique autrement dit une technique de validation du produit, incrément, ou Release à livrer en production, on parle du "RTG" (Rally Test Game) qu'on appelle aussi "GOB" (Game Of Bugs).
Dans l'absence de l'implication des utilisateurs finaux lors de la phase de démonstration des incréments produits en fin de chaque Sprint, et lors de la phase de tests de recette, le RTG s'avère nécessaire et indispensable pour assurer la meilleure qualité fonctionnelle possible du produit en question.
Le Rally Test Game :
Le RTG est une pratique et Workshop organisé avant la mise en production dans la présence de tous les acteurs (Développeurs, Parties prenantes, Product Owner, Testeurs, et surtout Utilisateurs Finaux) qui a pour objectif principal d'assurer une couverture fonctionnelle maximale et optimale du produit / Release à mettre en production pendant une durée allons d'une journée à 3 jours selon la taille de l'application ou de l'incrément à livrer.
L'objectif de cet atelier est de bien détecter et remonter tout bugs ou anomalie très tôt afin d'anticiper sa correction tant qu'on a pas encore effectué la mise en production finale, c'est une solution pour valider ensemble l'application de bout en bout avec les utilisateurs finaux et dans la présence de tout les acteurs.
Mise en pratique :
Réunir tous les acteurs dans la même salle sous formes de mini-équipes mixtes.
Utiliser les même jeux de données pour toutes les équipes créées.
Timeboxer le Workshop selon la taille de l'application ou l'incrément en question (sur une journée par exemple).
Unifier les conditions de réussite pour toutes les équipes.
Effectuer les mêmes tests et scénarios d'usage pour de vrai sur la même application / Produit / Incrément concerné.
Lancer le Workshop (à animer par le Coach agile, ou autre acteur plus un responsable du fonctionnel).
À la fin de la journée ou la période décidée, on collecte les résultats et on procède à une analyse pour identifier les vraies anomalies détectées par l'ensemble des équipes à travers une restitution générale.
On enchaîne avec une période de correction afin de corriger l'ensemble des vrais bugs détectés et validés par le ou les responsables fonctionnels, ainsi que les évolutions nécessaire, et on ne s'arrête que lorsque tous les bugs sont traités et corrigés. Une fois c'est fait on peut procéder à la mise en production.
N'hésiter pas à utiliser le management visuel pour le suivi des tests permettant de suivre l'avancement des scénarios en cours. Un Award ou cadeau est prévu pour l'équipe ayant trouvé le plus de défauts retenus :).
Conclusion :
Le "RTG" reste une parmi les meilleurs pratiques indispensables pour les nouvelles applications et produits à mettre en production, mais en revanche nécessite la mobilisation et l'implication de tous les acteurs de l'écosystème surtout les vrais utilisateurs finaux.
On peut déployer et utiliser cette pratique pour un Sprint, une Release, ou un produit en entier,et c'est à chaque équipe de voir la fréquence d'utilisation de cette technique en tenant compte de la disponibilité des gens, ainsi que les contraintes budgétaires nécessaires.
Comments