L’agilité apporte avec elle bon nombre de nouveaux termes. Parfois cette inflation ne se justifie pas, parfois cela permet de poser un terme sur une pratique qui était déjà diffuse, parfois c’est une réelle avancée … Bien difficile de s’y retrouver !
Le but des 2 articles que je vous propose est de clarifier les différentes notions de base sur les tests en agile, afin, ensuite, de vous présenter la démarche de test « ATDD outillée » avec des exemples concrets. Nous les présenterons aussi au regard des démarches traditionnelles pour expliquer aux profanes les évolutions.
Précisons bien le périmètre de notre sujet :
- Nous allons parler uniquement des tests de type « tests fonctionnels » (et pas de tests de portabilité, de performance ou autres – cf. types de test ISO 25010). Nous voulons nous assurer que la solution couvre l‘ensemble des besoins qu’elle doit assurer (complétude), que ces résultats sont corrects (exactitude) et qu’il est possible de l’utiliser (aptitude à l’usage).
- Nous évoquerons aussi, dans la série d’articles, les « tests de régression » en agile qui sont les tests exécutés sur une version de la solution préalablement testée mais qui a subi une ou plusieurs modifications (définition ISTQB).
Qu’est-ce que le TDD ?
Le « Test Driven Development » (TDD) est une pratique agile. Ce sont les « tests du programmeur » (Wikipedia), au centre de l’activité de programmation. La méthode XP, dont la démarche agile s’est inspirée, préconise en effet d’écrire les tests avant de coder. Le principe théorique est donc, pour le développeur, de coder une « spécifications de test » d’un “composant” jusqu’à ce que celle-ci soit un succès et que les autres spécifications de tests déjà préparées pour ce composant continuent de fonctionner.
Le plus souvent, le principe théorique se transforme en pratique de la manière suivante : je programme les nouveautés amenées par des spécifications de tests d’un “composant”, je les teste, je ré-éxécute les tests déjà existants du composant et qui fonctionnaient, je corrige les bugs, je re-teste, etc.
Elle ne signifie pas forcément que l’on automatise l’exécution des tests, bien que l’amalgame soit souvent réalisé car l’approche incrémentale, par tests successifs et ré-exécutions, nécessite beaucoup d’énergie !
Qu’est-ce que le BDD ?
Le BDD (Behaviour Driven Development) est, peut-on lire, la déclaration de comportements attendus pour « l’élément agile » à développer et à tester. Il concerne le Product Owner (PO) pour formuler les exigences utilisateurs et les acteurs IT (principalement le « Business Analyst ») pour formuler les exigences systèmes de la solution.
Pour notre part nous affirmons, ce qui est une autre façon de le présenter, que le BDD est une « méthode de spécification de test », c’est-à-dire à usage du développeur mais aussi du testeur.
En ce sens, on voit bien que le BDD est un préalable au codage afin de respecter le TDD.
La question est de savoir s’il existe d’autres méthodes pour spécifier les tests que celle proposée en BDD. Nous allons y revenir avec l’ATDD qui propose en effet une alternative…
BDD et Gherkin
Force est de constater, dans les faits, que BDD rime avec formulation « GHERKIN ». Cette dernière propose qu’une User Story (US : pour faire simple, le plus petit élément fonctionnel spécifié faisant le lien entre PO et développeurs) puisse avoir des spécifications de test sous la forme de “critères d’acceptation” textuels :
Etant donné que <texte des pré-conditions de l’US »,
Quand <ET de conditions>
Alors <ET d’observations constituant le résultat attendu pour le critère>.
Remarques :
- Le terme “critère d’acceptation” utilisé en agile a provoqué beaucoup d’ambiguïté (une de plus …). Il s’agit d’accepter ou non l’US. Cela n’a rien à voir avec les tests d’acceptation d’un système que les personnes connaissent depuis très longtemps !
- Le “étant donné que” pose souvent problème au testeur car on lui demande de distinguer, d’une part le contexte existant, et d’autre part les événements d’entrée. La phrase n’a en fait qu’un intérêt : poser, au départ, les pré-conditions de l’élément à tester. Très souvent, d’ailleurs, les testeurs les mettent une fois pour toute dans une rubrique dédiée (cf. les outils comme Xray qui le proposent).
- Un critère d’acceptation, c’est une vérification nécessaire du comportement de l’US, comme un ensemble de conditions et d’observations au sein de l’US. L’US peut en effet se décomposer en étapes. Un scénario de test de l’US est alors vu comme la traversée de critères d’acceptation pour aller depuis l’entrée de l’US jusqu’à une de ses sorties.
Le BDD est-ce nouveau ?
Si on donne pour définition que le BDD est une démarche de spécification de test, alors nous avions déjà la notion de « Règles de Gestion » (RG) en mode traditionnel (cycle en V – notion d’event Driven architecture). Ces RG se regroupaient en règles métiers puisqu’elles doivent former un tout cohérent. Autrement dit, une règle métier est une exigence utilisateur et se raffine en règles de gestion qui représentent des exigences du produit (système) à réaliser. On peut aussi ajouter qu’une règle métier doit utiliser un gabarit d’énoncé tel que l’IREB nous le conseille.
Nous avions souvent, pour les règles de gestion, la formulation « SI … ALORS ». Donc dans la pratique agile, sur le terrain, en utilisant la formulation QUAND … ALORS, on retrouve peu ou prou nos règles de Gestion ! Bilan : on a changé le “SI” par “QUAND” et la “Règle de Gestion” en “critère d’acceptation”, pas de quoi crier à la révolution et s’extasier !
Exemple du mode traditionnel : la règle métier RM2 “Etant donné que l’utilisateur ne s’est pas identifié, le système doit contrôler que la zone géographique du visiteur est bien l’île de France afin que le visiteur soit accepté” est composée uniquement de trois Règles de Gestion qui traduisent tous les cas de la règle métier, sans en oublier (“cohérence et complétude des RG”).
Si la règle métier RM2 fait l’objet de l’étape 2 de l’US nous aurons par exemple 3 critères d’acceptation pour la solution :
RG2-1 : Quand la ville du visiteur est hors région “Ile de France” Alors le message d’erreur “zone géographique non admise” s’affiche ET l’utilisateur sort de l’US
RG2-2 ; Quand la ville du visiteur est dans la région “Ile de France” ET la ville du visiteur est Paris Alors l’utilisateur doit préciser par une nouvelle saisie des informations de localisation plus précises (étape 3).
(étape 3 : rue, arrondissement avant de sortir de l’US – que je ne détaillerai pas ici).
RG2-3 : Quand la ville du visiteur est dans la région « Ile de France » et la ville du visiteur n’est pas Paris Alors l’utilisateur sort de l’US ET le menu d’accueil s’affiche).
Notons que si l’US était ultra-simple et n’avait que les étapes 2 et 3, alors nous aurions 3 scénarios de test (chaque scénario ne traverserait qu’une seule RG – c’est-à-dire un seul critère d’acceptation agile, voire 2 pour les Parisiens) et 2 « états de sortie » (l’état de sortie « erreur de localisation : visiteur hors Ile de France » et l’état de sortie « ville du visiteur en Ile de France »). Le terme « état de sortie » est considéré comme un résultat de l’US mais sans en regarder, cette fois, ses détails internes (le visiteur peut être de Paris ou d’une autre ville d’île de France, il est accepté). On peut donc avoir le même état de sortie sur plusieurs sorties distinctes.
Si on considère l’US avec une étape 1 précédant l’étape 2, et sans étape 4, nous pourrions avoir la règle métier RM1 de l’étape 1 (Etant donné que l’utilisateur ne s’est pas identifié, le visiteur doit être majeur afin de pouvoir accéder au site) et deux critères d’acceptation :
RG1-1 : Quand le visiteur se déclare majeur Alors il passe à l’étape 2
RG1-2 : Quand le visiteur se déclare mineur Alors un message d’erreur est affiché (site e-commerce interdit aux mineurs) ET il sort de l’US et de l’application
Un scénario de test serait, par exemple (ST 1), le passage avec succès dans RG1-1 et RG2-3 : nous avons affaire à un majeur habitant en Ile de France, mais pas à Paris. Ce scénario se classerait parmi ceux qui ont pour état de sortie « Visiteur accepté », alors que nous aurions aussi des scénarios ayant pour état de sortie « visiteur non accepté » (état atteignable sur plusieurs sorties possibles et pour lequel les causes de rejet n’ont pas d’importance).
On comprend que la spécification de test est liée à des règles métiers, qui se focalisent sur des sujets à traiter (l’âge du visiteur, la localisation géographique …), tandis que les scénarios de test sont issus d’une réflexion sur les critères d’acceptation traversés.
Certes une US doit être simple et nous pourrions énoncer le scénario de test ST1 directement, et sous forme Gherkin …
Etant donné que l’utilisateur n’est pas identifié, Quand l’utilisateur est Majeur ET l’utilisateur habite en Ile de France ET l’utilisateur n’habite pas Paris Alors l’utilisateur est accepté ET le menu d’accueil s’affiche.
Cependant cette analyse ne correspond pas au raisonnement métier qui spécifie « par sujet ». C’est une erreur, selon moi, que de vouloir en agile mélanger scénario de test et critères d’acceptation, même si une US est simple.
Il faut donc poser les critères d’acceptation Gherkin qui correspondent à une analyse des règles métiers et assurent la traçabilité avec les besoins utilisateurs, et, ensuite, en déduire les scénarios de test sous une forme non ambigüe (une liste de critères traversés peut être une des formes possibles).
On retiendra que le BDD prend toute sa puissance en agile. En effet, il doit être en entrée du TDD. De ce fait, le “BDD” a permis d’évangéliser les foules (PO, Business Analystes, développeurs) et de se diffuser … mais notons que cela n’est pas d’un point de vue théorique, et expliqué à des MOA chevronnées, une grande nouveauté en soi ! Alors maintenant que ces concepts ont été rappelés, il nous reste à revenir sur les notions relatives au développement d’un système en agile : les artefacts associés et leur documentation de test. C’est le sujet du prochain article.
A propos de l’auteur
Didier JOLIOT est formateur de l’offre Modern Product Agility (MPA) mise en place avec Stéphane BADREAU et couvrant tant l’aspect de savoir-faire agile que celui du savoir-être.
Le blog MPA : https://mpa.systeme.io
Didier a une grande expérience professionnelle (plus de 40 ans) et très diversifiée (cf. LinkedIn).
Il a d’abord été développeur puis responsable qualité et certification de logiciels temps réels critiques (Airbus, systèmes d’armes, nucléaire …). Il a été ensuite consultant pour les MOE bancaires, puis AMOA, directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il a pratiqué le cycle en V, et, depuis 2012, l’agilité. Il a notamment conduit les spécifications et les tests fonctionnels de très gros projets de SI (Crédit Agricole, Société Générale).
En devenant alors coach agile il a aidé de nombreuses équipes Scrum et de nombreux programmes « à l’échelle » sur des bases SAFe.
Il a écrit 5 ouvrages et de nombreux articles. Il a créé, de plus, plusieurs méthodes dans des domaines variés : la CNV-A (Communication Non Violente Agile), mais aussi le langage de spécification de test « Business Modeling Language (BML) », les tests ATDD avec « l’algorithme des tamis successifs », etc.
