La taverne du testeur

16 : Conseils d’application de l’ATDD en mode manuel et agile (1 / 3)

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 :

  1. Une epic “gérer son compte V1” qui doit être implémentée pour les releases 1 et 2.
  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”).
  1. 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 

  1. 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 
  2. 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

certifications

Certification ISTQB test manager: elle vaut le coup en Agile ?

La mise à jour des certifications ISTQB Chez QESTIT j’ai l’opportunité d’animer des sessions de formations aux diverses certifications ISTQB. Dans ce cadre j’ai été amené à animer des formations: Et vais prochainement animer une formation: Cette activité me permet de « réviser » des certifications que j’ai obtenues il y a

Lire la suite »
Présentation

Table ronde: des jeux pour le test

Revivez notre table ronde du 31 janvier 2022! Avec la participation de: Zoé Thivet: qui a écrit l’article sur la gamification dans le dernier livre du CFTL Christophe Moustier: concepteur du jeu proposé par Agilitest sur la maturité des pratiques de test Michael Granier: directeur des opérations chez Mr Suricate

Lire la suite »
Automatisation

Automatiser ses tests avec Agilitest

Agilitest en Bref Agilitest est un outil d’automatisation IHM en KDT qui a fait l’objet d’une présentation détaillée de sa première version dans la taverne. Le postulat d’Agilitest est que l’automatisation est complexe et demande des compétences techniques que les testeurs n’ont pas forcément. La compétence « automatisation » est donc relativement

Lire la suite »