Envisageons la situation où nous sommes une équipe agile ayant à spécifier et tester un parcours client en démarche agile, et sans outil autre qu’un outil de ticketing et un outil comme support des exigences et des tests (définition et exécution). C’est le cas le plus courant …
Illustrons alors par un exemple l’approche de la conception des tests en agile, tout en se rappelant de la démarche schématisée ci-après.
Identifier les tickets de réalisation pour un sprint
Pour notre exemple, la liste des artefacts agiles est la suivante :
- Une epic “gérer son compte V1” qui doit être implémentée pour les releases 1 et 2.
- Des features qui composent l’epic et qui déterminent la release 1 :
- Une feature F1 (“créer son compte”)
- Une feature F2 (“évaluer le risque client” – réalisée de manière autonome par le système)
- Une feature F3 (“S’authentifier de manière simple”).
- Si on détaille ici uniquement F3 (une analyse par US est aussi faite pour F1 et F2), la feature F3 se décompose dans le sprint 1 en une seule US : “se connecter de manière simple”. En effet l’histoire F3 consiste uniquement à essayer de se connecter (identifiant/mot de passe) avec 3 tentatives maximum.
Spécifier les US nouvelles en BML avec une table de décision et les scénarios de test issus de l’algorithme des tamis successifs
On peut dériver, à partir des exigences fonctionnelles (les règles de gestion), les scénarios de test et critères de décision.
Les 3 amigos (développeur, testeur et PO) ont déterminé le niveau de risque des US et donc l’algorithme connaît ses critères d’arrêt pour chaque US.
Par exemple l’US INVEST “se connecter de manière simple” a pour résultat celui déjà fourni dans un des articles précédents. Toutes les étapes de l’algorithme peuvent être couvertes en 3 scénarios.
Le développeur sait ainsi développer en TDD, le testeur peut vérifier l’US, le PO est informé de l’avancement du code et peut dialoguer avec les testeurs.
Intégrer les US INVEST et tester les fonctionnalités du produit
- La modélisation BML de chaque UC (ensemble d’US INVEST) est réalisée, par exemple par le PO sachant que l’équipe s’auto-organise
- La modélisation BML de la MUC (ensemble d’UC) est réalisée
Prenons uniquement l’exemple de la MUC “gérer son compte”.
On réalise sa schématisation graphique BML suivante :
3. Les spécifications permettent d’appliquer l’algorithme des tamis successifs que nous avons vu.
Changer par des US ce modèle, c’est modifier et taguer les alternatives touchées (voire en ajouter).
Il suffit donc pour le PO d’appliquer l’algorithme et taguer dans les scénarios les nouveautés (décisions, transitions/alternatives ou traitements touchés). Ainsi les scénarios ayant au moins un tag sont à jouer pour valider l’intégration des tickets agiles du sprint, tandis que ceux non tagués sont ceux de la non régression.
Ici, pour le macro-UC “gérer son compte” on peut passer en 2 scénarios sur toutes les alternatives du modèle qui servirait pour valider à “la version 1 du MUC”, c’est-à-dire l’epic “gérer son compte V1”.
Une fois cette epic terminée, et plusieurs semaines après, pourrait surgir une nouvelle epic “gérer son compte V2”, par exemple pour ajouter des traitements en cas d’erreur de compte … Il est très rapide alors de tester, par l’algorithme, tant les nouveautés apportées par le sprint agile que les aspects de non régression.
Nous observons, même si l’exemple présenté est très simple (en réalité un modèle BML graphique peut contenir jusqu’à maximum traitements … mais je ne conseille pas d’en mettre plus), les 3 points suivants :
- L’algorithme s’applique bien à toutes les granularités de fonctionnalité
- Le tableau des transitions en E/S permet de trouver rapidement les scénarios de test des nouveautés du sprint agile ou ceux de non-régression, et cela même sans outil.
- Les 3 amigos se concentrent davantage sur la modélisation et son contenu, les risques associés aux fonctionnalités du produit, et “jouent” à utiliser l’algorithme. C’est en effet très ludique !
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
