Nous allons aborder dans cet article la présentation des artefacts agiles et leur documentation de test. Nous insisterons sur l’impérieuse nécessité de comprendre que l’agilité ne tue pas la vision du système que doit avoir le PO (ce qu’on veut faire ?), et qui est différente des tickets de développement du système (comment le faire ?).
Distinguer artefacts agiles et fonctionnalités du produit
Le produit, même si l’on réduit son utilisation à un cas d’usage (le produit utilisé sous des conditions bien précises), possède des fonctionnalités.
Les “artefacts agiles” (US, epics, features …) sont les éléments à développer pour réaliser les fonctionnalités identifiées dans le contexte du cas d’usage (par exemple celles d’un parcours client).
Les testeurs agiles devront donc :
- Tester les nouveaux artefacts agiles : les US ou les artefacts en cours de réalisation (epics / features), et cela pour tous les sprints. Ils se répartissent le travail par niveau de granularité des artefacts agiles (A titre d’exemple d’organisation : testeur IT indépendant des développeurs pour les US, PO pour epics/features, tout en contrôlant les US traversées).
- Tester la régression des fonctionnalités du produit, selon les différentes granularités de ces fonctionnalités. Les fonctionnalités qui ne sont pas impactées par les modifications apportées au système doivent toujours fonctionner (sous-entendu donner le résultat attendu).
Spécifications de test, scénarios de test et tests : ce n’est pas pareil !
Remarquez que depuis le début de notre article nous parlons de « spécifications de test » et non de tests. Si nous prenons l’exemple suivant :
Etant donné que je suis manager ET que le devis est prêt à être envoyé
Quand le prix du devis est supérieur ou égal au « seuil de risque » (*) ET la facture de type X ou Y
Alors le manager reçoit un mail pour le valider.
(*) le seuil de risque est une constante. A ce jour (Elle peut varier), elle est fixée à 50000 euros.
C’est une spécification de test. Elle correspond, dans ce cas, à un la description d’un comportement attendu par l’utilisateur.
Cette spécification de test fait partie de la spécification plus générale de « l’élément agile » (avec des caractéristiques liées à l’élément, des maquettes, …).
Elle nécessite, à elle seule (une autre règle traite le cas du devis inférieur strictement au seuil de risque), 2 scénarios de tests :
ST1 : J’ai un devis >= seuil de risque ET facture de type X
ST2 : J’ai un devis > =seuil de risque ET facture de type Y
Enfin ST1 est un scénario de test qui exige 2 tests :
- T1-1 : devis = seuil de risque (ex : à ce jour 50000 euros) ET une facture de type X (F209)
- T1-2 : devis très largement supérieur au seuil de risque (à la limite haute – 9999999 euros) et un type de facture X (F342)
Notons pour le TDD, qu’une fois cette spécification de test codée, le programmeur attend une autre spécification pour le cas des devis inférieurs au seuil de risque et de type X ou Y, et pour les autres types de facture. Si le manager ne reçoit rien dans ces cas, il n’empêche que « rien » nécessite néanmoins des scénarios de test et des tests pour le vérifier !
BDD et ATDD
Nous verrons le cas des éléments à tester hors US par la suite, et, de ce fait, nous verrons comment le BDD n’est pas, en général, une démarche de spécification suffisante pour les spécifier.
En ce sens on pourra conclure que le BDD est une démarche de spécification essentiellement réservée aux US, ce qui la distingue d’une autre forme de spécification que nous détaillerons dans les prochains articles : l’ATDD (Acceptance Test Driven Development).
Les différents artefacts à tester fonctionnellement en agile
Par « élément » à spécifier et à tester il faut entendre des « artefacts agiles » qui sont :
- Une User Story (US) : plus petit élément fonctionnel ayant du sens pour le PO et à développer en un sprint. Il faut impérativement noter qu’elle correspond aussi à un ordre de développement matérialisé par un “ticket” (donc documenté).
- Mais aussi toute ou partie du système
Cela peut-être alors :
- Une fonctionnalité agile (feature au sens SAFe, une epic au sens Scrum) qui représente une fonctionnalité souhaitée par le Product Owner (PO). Elle peut être composée comme un ensemble d’US.
- ou bien plus encore. On veut ainsi pouvoir tester une « macro-fonctionnalité agile ». Cela peut être même toute ou partie d’une « activité » d’un parcours client, confrontée à une itération nouvelle.
Pour illustrer notre propos et simplifier la compréhension, prenons l’exemple d’une activité du parcours client « vendre un immeuble » au sein d’un office notarial. La macro-fonctionnalité agile « Signer électroniquement un contrat de vente d’immeuble » exigera 4 mois de développement (il faut en effet inclure toutes les clauses possibles, prévoir tous les cas d’immeubles …). Et ce n’est qu’une macro-fonctionnalité agile (le cadre est posé : on signe pour un immeuble, pas pour un acte de mariage !) du parcours client « vendre un immeuble ». On pourrait aussi, vu la difficulté, se dire qu’on va faire la macro-fonctionnalité « signer électroniquement un immeuble pour un couple » et « signer électroniquement un immeuble pour un célibataire » si cela est trop complexe.
Une macro-fonctionnalité agile met en jeu plusieurs fonctionnalités agiles en construction. Elles ne sont pas à l’état « fini » après un sprint de développement puisque ces macro-fonctionnalités agiles se réalisent généralement sur plusieurs itérations.
Si on fait des tests en continu, on veut vérifier progressivement que ces macro-fonctionnalités agiles correspondent aux résultats attendus.
On peut, in fine, faire des tests entre macro-fonctionnalités (si le système est complexe), ou de bout en bout pour traverser le parcours client dans sa totalité, dans le cas d’un processus simple.
Artefacts agiles et spécifications agiles
Nous n’avons pas précisé ici les termes des démarches agiles désignant les macro-fonctionnalités agiles. Mais constatons que :
- Soient les PO ne les utiliseront pas. Ils conserveront alors la notion d’activité de parcours client sur laquelle ils décriront dans un document word des évolutions agiles. L’évangélisation pour créer des artefacts autres que des US reste un travail de tous les jours !
- Soient, plus rarement, ils parleront d’epics (histoires en Scrum, ou ensemble de features, comme dans SAFe par exemple, autrement dit des macro-histoires, mais sans les spécifier de manière BDD. Là encore un document Word, plus ou moins structuré, plus ou moins précis, servira de référence.
On retiendra donc qu’au-dessus du niveau « user story », les éléments agiles (appelés parfois features, parfois epics, selon les démarches) utilisent rarement le BDD … car ce formalisme est souvent jugé difficile à mettre en oeuvre. En effet, au-delà des mots clés à utiliser, comment exhiber les règles de comportement qui lui sont propres ? Que signifie un critère d’acceptation d’une macro-fonctionnalité ?
Pour les user stories, cependant, pas de souci ! Les démarches agiles de type Scrum les obligent à respecter un gabarit documentaire. On y retrouve les « critères d’acceptation », terme équivalent à « spécifications de test » que nous avons aussi utilisé. Le BDD, avec les « critères d’acceptation » et la formulation GHERKIN s’y sont imposés.
Cependant, autre point à bien noter, une US a une durée de vie éphémère. Une fois développée, elle disparaît dans les limbes du projet. Le PO n’a plus que sa documentation du système comme référence (en espérant qu’elle existe !) et, en particulier, des critères d’acceptation système et des Tests de Régression qui expliquent ce que l’utilisateur attend de lui.
Niveaux de test en agile
Pour tester un système en agile (typiquement un parcours client), on s’appuie sur l’architecture des artefacts :
- D’abord les composants, pour le développeur
- Puis les user stories
- Puis les fonctionnalités demandées par le PO (features SAFe, epics Scrum)
- Enfin les macro-fonctionnalités agiles, et même de « bout en bout » pour s’assurer que le parcours client s’effectue bien malgré des dépendances entre macro-fonctionnalités. Par exemple « annuler une vente » … c’est compliqué de « détricoter »les données et le statut des objets après avoir exécuté « réaliser une vente » !!!
L’organisation des tests est hors sujet dans cet article. Disons qu’à chaque niveau il faut y associer des responsabilités.
Exemple (chaque équipe auto-organise sa « stratégie de test ») :
- Composant : à la charge des développeurs,
- US : Si le PO gère le « backlog » des US, leurs tests sont souvent à la charge des « Business Analysts agiles » ou « testeurs » indépendants des développeurs dans l’équipe IT,
- Fonctionnalités agiles demandées par le PO : à la charge du PO,
- Macro-fonctionnalités agiles : à la charge du PO,
- parcours partiels ou complets entre macro-fonctionnalités : l’utilisateur final.
Ce qu’il faut retenir
En définitive, sachant que nous allons approfondir les notions, on peut résumer les principes énoncés de la manière suivante :
On pourra noter, concernant le BDD, que :
- Ces spécifications de test permettent au développeur de programmer en agile des User Stories sous la forme TDD. La forme de spécification de test utilisée est le critère d’acceptation « Gherkin ».
- C’est à la fois une spécification GHERKIN, mais aussi une spécification de test dédiée US.
L’ATDD, de son côté, est :
- Un autre type de spécifications de tests
- Et est destinée à des tests de niveau supérieur (intégration et validation du système) qui ont besoin de spécifications plus complètes que le BDD.
Ce schéma essaie de résumer et d’éclaircir le vocabulaire agile. Concernant la distinction BDD et ATDD, nous verrons qu’en fait, l’ATDD propose une solution de spécifications de test qui englobe le BDD (nous y reviendrons). Autrement dit, l’ATDD ne devrait pas être utile pour une US. Vouloir faire de l’ATDD sur une US c’est démontrer que l’US est trop complexe !
Dernier point : il est FONDAMENTAL de comprendre que nous avons d’une part le point de vue des développeurs qui doivent réaliser par itérations successives le produit, et, d’autre part, le point de vue du PO et des testeurs qui ont à concevoir et tester un produit.
Nous avons donc deux approches qu’il faut rendre compatibles. Nous verrons tout l’impact de ce schéma pour la génération automatique de tests et pour l’ATDD.
Mais, l’ATDD, de quoi s’agit-il exactement ? Nous allons aborder ce sujet dans les prochains articles.
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. profil 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 (Ex : 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.
