Nous avions suggéré lors de la présentation de l’ATDD automatisé que nous puissions assimiler les principes agiles pour les US de la manière suivante :
- Le PO gère les exigences des US (appelées “règles métiers”, et dans le détail “règles de gestion”) sous la forme “Quand … Alors” (le “Etant donné que” n’est dans ce cas utile que pour les règles qui sont en entrée de la User Story).
- De nommer alors “critères d’acceptation” les règles de gestion, puisque les développeurs, qui les comprennent et qui les implémentent, se doivent de les discuter, ensuite les développer et enfin les vérifier. D’autre part, l’US devant être spécifiée par le PO, et comme nous prenions le parti d’utiliser un outil ATDD de génération automatique de scénarios de test, nous avions décidé que les critères d’acceptation, exprimés en agile par le PO et expliqués aux développeurs et aux testeurs, pouvaient donc se traduire plutôt par les règles de gestion.
- Les “scénarios de test” sont en effet générés automatiquement à partir d’un algorithme sur les règles de gestion. Un générateur “tout ou rien” fournit un seul résultat. Il n’y a plus discussion sur les tests à effectuer, ils sont fournis (voire même automatisés) par l’outil ! Toute la discussion fonctionnelle entre le PO et l’équipe ne peut porter que sur les règles de gestion.
Les scénarios de test peuvent, quant à eux, se présenter textuellement sous la forme Gherkin : “Etant donné que … Quand … Alors”.
Cette décision est en concordance avec la philosophie de l’outil ATDD.
Mais cette position “critères d’acceptation (RG) vs Scénarios de test” est-elle encore tenable lorsqu’on n’utilise pas d’outil de génération automatique de scénario de test ?
Que disent les démarches agiles ?
Une US doit être documentée avec :
- Des critères d’acceptation sont discutés entre PO, testeurs et développeurs (“les 3 amigos”). Il n’y a donc plus de fait accompli, il faut chercher les scénarios …
- Ils fournissent les scénarios de test de l’US lorsqu’elle est traversée et, en même temps, la trame de développement de la démarche TDD
On perçoit une chose absurde … Il n’y a pas stricto-sensu d’exigence exhibée (constat : le mot exigence est banni de l’agile !). On ne parle pas davantage de règles métiers (issues de la traduction des besoins avec les utilisateurs) ou de règles de gestion (traduction, s’il faut, d’une règle métier en plusieurs exigences de la solution) qui sont couramment utilisées dans les projets traditionnels !
Comment alors s’assurer que la liste des scénarios proposés suffit au développeur pour réaliser l’US ?
Nous allons démontrer que ces consignes conduisent à “un massacre” (dixit Thierry Gabriel Cros). La qualité ne peut plus être certifiée (aucune référence), la complétude non assurée. L’ATDD manuelle remet au centre ces questions, tout en restant agile.
Critères d’acceptation et règles de gestion en ATDD manuel
Nous avons vu les principes ATDD. Il s’agit ici de mettre le vocabulaire en concordance avec le contexte de conception manuelle des scénarios de test : nous ne sommes plus avec un outil qui nous livre, sans donc trop de questions à se poser, leur liste et nous évite a priori du travail.
Nos choix de vocabulaire doivent s’adapter aux nouvelles problématiques d’une ATDD qui génère “manuellement” les scénarios de test.
- Une US est formalisée en ATDD par une simple table de décision
- Celle-ci contient en ligne les règles de gestion. Elles expriment la traduction tabulaire et textuelle, pour le développeur, de tout ou partie du besoin utilisateur (règle métier en lien, si nécessaire). La solution doit impérativement intégrer cette exigence.
- Une règle de gestion est une partie d’étape de l’US. Une étape peut se traduire par “Etant donné que l’utilisateur/le système doit <nom de l’étape>”.
- Une étape contient toutes les règles de gestion consistantes
- Une règle de gestion contient :
- Des colonnes pour exprimer la clause déclenchante : chaque colonne est une condition,
- Une colonne pour inscrire sous forme d’un ensemble d’observations (chacune séparée par un ET, si besoin),
- Une colonne “direction” désignant l’étape suivante,
- Des colonnes supplémentaires si nécessaire (ex: commentaires)
- Des colonnes “critère d’acceptation” (CA) que l’on va remplir manuellement. Attention cependant : Ce remplissage ne sera pas quelconque. Il utilisera un algorithme. D’autre part les 3 amigos décideront du critère d’arrêt des tests de l’US, autrement dit le nombre de critères d’acceptation souhaité (par exemple à partir de sa valeur et/ou de ses risques).
- Une cellule, par exemple en bas de chaque colonne de critère d’acceptation, donnera “l’objectif” atteint par le critère. Cet objectif va servir pour les tests de niveau supérieur.
- Une colonne pour tracer les tickets agiles qui spécifient chaque ligne (US INVEST ou “ticket de correction d’US” (USF : US Fix)
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.