Voyons comment un outil ATDD peut traiter la validation d’un produit (toutes ses fonctionnalités doivent marcher), mais dans le cadre d’un développement agile.
Test des fonctionnalités nouvelles en agile : le constat
En agile, nous l’avons vu, nous avons utilisé les colonnes complémentaires pour tracer les artefacts agiles (par exemple les US dans les tâches, ou les epics dans une fonctionnalité UC).
Donc le générateur devrait nous sortir les plans de test par artefact agile (par US par ex) pour les donner au testeur.
Autrement dit un outil ATDD doit être capable de générer plusieurs types de scénarios agiles :
- Les scénarios de test pour toute la table (une US INVEST par exemple).
- Ou les scénarios de test sur une sélection de la table, par exemple, obtenir les scénarios pour une US représentant une micro-évolution d’une tâche (un ou plusieurs critères d’acceptation pour la valider, mais pas la totalité des lignes de la table)
- Voire toutes les possibilités d’une colonne (par exemple toutes les US d’une tâche, à partir de la colonne traçabilité agile) sans avoir à les sélectionner une par une. Mieux encore, cette fonctionnalité devrait filtrer les US uniquement nouvelles. Cela pose la question suivante : comment l’utilisateur déclare-t-il les nouveautés, jusqu’où un générateur peut déduire les nouveautés entre 2 versions de spécifications de test d’un élément ?
On constate donc que ces fonctionnalités liées à l’agile sont possibles mais que l’utilisateur est amené à faire des manipulations : donner de façon précise toutes les informations (configurer des colonnes “intelligentes” …), faire ses demandes pour que le générateur puisse s’exécuter.
Nous allons vous illustrer, avec YEST, les différents cas rencontrés en agile et vous montrer comment faire.
Exemples de scénarios de tests d’US générés automatiquement
- Scénarios de tests d’une US INVEST
C’est le cas le plus simple. Il suffit de partir de la table de décision de la tâche correspondante et demander une génération “sur tout”.
2. Scénarios de test pour une nouvelle US d’une tâche (US comme ticket non INVEST)
Supposons que la tâche “afficher la page de la fiche S1 dupliquée” exige une petite correction (ajouter un picto ou non suivant les cas), donc un ticket US19.
On se retrouve avec une table de décision “multi-US”.
Il suffit alors de sélectionner US19 dans l’outil et de demander la génération des tests touchant uniquement cette US.
Mode 1 : On utilise la colonne traçabilité agile comme critère de sélection
Mode 2 : on utilise l’analyseur de couverture (qui détecte que US19 n’a pas de scénarios de test associés).
3- Exemple de suppression d’un/des critères d’acceptation dans une table existante
Dans ce cas :
a) on supprime la/les ligne(s) directement dans les tables (ex: suppression de la ligne US21 : pas de logo à afficher)
b) On appelle l’analyseur de couverture qui détecte un problème sur des scénarios en incohérence avec la suppression (les critères y sont toujours présents)
c) Il propose de corriger les scénarios pour tester la suppression
Tests de régression et agilité
Au-delà de dire “il faut re-exécuter les tests de régression”, le problème est de détecter lesquels ! Or le problème est TRES complexe.
Un outil ATDD aide à résoudre ce type de problématique, même si l’opérateur doit connaître comment procéder et reste indispensable …
L’outil doit être configuré par l’utilisateur pour avoir des plans de test par sprint, par acteur et par environnement.
Quand des modifications surviennent, vous pouvez nommer les nouveaux tests (que nous venons de voir dans le précédent paragraphe) par un préfixe SPXX désignant le sprint (ex: XX=27).
Les tests de régression sont alors déterminés par :
- La liste des artefacts touchés par les modifications (ex: UC, MUC, …).
- Les tests déjà existants commençant par SPYY, YY n’étant pas le sprint en cours (XX).
- Les tests SPYY qui restent valables, donc, par exemple, les tests d’UC qui ne traversent pas des US INVEST (tâches) supprimées ou des US INVEST modifiées (en analysant alors les US de correction de spécification qui s’invitent dans leur table de décision).
On a donc des actions manuelles à la charge de l’utilisateur : le nommage des scénarios, leur classement, … Mais surtout le testeur peut se tromper dans l’identification des tests restant valables ou non. Rien n’est automatisé, à ce jour … alors que cela pourrait être un défi lancé aux éditeurs d’outil et se faire !
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, notamment le langage de spécification de test « Business Modeling Language (BML) », les tests ATDD avec « l’algorithme des tamis successifs », …
