Par Eric RIOU du COSQUER*, Trésorier du CFTL (Comité Français des Tests Logiciels), Test Manager Senior chez France Télécom
Quid de la traçabilité ?
De nombreuses définitions existent pour le mot « traçabilité », et pas seulement dans le domaine informatique. La définition issue de l’agro-alimentaire est intéressante : « Traçabilité = Possibilité de retrouver, pour un produit donné, la trace de toutes les étapes de sa fabrication et la provenance de tous ses composants. La traçabilité d’un produit permet, par exemple, de retrouver les fournisseurs des matières premières, les différents endroits où le produit a été entreposé, les manipulations et équipements utilisés dans sa fabrication. ».
Définition intéressante et, si on remplace « matières premières » par « composants » et « entreposé » par « développé et testé », nous ne sommes pas si loin du sens donné dans le monde du développement logiciel !
CMMI-développement par exemple définit la traçabilité comme « une association identifiable entre au moins deux éléments tels que Exigences, Éléments constituant le système, Vérifications ou encore Tâches »
En réalité dans chaque entreprise, et parfois pour chaque projet, il est nécessaire de préciser la définition que l’on donne au mot « traçabilité » avant de réfléchir à sa mise en œuvre.
Quels sont les éléments concernés par la traçabilité ?
Les éléments qui peuvent être liés les uns aux autres sont nombreux, en particulier si l’on couvre tout le cycle, de l’expression des besoins jusqu’aux incidents survenant en production.
Par exemple :
– les besoins exprimés par un client ou une maîtrise d’ouvrage
– les exigences métiers
– les exigences produits
– les éléments d’architecture technique
– les éléments d’architecture fonctionnelle
– le code
– les tests
– les instances de test
– les environnements de test
– les données de test
– les résultats de test
– les anomalies
Cette liste n’est pas exhaustive, loin s’en faut ! Il appartient à chacun de la modifier et de la compléter selon son contexte.
Quels sont les liens utiles et pourquoi ?
Ici encore, les réponses seront différentes selon les entreprises et les projets.
L’essentiel est de se poser la question et d’y répondre. Cela permettra de communiquer efficacement sur le sujet et de convaincre les acteurs concernés de faire l’effort de « tracer ».
Faire un lien de traçabilité a un coût non négligeable. A moins d’être dans un contexte particulier, tel que celui des systèmes à sécurité critique, il n’est pas nécessaire de mettre en place tous les liens de traçabilité possibles mais seulement ceux qui auront une valeur pour le succès du projet. Essayons d’identifier, à partir des éléments listés plus haut, des liens de traçabilité utiles.
Le lien « besoin – exigence métier »
Dans un sens, il va permettre de s’assurer qu’un besoin, souvent formulé « par morceau » sur différents supports (mails, documents, images…) est bien pris en compte dans une ou plusieurs exigences métier, clairement référencée(s)
Dans l’autre sens, il va permettre, lors de la définition ou de la revue des exigences métier, de retrouver ce qui est à l’origine de l’exigence, avec un certain niveau de détail.
Le lien « exigence métier – exigence produit »
Ce lien de traçabilité verticale indique comment le produit à développer va prendre en compte chaque exigence métier. Il permet de ne pas oublier d’exigence métier et également, pour chaque exigence produit, de remonter à sa source. Une exigence métier pouvant impacter plusieurs parties du produit, ce lien pourra être utile pour commencer à évaluer l’impact de changements métier sur la spécification et le développement du produit.
Le lien « exigence produit – éléments d’architecture »
Pour savoir dans quels éléments matériels ou dans quelles briques logicielles, une exigence produit va être implémentée, il est nécessaire d’établir un lien qui permettra de garantir la prise en compte réelle d’une exigence dans le produit. Le lien entre l’humain (textes, dessins…) et le logiciel (architecture) commence à se faire !
Le lien « exigence produit – code »
Quel sera l’impact de la modification d’une exigence produit sur le code ? Quelle exigence produit sera impactée par une erreur présente dans une partie précise du code ? Quel est le volume de code développé pour satisfaire l’exigence ? C’est pour répondre à ces questions que le lien ci-dessus est utile. Il peut être direct ou indirect, en passant par l’intermédiaire des éléments d’architecture.
Le lien « code – tests »
Souvent géré au niveau de l’environnement de développement, ce lien est très important, car il permet non seulement de s’assurer que chaque partie du code est testée, mais aussi d’identifier les tests à rejouer en cas de modification du code et d’automatiser des tests de non régression sur les composants, tout cela de façon automatisée. Ce lien est très présent au niveau « tests de composants ».
Le lien « exigence produit – test »
Dans un premier temps, ce lien qui peut être créé tôt, va permettre de vérifier qu’un test (au moins !) est bien prévu pour l’exigence concernée et, si on se place du côté des tests, de savoir précisément ce qui est testé par chaque test. Les tests étant parfois nombreux et complexes, il n’est pas toujours évident de savoir rapidement ce qui est testé.
Dans un deuxième temps, lorsque les tests commenceront à être exécutés, ce lien permettra de faire remonter des informations issues de l’exécution sur les exigences.
La « famille » de lien « test- instance de test – environnement de test – données de test – résultat de test »
Nombreux sont les liens de traçabilité dans le domaine du test logiciel.
Si on considère qu’un test correspond simplement à un scénario composé d’étapes et de vérifications, alors un même test pourra être exécuté dans différents environnements d’exécution, avec différentes données de test et avec bien sûr différents résultats d’exécution à la clé.
Le concept d’« instance de test » est parfois utilisé. Il nécessite la mise en place de différents liens de traçabilité, car il désigne un test associé à un environnement d’exécution et à des données de tests qui pourra être exécuté plusieurs fois avec des résultats potentiellement différents !
Pour être rigoureux dans la traçabilité autour des tests et dans la documentation associée, il est vivement conseillé de s’appuyer sur la norme IEEE 829 sur la documentation des tests.
Le lien « résultat de test – anomalie »
Ce lien permettra de s’assurer que chaque incident lors de l’exécution d’un test a bien donné lieu à la création d’une anomalie. Utilisé à partir d’une anomalie, il sera doublement utile. Il permettra premièrement à la personne en charge du traitement de l’anomalie de retrouver le détail du test qui l’a mise en évidence et de reproduire l’anomalie facilement. Deuxièmement, une fois l’anomalie corrigée, il permettra à la personne en charge de la vérification de la correction, de vérifier que le test qui avait échoué est maintenant bien passant.
Chaque lien présente en général un
réel intérêt mais lorsque tous ces liens sont mis en place, l’intérêt est décuplé !
Par exemple, une traçabilité « Exigence Métier – Exigence Produit – Test – Instance de Test – Résultat de Test – Anomalies » permettra de connaître à tout instant le status de la couverture de l’exigence par rapport aux tests et de répondre aux questions : a-t-elle été testée ? si oui, quel est le résultat ? si le résultat est négatif, quelle est l’anomalie associée ? …
Comment mettre en place les liens utiles et mesurer la traçabilité ?
Une fois les liens utiles identifiés, il est nécessaire de réfléchir à la façon de les mettre en place. Toutes les phases du cycle de développement logiciel sont touchées, de nombreux éléments sont concernés, plusieurs acteurs interviennent et différents outils informatiques sont concernés (gestion des exigences, gestion et exécution des tests, modélisation, développement, gestion des anomalies…).
Chaque lien peut être mis en place de façon manuelle (références ou liens renseignés manuellement dans des documents ou outils) ou automatique (lien de traçabilité créé à partir de fonctions des outils). Malheureusement, aucune chaîne d’outils ne permet d’implémenter d’emblée tous les liens de traçabilité nécessaires et il est fréquent d’avoir recours à des développements spécifiques. Le plus important est d’expliquer et de documenter la façon de créer ces liens, puis de former les personnes concernées.
Enfin, l’aspect « mesure » entre en jeu et peut être considéré sous deux angles.
La mesure de la traçabilité elle-même : l’objectif est de mesurer le pourcentage de mise en œuvre des différents liens de traçabilité (idéalement 100% !) et de prendre des mesures adéquates si nécessaires. 100% des exigences sont elles associées à au moins un test ? Chaque composant logiciel ou morceau de code est-il associé à une exigence ou à un élément de l’architecture logicielle ?
Le deuxième angle concerne les mesures possibles grâce à la traçabilité qui a été mise en place, par exemple : Quel est le nombre d’anomalies associées aux différentes parties du code ? Quelles sont les exigences produit qui ont été testées entièrement avec succès ? Combien de tests vont devoir être rejoués si telle exigence métier est modifiée ?
La traçabilité peut donc être complexe à définir et à mettre en œuvre. Cela doit se faire projet par projet, en fonction des objectifs et des besoins liés à la qualité. Utilisée à bon escient, la traçabilité devient un outil puissant d’amélioration de la qualité.
* Diplômé de l’Ecole d’Ingénieurs de Brest (Informatique Industrielle), Eric Riou du Cosquer a commencé sa carrière en 2000, en qualité de Chef de Projet au sein des sociétés CSC PeatMarwick, puis Softeam de 2000 à 2003, avant de rejoindre la division R&D de France Télécom, dans le cadre des projets CATI et APSYS. Depuis 2007, Eric exerce en qualité de Consultant et Formateur pour le Centre de Compétences Test de France Télécom (ROSI/DDSI).
Depuis 2002, il a dispensé plusieurs conférences et formations dans le domaine des tests de logiciels. En tant qu’expert, Eric Riou du Cosquer est également membre du groupe de travail international pour la définition du Syllabus Avancé de l’ISTQB, Responsable de la création de la version française et Président du Club utilisateurs de Mercury France.
Il a également participé à la définition et à la mise en œuvre du processus de qualification de FT division R&D, ainsi qu’à l’audit de l’utilisation des outils de gestion de tests et anomalies sur différents projets, côté fournisseurs
