Dans un article de juin 2025 je présentais Bugs End, un jeu coopératif que j’ai créé avec Julien Cahu. Comme dit, Bugs End est avant tout un jeu!
Mais, comme vous le savez, les jeux sont un outil d’apprentissage puissant. Au delà du côté ludique nous souhaitions mettre en avant la complexité de la gestion de la qualité dans un contexte Agile. Et pour cela nous avons fait des choix au niveau des règles qui ont orienté notre Game Design.
Le but de cet article est d’expliqué ces choix à travers des règles qui peuvent paraître complexes pour des non habitués aux jeux de société mais qui deviennent vite naturelles pour des personnes travaillant en Agile.
Le découpage d’un produit en User Story
Un produit développé en Agile c’est un produit construit de manière itérative dont les briques sont des user story qui sont, autant que possible, INVEST. Ce travail de découpage n’est pas toujours facile mais nécessaire si l’on veut vraiment proposer un produit construit en Agile.
Bugs End propose 3 produits découpés en 30 user storys qui répondent à cette problématique et peuvent servir d’exemple:
Les itérations
Un produit agile est construit en itération… Lorsque l’on travaille en Scrum, ces itérations sont des sprints de durée identiques. Nous avons souhaité mettre cela en avant avec des itérations constituées d’un nombre de tours fixe.
De même, la charge de travail dans une itération absorbable par l’équipe dépend du nombre de joueurs. Le contenu et la qualité attendus pour le produit est fixe. La seule variable d’ajustement est le nombre d’itérations. C’est pourquoi, moins il y a de joueurs, plus il y a d’itérations pour finir totalement le produit.
Enfin, à la fin de chaque itération, le produit est livré en production. Il se doit d’avoir un niveau de qualité suffisant
Les bugs
Ne pas tester ne veut pas forcément dire que l’on aura automatiquement des bugs.
De même le terme « bug » est assez vague. La complexité est assez élevée, nous avons cependant souhaité mettre en avant 3 éléments importants:
- La notion de criticité
Nous avons choisi 4 niveaux de criticité (cosmétique, mineur, majeur et critique). L’idée est de mettre en avant que les bugs ne sont pas tous aussi impactant. Les bugs mineurs peuvent être acceptables pour les utilisateurs contrairement aux bugs critiques qui empêchent l’utilisation du produit.
De même, en fonction de l’impact du bug le travail de correction n’est pas le même.
C’est ce que nous avons apporté avec les cartes bugs.
- La diversité des bugs
Il n’y a pas un seul type de bug. Un service numérique est complexe, l’évaluation de la qualité l’est également. C’est pourquoi nous avons proposé différents types de bugs, liés pour un grand nombre à des critères qualité. Chacun de ses critères peut être plus ou moins impactant… Et apparaitre être présent selon les fonctionnalités.
C’est ce que nous avons voulu montrer avec les types de bugs (fonctionnel, affichage, UX, accessibilité, synchronisation, sécurité, API, portabilité et régression)… Chaque type de bug pouvant avoir des criticité plus ou moins importantes:
- Le fait que la détection de bugs n’est jamais certaine
Pour cela nous avons ajouté de l’aléatoire avec une probabilité de présence de bugs quand la phase de test n’a pas été complétée (voir le plateau). Nous avons par contre choisi, d’un point de vue de game design, de ne pas avoir de probabilité de bugs (hors événement) si le processus de test est bien respecté.
La régression
Un produit construit en Agile est un produit qui grossit au fur et à mesure des itérations. C’est également un produit potentiellement utilisable (ou en production) à la fin de chaque itération. Tester les nouveautés est essentiel… Mais il faut aussi s’assurer que les fonctionnalités déjà implémentées sont toujours utilisables.
Pour cela il est nécessaire d’exécuter des tests de régression. Le nombre de ces tests dépend de la taille et de la complexité du produit déjà utilisé. Nous avons pris en compte cela avec l’identification du nombre d’exécution de tests de régression en fonction du nombre de storys présentes à la fin de l’itération précédente. Pour une partie en mode « normal » c’est 1 exécution pour 2 storys implémentées.
La suite
Dans un (ou des) prochain(s) article(s) je présenterai la logique derrière les cartes actions et bonus de Bugs End.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
