Les activités de qualification fonctionnelle sont une composante essentielle de l’assurance qualité du système d’information. Après avoir été longtemps le parent pauvre du développement informatique, le test connaît actuellement une véritable révolution fondée sur une industrialisation de ses processus, une professionnalisation des métiers du test, l’arrivée à maturité d’une chaîne outillée allant des exigences au référentiel de tests, et enfin la mise en place de centres de service, internes ou externes, dédiés aux activités de test.
Le coût et l’origine des anomalies
Toutes les études réalisées, tant par les analystes ou au niveau académique convergent : le coût de traitement d’une anomalie, selon sa détection en phase de qualification logicielle ou après la mise en production, peut aller d’un rapport de 1 à 1 000.
La figure 1 illustre cette réalité. Une anomalie détectée sur le terrain, lorsque l’application est en exploitation, implique de lourds processus d’analyse, de correction, de patchs spécifiques ou généraux et de livraison. À cela s’ajoute la dégradation d’image, ou même la perte de revenu, par exemple pour un site de vente en ligne. Un phénomène encore accentué par l’aversion croissante des utilisateurs envers les anomalies : les multiples dysfonctionnements d’une application ou le non-respect des exigences métier deviennent insupportables. Pour l’utilisateur, la qualité n’est plus négociable.
On a aujourd’hui une idée assez précise de l’origine des anomalies. Comme l’illustre la Figure 2, issue d’une étude parue dans Crosstalk, the Journal of Defense Software Engineering, sur la répartition des anomalies selon leur origine, la mauvaise prise en compte des exigences métier constitue une source importante d’anomalies sur le système d’information. Pas de surprise : on sait bien à quel point il est difficile sur le terrain de prendre en compte des référentiels d’exigences métier complexes, évolutifs, et pour souvent peu formalisés.
Ce type d’anomalies, issues d’une mauvaise implémentation des exigences fonctionnelles, sera principalement détecté en phase de qualification fonctionnelle, c’est-à-dire lors des phases de test visant à vérifier la bonne implémentation métier. La qualité ne se résume pas au test et doit irriguer tout le processus de production et la phase de qualification fonctionnelle. Ceci constitue une étape clé pour assurer la bonne adéquation aux exigences métier et limiter les anomalies graves se produisant en exploitation.
Ainsi, la performance des phases de test fonctionnel constitue un enjeu essentiel des DSI , des grands intégrateurs et, plus globalement, des différents acteurs de l’IT . Ces phases de tests fonctionnels doivent assurer une couverture complète des exigences métier afin de maximiser leur impact en termes de détection d’anomalies.
L’industrialisation du test fonctionnel
Assurer la performance et la maîtrise des coûts des phases de test fonctionnel implique la mise en place d’un processus rigoureux, maîtrisé, systématique, dont la qualité soit reproductible sur chaque projet concerné : l’industrialisation du test fonctionnel.
Les bonnes pratiques de cette industrialisation permettent de définir les clés du succès en la matière. Elles peuvent être synthétisées en 7 points principaux :
- Définir un budget pour la qualification fonctionnelle. La qualification fonctionnelle doit être budgétée en tant que telle et faire l’objet d’un suivi en phase avec la gestion du projet. Ce budget garantit la réalisation des activités de qualification fonctionnelle indépendamment des aléas du développement de l’application. L’estimation d’un projet de test demeure une activité difficile. Cependant, elle peut s’appuyer aujourd’hui sur des méthodes analytiques qui permettent, en lien avec un suivi des projets et des métriques, une meilleure fiabilité de ces estimations.
- S’appuyer sur une équipe spécialisée dans le test. Le test est une activité dont l’efficacité passe par la mise en place de méthodes et processus outillés permettant de garantir à la fois la qualité des tests (en termes de détection d’anomalies) et d’assurer une bonne productivité de la production des tests. L’industrialisation des tâches de qualification conduit ainsi à préciser les différents fonctions et rôles qui doivent être réunis dans le cadre d’un projet, depuis les analystes jusqu’aux administrateurs, en passant par les chefs de projet, les consultants et dans le domaine du support : les responsables méthodes et outils. Les compétences seront structurées au sein d’une équipe de test, dont la transversalité dépendra de l’organisation de l’entreprise. Un tel centre de test peut être constitué en interne ou s’appuyer sur un dispositif de sous-traitance, par exemple une tierce recette applicative. L’important est que la recette s’appuie sur une équipe spécialisée, maîtrisant les savoir-faire spécifiques des activités de test, et formée aux méthodes et aux outils.
- Démarrer les activités de qualification dès le début du projet. Une erreur courante consiste à positionner l’ensemble des activités de qualification fonctionnelle en fin de projet : lorsque le projet est en retard et qu’il est urgent de livrer. En fait, la bonne solution consiste à commencer la production des tests dès les phases de spécifications terminées, voire en amont avec les aspects stratégie de test et identification des exigences. Pour cela, l’approche par génération automatique des tests est un outil puissant, car la génération automatique s’appuie sur un modèle de test qui est élaboré en parallèle des développements, permettant une production du référentiel de tests en phase avec les livraisons prévues. Ce modèle de test permet aussi de détecter au plus tôt les ambiguïtés ou les contradictions au sein des spécifications, avec un bénéfice immédiat pour le projet grâce à leur consolidation.
- Piloter la production des tests à partir des exigences métier avec la génération automatique de tests (démarche « Model-Based Testing »). Définir les exigences fonctionnelles et qualifier sur la base de ces exigences permet d’assurer l’alignement entre l’application informatique et les besoins métier. Ainsi, les tests de qualification fonctionnelle doivent être élaborés à partir des exigences métier et montrer la couverture (matrice de traçabilité bidirectionnelle des exigences vers les tests). Il s’agit d’assurer le pilotage des activités de test par les enjeux métier. La génération de tests à partir d’un modèle des exigences (appelé modèle de test) permet de systématiser la couverture des exigences, de prendre en compte le niveau de risque lors de la génération des tests, et de faciliter la maintenance du référentiel de test.
- Automatiser l’exécution des tests dans un objectif de test de non-régression et maîtriser cette automatisation. L’exécution uniquement manuelle des tests ne peut permettre d’assurer ni la qualité de la recette (trop incertain dans sa mise en oeuvre), ni le time-to-market (trop long dans sa mise en oeuvre lors des tests de non-régression), ni la maîtrise des coûts (trop cher du fait de la répétition). Lorsque l’application bénéficie régulièrement de mises à jour fonctionnelles ou techniques, il est pertinent de passer à l’automatisation des tests pour permettre de tester suffisamment et de traiter les problèmes potentiels de régression. Mais l’automatisation doit être maîtrisée, en particulier en utilisant des techniques de génération automatique des tests automatisés qui structurent la production des scripts en s’appuyant sur des mots-clés et facilitent la maintenance. L’automatisation peut aussi être freinée par des problèmes de testabilité de l’application. Ainsi, les automates de tests peuvent être difficiles à mettre en oeuvre sur des parties graphiques ou sur des outils de développement peu ou mal supportés. L’automatisation devra donc être maîtrisée pour trouver son efficacité (rapport effort/bénéfice) maximum.
- Mettre en place des métriques et un tableau de bord de suivi des résultats des activités de qualification logicielle. Il s’agit de définir les indicateurs et leur suivi afin d’évaluer la qualité des applications lors de leur réalisation, de leur utilisation et à l’occasion de leurs évolutions. Pour partie, ces indicateurs sont directement issus des activités de qualification fonctionnelle (en termes de couverture et de suivi d’anomalies en particulier). Ces indicateurs permettent de suivre l’évolution dans le temps des critères de qualité, mais participent aussi à la maîtrise des schémas de sous-traitance. La qualification fonctionnelle peut ainsi être considérée comme partie intégrante du système d’information de la gouvernance des applications informatiques.
- Appuyer la transition vers la mise en exploitation par la qualification fonctionnelle et mettre en place un processus continu de qualification. La transition des phases de développement vers la mise en exploitation constitue une étape cruciale du projet, où se produisent de nombreux échecs. Une bonne pratique consiste à faire courir la phase de qualification logicielle sur les premières étapes de la mise en exploitation de façon à assurer une continuité des phases de test et des premières exploitations terrain. Il s’agit de procéder à la mise en place d’un processus continu de qualification garantissant au delà du processus plus global de gestion des configurations logicielles, la bonne réalisation de ce dernier en particulier dans son étape ultime de mise en exploitation. Les équipes en charge de la qualification fonctionnelle seront ainsi à même d’apporter leur expertise aux premières phases de mise en exploitation, et d’assurer une continuité de service dans la prise de maturité de l’applicatif. C’est aussi un moyen d’engager profondément la responsabilité de l’équipe de test qui doit garantir non seulement la phase de recette et la couverture des exigences fonctionnelles, mais aussi faire le lien entre le référentiel de test et les retours du terrain.
Ces sept bonnes pratiques des activités de test fonctionnel sont au coeur des démarches réussies en matière d’assurance de la qualité du logiciel. Elles correspondent aux enjeux clés des organisations amenées à gérer l’aversion des utilisateurs aux bugs, la complexité croissante des applicatifs et la globalisation des démarches de développement.
Conception et maintenance du référentiel de test avec la démarche «Model-Based Testing»
La conception du référentiel de tests doit permettre d’assurer une bonne couverture fonctionnelle des exigences dans le référentiel, de faciliter la maintenance des tests lors d’évolutions applicatives ou techniques, et permettre une automatisation, au moins partielle, pour maîtriser les coûts d’exécution lors des phases de test de non-régression. Ces points sont complexes, et la création, la maintenance et l’automatisation des tests constituent actuellement une zone de difficulté majeure pour les projets de test.
La génération automatique de tests à partir de modèle permet d’obtenir une continuité entre les exigences métiers et le référentiel de tests, d’assurer le suivi des évolutions fonctionnelles de l’application et d’accélérer la production du référentiel de tests automatisés en prenant en charge des tâches répétitives et laborieuses. C’est ainsi une composante essentielle de la démarche d’industrialisation du test fonctionnel.
Les approches et techniques de génération automatique de tests ont été développées depuis le début des années 90, et sont connues au niveau international sous le terme « Model- Based Testing (MBT) ». Elles ont donné naissance aujourd’hui à des solutions outillées de production et de maintenance du référentiel de tests, qui s’intègrent avec la gestion du référentiel et les environnements d’automatisation des tests, et supportent un processus de bout en bout : des exigences métier au référentiel de tests automatisés.
La Figure 4 fournit une description du processus de production de test MBT. Ce processus met en oeuvre une chaîne outillée intégrant la gestion des exigences, la génération de tests et la gestion du référentiel de tests et de leur automatisation.
Le point de départ de la production du référentiel de test est constitué par les exigences métiers et les éléments de spécification. Ces exigences sont définies par les analystes ou experts métiers et gérées dans un outil spécialisé, sous la forme de document textuel ou dans un tableau avec une feuille de calcul.
Le référentiel de tests est produit par l’analyste de test, et s’appuie sur une modélisation dédiée pour la génération de tests (le modèle de test). Il bénéficie de l’apport d’outils de génération automatique de tests pour calculer les tests, documenter le référentiel de tests et assurer automatiquement la traçabilité entre les exigences et les tests. Cette démarche permet ainsi d’assurer la couverture des tests à partir du modèle.
Les tests générés sont exportés dans le référentiel de tests – flèche 2. S’il s’agit de tests nouveaux, ils sont créés dans le référentiel ; s’il s’agit de tests existants, leurs informations (description des pas de test…) sont mises à jour dans le référentiel ; si un test est supprimé, il est rendu obsolète (invalidé) dans le référentiel. Les liens de traçabilité entre les cas de tests et les exigences de test sont mis à jour – flèche 1 pour assurer la cohérence de l’ensemble. Ce processus facilite la maintenance du référentiel, car une évolution fonctionnelle, une fois prise en compte dans le modèle de test, est répercutée automatiquement sur l’ensemble du référentiel de tests.
Dans le cas de la production de tests automatisés, le script de tests est généré (ou mis à jour s’il existait déjà) – flèche 3. Les étapes du script font appel à des fonctions (appelés aussi mots-clés ou composants de tests) implémentées par l’ingénieur d’automatisation. En génération automatique de tests, les scripts sont générés et maintenus automatiquement avec l’outil de génération. Seule la bibliothèque de fonctions (ou de composants de test) fait l’objet d’une implémentation et d’une maintenance manuelle.
Dans le cas d’une exécution manuelle des tests, la documentation du modèle de test permet de générer des tests totalement lisibles et exploitables par un testeur. Les données concrètes de test peuvent être gérées à partir du modèle de test, ou positionnées sur des scénarios paramétrés définis au moment de l’exécution des tests (au travers de tables de données par exemple).
Ce processus met en oeuvre les compétences des différents acteurs de la chaîne outillée : l’expert métier, l’analyste de test qui développe le modèle de test, le testeur qui exécute manuellement les tests et l’automaticien de test qui implémente les mots d’action utilisés.
Bénéfices du « Model-Based Testing »
Les apports de la démarche MBT pour la structuration du processus de test, l’amélioration de la productivité et l’augmentation de la couverture fonctionnelle sont les suivants :
- Maintenance du référentiel - Le modèle de test permet de formaliser les exigences et les règles métier au travers d’une modélisation des comportements à tester. Ce modèle factorise les règles fonctionnelles, et simplifie la maintenance en cas d’évolution sur les exigences : une évolution fonctionnelle se traduit par une évolution dans le modèle et permet une mise à jour automatique de la base de tests générée.
- Couverture fonctionnelle - Le générateur de tests permet de produire la couverture fonctionnelle souhaitée en assurant une couverture systématique des comportements applicatifs et des processus métiers modélisés.
- Productivité de la production des tests - à partir du modèle de test, l’ensemble des informations du référentiel de tests est automatiquement produit et maintenu lors de la génération puis de la publication. Cela simplifie la tâche de l’analyste de test qui se concentre sur la formalisation des comportements à tester et la définition de la stratégie de test. Les gains de productivité peuvent être de plus de 50 % en phase de création du référentiel de tests et de plus de 70 % en phase de maintenance.
- Automatisation des tests - les tests générés sont documentés pour une exécution manuelle et produits sous forme de scripts dans le langage du robot de test. C’est une aide importante pour l’automatisation, qui est structurée par la définition des mots d’actions au niveau du modèle. Chaque mot d’action est implémenté sur l’IHM ou les API de l’application à tester. Ces éléments permettent d’améliorer le retour sur investissement de l’automatisation. En général, un retour sur investissement est obtenu après le 5ème ou 6ème rejeu des tests (sans changement), avec cette démarche on tombe à un retour sur investissement au bout de la 2ème ou 3ème exécution.
- Consolidation des exigences fonctionnelles – La modélisation de test permet de détecter des ambiguïtés de spécification, et de mettre en évidence des contradictions entre différentes règles métier. C’est un apport important pour consolider les exigences fonctionnelles.
Ces apports se déclinent dans différents contextes du test fonctionnel : test d’acceptation, de qualification fonctionnelle, d’intégration de sous-systèmes applicatifs et de sécurité (test des fonctions de sécurité).
Illustration : la qualification du site ServiDirect.com
L’application ServiDirect – www.servidirect.com - est issue d’un groupement d’assurances suisses qui a souhaité proposer un service en ligne pour la souscription à un contrat d’assurance maladie suisse avec une tarification simplifiée et unifiée. Cette application a été développée par la société CLIO SA - Genève.
La validation a été effectuée à l’aide des techniques de génération de test à partir de modèle UM L dans le cadre du projet Interreg Test_Indus – Industrialisation du test logiciel – soutenu par la communauté européenne – cf http://lifc.univ-comte.fr/test_ indus/. Nous avons réalisé une modélisation de l’application web ServiDirect (http://www.servidirect.com) qui permet de saisir en ligne les informations nécessaires à l’élaboration d’un devis d’assurance maladie et la possibilité de souscrire un contrat en ligne.
La production d’un référentiel de tests automatisés vise la couverture des exigences fonctionnelles et le calcul de la prime d’assurance en fonction des options choisies. Le calcul de la prime varie en fonction de l’âge, du genre, du choix du package, du capital décès/invalidité choisi, de la franchise et des options éventuelles.
La chaine outillée mise en place pour ce projet de test est constituée des outils suivants :
- Réalisation du modèle de test (UML) : IBM Rational Software Architect
- Génération de tests : Smartesting Test Designer
- Gestion du référentiel de tests : TestLink (open-source)
- Automatisation des tests : Selenium (open-source)
- Suivi des anomalies : Bugzilla (open-source)
Les exigences fonctionnelles pour cette application sont au nombre de 40. Elles ont été complètement représentées dans le modèle de test réalisé avec l’outil IBM Rational Software Architect.
Figure 5 : Extrait des exigences ServiDirect
La modélisation pour le test est réalisée en UML en utilisant trois types de diagrammes :
- Le diagramme de classes permet la définition des entités métier (nom d’entités, attributs), des relations entre ces entités (par des associations) et la déclaration des actions réalisées sur l’application (via des opérations) ; il s’agit d’une représentation statique de l’application testée.
- Le diagramme d’états, précisé avec des annotations en OC L (Object Contraint Language), permet de représenter le flot ou processus métier d’enchaînement des actions de l’utilisateur ; il s’agit du comportement dynamique de l’application : il spécifie les effets des actions de l’utilisateur sur l’application testée en termes d’évolutions des valeurs des attributs des entités métier. Ainsi, le modèle de test représente le comportement attendu de l’application dans les différentes sollicitations dont il peut faire l’objet.
- Le diagramme d’objets (aussi appelé diagramme d’instances) permet de représenter les données logiques (les classes d’équivalence) de test et l’état initial de l’application au travers d’instances du diagramme de classes, c’est-à-dire les tests de saisie des champs et les contrôles s’y attachant et le calcul de la prime. La première étape a été de définir le diagramme de classes associé à l’application.
Le diagramme de classes représente les actions réalisées sur l’interface ServiDirect, et qui constitueront les pas de test, et les données métiers manipulées lors des tests (par exemple le lieu de résidence ou les informations sur la famille, ou les réponses au questionnaire médical).
Figure 6 : Diagramme de classes du modèle de test ServiDirect
Le processus métier de l’application ServiDirect est représenté par un diagramme d’état UML, ou les états représentent les éléments de l’interface, et les transitions les actions utilisateurs réalisées sur cette interface.
Les différents écrans de l’application apparaissent dans ce diagramme. Ce choix de modélisation a été fait pour assurer une couverture des champs de saisie. Les transitions entre deux écrans sont activées typiquement par des boutons à cliquer.
Figure 7 : Diagramme états/transitions ServiDirect
Une fois l’état initial du système défini, le modèle est importé dans l’outil de génération de tests Test Designer. Pour ServiDirect, le nommage des tests à été personnalisé de manière à visualiser rapidement les cas de test nominaux et les cas d’erreurs. Ils sont préfixés NOMINAL ou EREUR. Comme le montre la Figure 8, nous retrouvons aussi les exigences (requirements) définies dans le modèle UML.
Figure 8 : Test généré par Test Designer pour ServiDirect
Une fois les tests générés, ils sont publiés dans le référentiel de test TestLink, comme l’illustre la Figure 9.
Figure 9 : Tests ServiDirect dans TestLink
L’automatisation repose sur le codage Sélénium de chacune des opérations définies dans le diagramme de classes qui correspondent aux actions sur l’application tel que le ferait un utilisateur : saisir le champ date, cliquer sur le bouton ‘OK’…
Ces opérations sont appelées depuis les fichiers de scripts contenant les tests à exécuter. La Figure 10 illustre l’exécution d’un script par Sélénium sur l’application ServiDirect. Une fois le script exécuté le résultat est intégré dans TestLink et un lien peut être fait avec Bugzilla en cas de détection d’une anomalie. La saisie se fait manuellement, via un bouton dans l’application TestLink permettant de lancer Bugzilla.
Figure 10 : Exécution d’un script Sélénium sur ServiDirect
La génération de tests produit automatiquement 86 cas de test logiques qui correspondent à 1078 pas de tests. Après mise en place des tables de données pour introduire la combinatoire sur le numéro postal, l’âge, le genre et le nombre de membres de la famille, ceci correspond à 162 tests concrets exécutés sur ServiDirect, tous automatisés.
Les temps passés dans les différentes activités (réalisation du modèle de test, implémentation des mots d’action) ont permis d’atteindre des ratios de productivité de plus de 8 scripts automatisés par jour/homme, qui correspond à une métrique représentative des résultats obtenus avec la démarche de « Model-Based Testing ».
Le test fonctionnel fait sa révolution !
Après avoir été longtemps une activité de « second rang » du développement logiciel, le test s’impose comme une activité clé pour l’assurance qualité des applications du SI. Cette prise de conscience se traduit au niveau de l’organisation des équipes, de la mise en oeuvre de processus outillés et de la qualification aux métiers du test :
- Organisation des équipes de test – L’organisation en centre de test se généralise, permettant de spécialiser les compétences et les processus pour répondre efficacement au besoin de test des projets. Ces centres de test peuvent être internalisés ou externalisés, mais l’objectif est le même : aller dans le sens de l’industrialisation des processus de test.
- Processus outillés et méthodes – Les processus outillés s’appuient sur la génération des tests, la gestion centralisée du référentiel de tests et l’automatisation pour le test de non-régression. Ils permettent une mise en oeuvre efficace de méthodes basées sur la couverture des exigences. Ces processus s’appuient sur des outils qui sont aujourd’hui matures et intégrés.
- Qualification des équipes - Le FAFIEC, organisme collecteur de la formation continue dans le secteur logiciel, a créé un plan « Métiers du Test » pour former aux différents rôles d’analyste de test, d’automaticien de test, et de responsable d’équipe test. Plus récemment, la Nomenclature 2009 du CIGREF sur « Les emplois-métiers du SI dans les grandes entreprises » a introduit le métier de testeur. Le test est devenu un des métiers du logiciel, avec des qualifications et savoir-faire spécifiques.
Ces éléments sont une bonne nouvelle, car ils vont dans le sens de systèmes d’information plus fiables et de coûts de qualification mieux maîtrisés. La démarche « M odel-Based Testing » est au coeur de cette évolution, car elle permet d’assurer la continuité du processus de test, depuis les besoins métier jusqu’au référentiel de tests automatisés.
Industrialiser le test fonctionnel : des exigences métier aux référentiels de tests automatisés
Bruno Legeard et Fabrice Bouquet
DUNOD - avril 2009
Voir www.portaildutest.fr
lun, 23/11/2009 - 15:15 | 
amg
