La taverne du testeur

ATDD : génération automatique et gestion des tests dans un cadre agile

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

  1. 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”.

Exemple de demande de génération de scénarios de test sur l’US2

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”.

Tâche ayant été modifiée par plusieurs US (dont US19 dans ce sprint)

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

Sélection sur les valeurs de la colonne complémentaire à la table de décision et traçant les tickets agiles

Mode 2 : on utilise l’analyseur de couverture (qui détecte que US19 n’a pas de scénarios de test associés).

Utilisation de l’analyseur de couverture sur la colonne de traçabilité agile

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)

Utilisation de l’analyseur de couverture pour détecter des incohérences entre spécifications et scénarios de test

c) Il propose de corriger les scénarios pour tester la suppression

Exemple montrant la ligne à supprimer pour corriger le scénario

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 :

  1. La liste des artefacts touchés par les modifications (ex: UC, MUC, …). 
  2. Les tests déjà existants commençant par SPYY, YY n’étant pas le sprint en cours (XX).
  3. 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

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 », …

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Outils

Outil de test: concevez vos tests avec Yest

Yest en Bref Yest est un outil de conception de test qui se sert des schémas afin de rendre plus compréhensibles les scénarios. Cette modélisation graphique n’a pas seulement pour but de concevoir les tests. Yest peut également être utilisé pour faire de l’ATDD visuel et donc améliorer la communication

Lire la suite »
ATDD

Les 7 principes du test: tester tôt (3/7)

Dans cette série vous pourrez trouver dans chaque article une présentation d’une des 7 principes fondamentaux du test. Tester tôt Description Ce principe est assez simple à appréhender. Il rappelle qu’il est important/ nécessaire de tester aussi tôt que possible afin d’éviter que des problèmes mineurs et faciles à corriger

Lire la suite »
Interview

Rajae Aouchi: Ingénieur test et validation

Bonjour, qui êtes-vous, quel est votre métier et quelles sont vos activités professionnelles ? Je suis Rajae AOUCHI, Ingénieur Test et Validation depuis 3 ans, membre de la CMTL. J’ai découvert le métier du test lors de ma toute première expérience professionnelle durant mon stage de Projet de Fin d’Etudes chez SQLI, cette

Lire la suite »