Rappelons que le travail des 3 amigos (Développeur, testeur et Product Owner) va consister en ATDD à :
- Valider les RG qui spécifient la tâche (celle-ci représente en effet l’US initiale, dont il faut assurer la non-régression, et ses corrections de détail dont il faut garantir la bonne implémentation).
- Choisir ensuite, en fonction du risque encouru par la tâche (l’US si aucune erreur de spécification n’intervient) et de sa valeur, la couverture de test que l’on désire. En principe la capacité à faire n’a pas à être un obstacle, sinon la qualité pourra se révéler moindre que celle attendue.
Ce principe nous le reprendrons au niveau des autres éléments du produit et de la prise en compte des tickets agiles de plus grande granularité.
Ainsi l’algorithme des tamis successifs, que nous préconisons (en réalité ayant un énoncé pour les US et un autre pour les autres artefacts métiers), vise à fournir des tests progressivement, jusqu’au niveau de qualité attendu, et de manière simple.
Énoncé de l’algorithme pour une US
On part de l’hypothèse que les exigences fonctionnelles de la solution sont rédigées en BML, soit sous la forme textuelle, soit sous une forme tabulaire.
Dans ce cas, on essaie, en cochant les différents pas de test par un n° (du n°1 au n° x qui sort de l’US), d’aboutir aux buts suivants :
- Parcourir l’US via le chemin nominal (chemin le plus courant qui traverse l’US)
- Parcourir l’US pour couvrir au moins une fois chaque objectif d’US (par objectif d’US il faut entendre les ”sorties boîte noire” de l’US, qui peuvent être reprises pour les tests d’intégration)
- Parcourir l’US pour couvrir au moins une fois chaque étape
- Parcourir l’US pour couvrir au moins une fois chaque RG
- Parcourir l’US pour couvrir au moins une fois chaque alternative dans une condition (avec un/des OU)
L’algorithme permet des taux de couverture progressifs
Cet algorithme est progressif car les buts sont de plus en plus difficiles à atteindre.
Pour autant, il arrive parfois que plusieurs buts soient atteints avec un même scénario de test.
Chaque scénario de test explicite tous les résultats intermédiaires.
Chaque scénario de test donne lieu à un critère d’acceptation qui se formule sous la forme :
Etant donné que <pré-requis du scénario>
Quand <liste des conditions satisfaites>
Alors <objectif de l’US atteint>
Le critère d’acceptation perd ainsi l’annotation des résultats intermédiaires, sauf à les fournir en commentaires (ce qui est peu rigoureux, inacceptable, peu exploitable).
Exemple de critères d’acceptation obtenus par l’algorithme des tamis successifs pour l’US INVEST
Prenons l’exemple d’une authentification simple.
Le critère d’acceptation 1 représente le chemin nominal.
Etant donné que je suis client ou prospect identifié,
QUAND l’identifiant est saisi correctement à la première tentative
ET le mot de passe est saisi correctement à la première tentative
ALORS la connexion au site est réussie.
Le tableau est auto-suffisant et précis (tous les comportements intéressants pour le développeur et le testeur y figurent). Il est inutile en fait d’écrire le critère d’acceptation sous forme GHERKIN puisqu’il se déduit du texte des RG traversées. C’est donc très rapide (agile !). Il suffit de se concentrer sur les spécifications (RG) et d’appliquer l’algorithme qui s’avère être efficace et aligné sur les objectifs du testeur.
Ce critère n°1 atteint ainsi l’objectif de connexion : O1.
Donc la prochaine étape de l’algorithme est d’arriver à tester O2, et tant qu’à faire, en ajoutant des nouvelles RG testées !
On s’aperçoit qu’après ce 2ème critère d’acceptation :
- On a aussi traversé toutes les étapes (1 et 2) au moins une fois !
- Mais RG2-2 et RG2-3 n’ont jamais été testées (en fait nous sommes à 4/6 de RG testées, soit 66%).
D’où le critère d’acceptation n°3 pour compléter la couverture des RG à 100%.
Dans cet exemple, il n’y a pas d’alternatives dans les conditions, donc l’algorithme s’arrête.
La méthode est ainsi très rapide, systématique. Les scénarios de test sont mis en évidence et le principe de leur génération repose sur une logique parfaitement compréhensible et justifiée. Reste donc à parler de leur implémentation sous la forme de “tests”, c’est-à-dire en utilisant des valeurs pour les données manipulées.
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.
