En matière de Qualité Logicielle, il existe plusieurs approches permettant d’appréhender et de concevoir les tests logiciels (test de transition d’états, test de cas d’utilisation, couverture de code, etc). Nous allons explorer dans cet article une de ces approches qui monte en puissance dans les organisations et les cellules de Qualité Logicielle : Le Model-Based Testing, ou MBT.

Le MBT est une approche graphique de conception de tests fonctionnels. C’est une technique 'boite noire' dont le but est de générer des suites de tests à partir d’un modèle abstrait des fonctionnalités et du comportement attendu du logiciel. Le modèle est conçu sur la base des exigences ou spécificités du système.

Les suites de test peuvent être générées :

Offline : Les suites de tests sont générées dans un premier temps et devront être compilées pour pouvoir être exécutées. Différents formats sont envisageables :

Instructions pour exécution manuelle

Scripts et langages de programmation (C#, Java, etc.)

Graphiques (diagramme d’états, d’activités, etc.)

Online : Les suites de tests sont exécutées dès leur création

Le schéma global de mise en œuvre du MBT tel que présenté par l’ETSI (European Telecommunications Standards Institute) est décrit ci-dessous :

Trois grandes étapes se démarquent :

La modélisation : elle est réalisée en fonction des objectifs de tests par l’Analyste de test en collaboration avec l’Analyste métier. Le modèle est associé à des tables de décision.

La génération des tests abstraits : les tests sont générés automatiquement en fonction des critères de sélection appliqués sur le modèle.

L’adaptation de tests : permet la cohérence entre les tests abstraits et les scripts exécutables sur le SUT. Cette étape, réalisée par l’ingénieur automaticien, permet l’interfaçage avec les frameworks de tests automatisés (Appium, Ranorex, Cucumber, Squash TA, Selenium, etc.)

Il existe des logiciels permettant de créer ces modèles et de générer des scripts de tests à partir de ces modèles. Ils s’appuient en général sur le BPM ou sur l’UML (en langage OCL), méthodologies qui peuvent être complexes à appréhender et difficiles à mettre en œuvre dans des cellules de qualification déjà existantes.

Face à cette complexité, on assiste à l’émergence d’outils très 'user-friendly', beaucoup plus accessibles en termes de modélisation et qui s’insèrent surtout dans un mode de développement Agile.

On peut citer par exemple Yest qui est un outil sur licence qui propose une approche visuelle du pilotage, de la conception et de la maintenance des tests manuels et automatisés.

Exemple d'un Workflow de gestion de contrat modélisé avec Yest de Smartesting (http://smartesting.com/fr/yest/)

On retrouve aussi CA Agile Requirements Designer, que nous avions vu précédemment lors de la JFTL 2018 à la conférence 'Tester une voiture connectée, Tests multi-canaux'.

Cet un outil complet qui permet la modélisation et l’export des scripts directement vers des frameworks de tests (web, mobile, Desktop, UI, etc.) en TDD et BDD. En Open Source, on retrouve FMBT qui s’appuie sur des librairies Python et qui est multiplateforme.

Pour conclure, le déploiement d’une approche MBT apporte cependant des contraintes en termes :

De compétences de modélisation des Analystes testeurs/Automaticiens.

D’expressivité car il est demandé de représenter l’ensemble des conditions sur le modèle (d’où l’utilisation d’annotations).

D’investissements en outils pour les entreprises (les outils réputés aujourd’hui étant sous licence.

Cependant, elle présente de nombreux avantages non négligeables tels que:

Une meilleure compréhension et maîtrise de la complexité du système et des tests grâce à l’aspect graphique.

La communication simplifiée avec les Business Owners via le modèle.

L’amélioration de la phase de test en permettant une meilleure couverture fonctionnelle.

La réduction des coûts de conception et de maintenance des tests (une modification du modèle se répercutera sur l’ensemble des cas de tests associés).