4- Problèmes sur les US : leurs critères d’acceptation

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.

  1. Une US est formalisée en ATDD par une simple table de décision
  2. 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.
  3. 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>”.
  4. Une étape contient toutes les règles de gestion consistantes
  5. 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)
  6. 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).
  7. 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.
  8. 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.

Laisser un commentaire

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

Automatisation

Le calcul du ROI des tests automatisés, que prendre en compte ?

Pour calculer le ROI des tests automatisés il faut d’abord bien estimer le coût des tests. J’en avais déjà parlé dans cet article. Le coût des tests ce n’est pas que leur exécution. Le coût des tests c’est : ·        L’écriture du cas (coût qui n’arrive qu’une seule fois) ·        Le coût de

Lire la suite »
culture générale

Les niveaux de test

Le syllabus fondation ISTQB 2023 propose une évolution sur 5 niveaux. Vous pouvez retrouver un article similaire basé sur cette version du Syllabus en allant sur ce lien. Pour avoir un exemple imagé sur les niveaux de test je vous invite à lire cet article complémentaire. Introduction : Il existe d’après

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 »