Consolidez vos pratiques de tests à travers vos projets

Contexte

Pour une entreprise de développement logiciel, les projets successifs sont à la fois semblables et différents. Différents parce que les fonctionnalités demandées changent à chaque projet, rendant difficile la réutilisation au niveau des tests. Semblables parce que ces projets restent généralement ancrés dans un même domaine métier, c’est-à-dire ancré sur des mêmes concepts. Tant au niveau d’exigences fonctionnelles telles que les protocoles de communications ou non-fonctionnelles en matière de performance, d’utilisabilité ou de sécurité. En fin de compte, la réutilisation concerne donc plus le know-how associé aux processus que les artefacts de tests eux-mêmes.

Ce constat s’applique par exemple dans le domaine des cartes à puces où les projets consistent à développer différentes applications d’identification ou de paiement. Ces applications ont beaucoup de similarités car elles utilisent tout un ensemble de commandes envoyées via un protocole spécifique (APDU) entre la carte et le lecteur. Les contraintes dans ce domaine sont très fortes en matière de fiabilité et de sécurité. En effet, une erreur non détectée peut avoir de graves conséquences pour le client. Cela peut entrainer des coûts énormes de correction voire de rappel des cartes avec une atteinte conséquente à la réputation de l’émetteur de la carte. Dans ce domaine, le processus de test est donc particulièrement poussé et couteux et le besoin en matière de réutilisation d’autant plus grand.

Une bibliothèque de patterns de tests

Sur base d’une analyse des pratiques actuelles, il est vite apparu que la réutilisation stricte de scripts de test était illusoire. Outre les différences de spécifications entre projets, les testeurs disposent de certaines libertés dans la manière de développer leurs tests. Il est cependant apparu que les testeurs présentaient de larges similarités qui gagnaient à être mises en commun. Les connaissances et l’expérience peuvent être partagées entre projets et entre testeurs. La forme pratique utilisée pour capturer et structurer la connaissance s’appuie sur la notion de pattern. Les patterns ont souvent été mis en œuvre avec succès en matière de réutilisation en développement logiciel, notamment pour la programmation orientée-objet (design patterns). En matière de tests, une forme spécifique de patterns a été utilisée : les Questioning Patterns ou QPattern. Les principaux éléments définissant un QPattern sont : l’identifiant, le nom, l’intention (décrivant l’aspect à tester), les questions (permettant de capturer l’information sur l’aspect), les règles (permettant d’identifier des patterns plus fins à invoquer), des tests associés (répartis en plusieurs catégories : nominaux, d’exceptions, …).

Leur mise en œuvre permet d’aboutir à une bibliothèque structurée et outillée des pratiques de tests répondant aux besoins industriels suivants exprimés par STMicroelectronics Belgique.

• Simplicité et efficacité de la structure des patterns.
• Degré de granularité des descriptions adaptable aux pratiques du terrain.
• Facilité d’instanciation et d’évolution de la base de tests.
• Support outillé permettant de générer des plans de tests, d’effectuer des vérifications de complétude, de faire le lien avec la réutilisation des pratiques concrètes, de proposer une génération automatique pour certaines classes de tests.
• Adaptabilité et traçabilité. L’approche ne doit pas être contraignante sur le processus de test lui-même. Le testeur est libre de gérer l’ordre des tests, voire de s’écarter du plan de test tout en assurant la cohérence avec celui-ci.

Mise en œuvre chez STMicroelectronics Belgique

Le processus de développement de la bibliothèque est illustré à la figure suivante. Nous le détaillons sur le cas concret du domaine des cartes à puces.

Figure 1. Aperçu du processus de mise en oeuvre des QPatterns

• La phase d’identification a consisté en l’étude préalable du domaine et de plusieurs projets, une série d’entretiens (environ une demi-journée par testeur) et une consolidation sous forme de workshops.
• La phase de structuration a abouti à une bibliothèque d’une cinquantaine de patterns, structurée selon les aspects fonctionnels et non fonctionnels des applications : validité des commandes, sécurité, atomicité, machines à états… La structuration a été capturée de manière pragmatique sous un format Excel facilement maitrisable.
• La publication se fait via un outil générique permettant de générer une version de la librairie de patterns mise à disposition des testeurs.
• L’instanciation se fait via un outil spécifique. Elle consiste à répondre aux questions proposées de manière libre, en suivant les dépendances. Des données très concrètes, par exemple relatives à des bornes dans le cas de tests aux limites, peuvent également être capturées. Des représentations graphiques, notamment de dépendances entre des fonctions à tester, sont générées et permettent de guider la planification des tests. Cette phase aboutit à la production d’un plan détaillé de test (par défaut au format IEEE-829) dont la génération est automatique. Des fonctions supplémentaires permettent de suivre l’évolution (différences) entre des versions successives et de gérer la traçabilité avec des tests concrets. Notons que l’approche n’a pas pour but d’imposer une approche processus « top-down ». Les testeurs sont maîtres du processus de test lui-même en pouvant s’écarter du plan proposé mais en exigeant un recoupement avec le plan de test proposé (via l’outil de traçabilité). Enfin l’outil supporte également la génération automatique de certaines classes de tests spécifiques, notamment le test des machines à états.
• La phase de commentaires permet de collecter des manquements identifiés dans la bibliothèque (aspect non couvert, nouveau cas de test). Ceci sert fournit l’input qui permet faire évoluer la bibliothèque.

Figure 2. Aperçu de l’outil développé pour l’instanciation de pattern et la génération de plan de tests

Applicabilité à d’autres domaines

La méthodologie développée est largement réutilisable dans d’autres domaines, même moins critiques et structurés.
Outre la meilleure efficacité et l’homogénéité des pratiques, la base de connaissance constituée permet d’accélérer la phase d’apprentissage des nouveaux testeurs et de réduire les risques de pertes de savoir lors du turn-over.
L’outillage développé possède une base générique qui peut évoluer vers du support plus spécifique permettant notamment d’envisager des générateurs spécifiques au domaine pour des classes de tests ayant un caractère systématique et volumineux où la machine est plus efficace que l’humain. Ceci permet à l’intelligence du testeur de se concentrer sur des aspects critiques plus spécifiques de l’application.

Pour en savoir plus

N’hésitez pas à nous contacter si vous désirez en savoir plus en la matière.

Pour en savoir plus sur les pratiques de réutilisation dans le contexte plus large du développement, consultez également le projet NAPLES