La taverne du testeur

La génération automatique de tests avec un outil ATDD

Evidemment le gros avantage d’un outil ATDD est de produire les scénarios de tests, puis les tests, à partir de la modélisation effectuée : les graphiques et les tables. Que faut-il en penser ?

Points d’attentions à avoir sur un générateur automatique de tests ATDD

Trois points sont au moins à vérifier :

  • Un générateur “tout ou rien” ou un générateur par “tamis successifs” ?

L’outil vous propose des tests sur un périmètre, mais avez-vous moyen d’avoir une proposition et une orientation de stratégie pour un nombre de tests plus limité ? La solution d’un générateur livrant tous les tests possibles (“générateur total” n’est pas la solution s’il s’agit pour vous de décocher ensuite manuellement les tests inutiles pour vous, sans être guidé !

Donc si vous avez 25 tests générés mais que vous n’avez que 5 tests à faire (manque de temps, risques faibles …), vous passez du temps à analyser vous-mêmes, ceux que vous gardez ! L’intérêt d’un générateur faiblit grandement …

L’outil doit utiliser une stratégie par types de cibles à atteindre sur le modèle graphique. Certains types sont facilement atteignables (ex: passer une fois par chaque sous-élément) d’autres plus complexes (ex: passer par tous les chemins du point d’entrée aux points de sorties). En ce qui me concerne, j’utilise sur un modèle ATDD une manière précise pour filtrer petit à petit les cibles. C’est, ce que j’ai appelé, “l’algorithme des tamis successifs” : près d’une dizaine de stratégies qui couvrent petit à petit les spécifications de test ATDD (“les cibles”). Cela marche depuis très longtemps et a été utilisé sur tout type de système, depuis des logiciels embarqués jusqu’aux systèmes d’informations bancaires, des plus simples aux plus complexes (plusieurs centaines de M€).

Il faut savoir que les outils ATDD, même en posant des colonnes supplémentaires dans les tables de décision, ne peuvent pas automatiser simplement cet algorithme et donc les outils ATDD n’ont pas toujours un générateur modulable.

  • Le générateur tient-il compte de contraintes métiers ?

Avec certains outils vous pouvez poser des contraintes référentielles, mais pas avec tous.  Par exemple si X>0 alors il est impossible que Y<0. Dès lors proposer un chemin qui contiendrait la première condition, puis la 2eme, n’a aucun sens métier.

  • Le générateur supporte-t-il les boucles ? 

La modélisation peut avoir des boucles, quoiqu’on en dise. Or, si vous testez un outil ATDD sur une modélisation avec boucles, encore plus lorsqu’il y a des contraintes sur celles-ci (j’ai pris l’exemple de 2 tentatives maximum pour entrer un mot de passe pour sortir d’une fonctionnalité), alors le générateur peut s’y perdre … Il faut alors connaître son fonctionnement intime pour chercher à l’aider et contourner son problème ! Ce n’est pas acceptable.

Puissance d’un outil ATDD

En forçant l’utilisateur à gérer ses données et les conditions sur elles, vous pouvez avoir des analyses d’impact très puissantes. 

Vous pouvez aussi vérifier la complétude de vos tables de décision. Il suffit de scruter les conditions non encore mises en jeu.

Un outil ATDD peut proposer des analyses pour « débugger » les problèmes qui, si elles sont bien maîtrisées, me paraissent puissantes.

Exemple de fonctionnalité de début avec l’outil YEST

Vous devez avoir dans un outil ATDD des analyses de couverture très fines. Or cette fonctionnalité, si elle existe pour un générateur “total”, c’est pour découvrir que le générateur n’a pas réussi à résoudre certains chemins !

Cependant une autre idée est de vérifier que l’outil est aussi capable de vous donner des taux de couverture correspondant aux différents tamis, s’il est modulable. Ainsi vous pouvez mieux jauger votre effort de test ou votre critère d’arrêt des tests.

Exemple de fonctionnalité d’analyse de couverture avec l’outil YEST (générateur « tout ou rien »)

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 *

Automatisation

Outil de test : automatiser ses tests de navigateur avec Kasaya

Kasaya En bref : Un nouvel arrivant dans les outils de tests : Kasaya L’avantage de cet outil est que ce que vous voyez c’est ce que vous obtenez. Autrement dit, les actions qui seront décrites (un peu comme du Keyword Driven Testing) dans votre script seront compréhensibles par le navigateur (Chrome

Lire la suite »
Automatisation

Améliorer la productivité et l’efficacité des tests

Introduction La plupart du temps lorsque j’arrive sur un projet j’entends parler de problèmes avec les tests. Certaines phrases comme celles-ci-dessous sont récurrentes : ·        Les tests prennent trop de temps ·        Il y a trop de bugs en productions, les tests sont donc mal faits ·        Il faut automatiser pour tout améliorer et

Lire la suite »
Qualité

Qualité vs Surqualité

Introduction :  Aussi impliqués et passionnés que nous puissions l’être dans nos métiers d’informaticiens, il ne faut pas se voiler la face, le nerf de la guerre en matière de projets reste tout de même les finances.  Pour que la réalisation d’un produit soit considérée comme un réel succès par

Lire la suite »