En conclusion de nos articles, d’une part sur l’ATDD avec un outil générant les scénarios de test et les tests (scénarios avec les valeurs spécifiques en conditions et observations), d’autre part une approche ATDD qui spécifie et teste de manière systématique et rapide les exigences, que pouvons-nous dire ?
Le test agile doit rester centré sur le produit à livrer
Souvent on pense que le test en agile c’est le test des US, celles-ci étant souvent créées même lorsqu’elles ne sont pas INVEST. La série d’articles, je l’espère, rectifie cette vision.
- Les tests agiles doivent aussi être ceux qui vont valider le produit dans sa globalité (jusqu’aux tests de parcours, notamment pour le PO) : c’est un système dont la complexité peut être forte. Réalisé, ou non, en agile, cette réalité demeure !
- Les tests agiles doivent nécessairement s’appuyer sur une spécification claire du système, indépendamment des tickets de réalisation. Comment trouver les tests de non régression si vous ne mettez pas ensemble les règles qui constituent le produit et pouvoir analyser leurs interactions ? Nous avons vu que nous nous appuyons sur les spécifications des fonctionnalités du produit (MUC, UC, tâches) et non pas les artefacts agiles. Ayant testé cette dernière solution, je l’ai abandonnée dès que je me suis aperçu que je perdais en visibilité d’ensemble et en morcelant inutilement le système. Par contre dans la méthode proposée il suffit de poser les fonctionnalités (relativement stables dans leurs libellés, à défaut de leur contenu) et “taguer” les évolutions agiles.
- L’algorithme des tamis successifs est donc applicable à ces éléments de produit, avec la capacité de filtrer les impacts des tickets agiles :
- En mettant une colonne de “traçabilité tickets agiles” dans les tables
- En utilisant BML pour juger de l’utilisation des données dans tout le système, sans se soucier de rechercher dans les documents leurs sprints de création, modification ou utilisation.
Le nombre de scénarios de test doit être proportionnel aux risques encourus
Ce principe existait déjà en mode traditionnel (cycle en V). Toutefois il devient encore plus prégnant en agile du fait des changements fréquents. Il faut de la qualité (elle n’est pas négociable, même en agile !), mais pas de sur-qualité car les délais de réalisation sont contraints.
Ceci implique deux conséquences :
- Les générateurs ATDD doivent nous proposer des scénarios de test “à la demande”. Leur intérêt diminue s’ils nous fournissent beaucoup trop de scénarios que nécessaires !
- Un algorithme doit être compris et guidé par le bon sens. “L’algorithme des tamis successifs”, que je propose, répond à ces objectifs. Il a le mérite d’avoir été très longuement utilisé sur des projets de toute taille et de toute criticité.
Il montre bien que la granularité des points à tester s’affine (une analogie avec l’affinage des epics en US pourrait être appliquée : on commence par le plus important – le cas nominal, on finit par les détails – les cas alternatifs). L’algorithme explique bien cette image des “tamis” qui sont d’abord à “grosse maille” puis diminuent.
Pour les 3 amigos, il faut d’abord se concentrer sur les exigences avant de trouver systématiquement les critères d’acceptation
Les exigences fonctionnelles (nous n’avons parlé que de celles-ci) doivent respecter des critères qualité : elles doivent être complètes, précises, claires, sinon vous vous exposez à des spécifications ambiguës, des développements erronés, des tests insuffisants… et dans ce cas, tout le monde est perdant !
Nous voyons qu’un algorithme fondé sur une grammaire textuelle et/ou graphique, simple mais rigoureuse, amène à des critères d’acceptation et des scénarios de test précis.
Le langage Gherkin dont beaucoup ne retiennent que la forme n’est pas suffisant puisqu’il faut ajouter des commentaires après chaque étape (Quand) pour connaître le résultat intermédiaire.
Le langage de spécification BML (Business Modeling Language) me paraît plus adapté, tout en ne contredisant pas Gherkin, mais en le précisant.
Des scénarios de test aux tests
Une fois les scénarios de test mis en évidence, les tests d’US INVEST utilisent les données à tester sur chaque affirmation.
Les principes, là aussi, montrent une graduation progressive du nombre de tests en fonction des valeurs spécifiques à tester (limites du spectre des valeurs d’une donnée ou frontières spécifiques, internes au spectre).
Concernant les tests conçus manuellement en mode ATDD, la désignation des scénarios réutilisables suffit pour le PO pour comprendre les données à utiliser. De la même manière qu’un roadbook pour les vacances désignent, en quelques pages, les villes et visites essentielles, sans indiquer chaque rond-point, le PO connaît l’ application. Inutile de dire plus que l’intention d’un scénario bien décrit par ailleurs.
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.
