Livrable L1.1: Guide méthodologique de l'industrialisation et référentiel de bonnes pratiques. Version 1

Transcription

1 Emetteur : SDE Date de révision : 07/02/09 Livrable L1.1: Guide méthodologique de l'industrialisation et référentiel de bonnes pratiques APPROBATION DU DOCUMENT Version 1 Nom Date Signature Rédacteur S. Debricon 05/01/09 Vérificateur B. Legeard 07/02/09 Approbateur P.Y. Muhlebach DIFFUSION DU DOCUMENT Liste de diffusion Nom Organisation Pour action Pour information M. Pawlak CTI / DTD P.Y. Muehlbach CLIO B. Legeard Smartesting F. Bouquet UFC / LIFC S. Debricon UFC / LIFC HISTORIQUE DES MODIFICATIONS Référence Date Modifications V /01/09 Création du document 1

2 Table des matières Table des matières... 2 Figures... 4 Tableaux... 3 Introduction Les exigences Des exigences métiers aux exigences de test Définir le concept d exigence Différents types d exigence Traçabilité entre les exigences et les cas de tests Génération des tests et traçabilité des exigences Bonnes pratiques et préconisations Définition de la stratégie de test fonctionnel Positionnement de la stratégie de test Stratégie de test et politique qualité Niveaux stratégiques, tactiques et opérationnels de la stratégie de test Structuration du plan de test Stratégie de test dirigée par les risques Les outils de test logiciel Notion de Processus outillé Pourquoi un processus outillé Un outil pivot : le gestionnaire du référentiel de tests Intégration ou coopération d outils L outillage de test doit s inscrire dans une politique globale de l entreprise Le générateur de tests Principes de la génération de tests Les fonctions d un outil de génération de tests Les générateurs de tests sur le marché Apports de la génération de tests L automate de test L'automatisation des tests sur IHM Les outils d automatisation des tests sur IHM Production du référentiel de tests Techniques de conception de tests Principes du test boîte-noire Test logique / Test physique Techniques basées sur le partitionnement par classe d équivalence Combinaison de valeurs Un cas de test est en général constitué d une séquence d actions et de vérifications sur l application Génération automatique de tests à partir de modèle Principes de la génération de tests Modélisation pour la génération de tests Données de test Génération automatique des tests Publication des tests dans le référentiel Génération des scripts de test

3 En conclusion : Mutation du test fonctionnel - De la planche à dessin à la CAO tridimensionnelle Tableaux Tableau 1-1: Eléments principaux participants à la définition des exigences applicatives Tableau 1-2: Situation vis-à-vis de l expression des exigences et préconisation Tableau 2-1: Tableau croisé des niveaux de risque (d après TMap Next) Tableau 2-2: Croisement des fonctionnalités / objectifs de test avec le niveau risque associé Tableau 4-1: Table de décision

4 Figures Figure 0-1: Le cycle de la qualification fonctionnelle en lien avec les besoins métiers... 7 Figure 0-2: Les outils de l industrialisation de la qualification fonctionnelle... 8 Figure 1-1: Lien entre le référentiel des exigences et le référentiel des tests Figure 1-2: Construction du référentiel des exigences par l expert métier ou à partir de documents de spécifications en Word Figure 1-3: Traçabilité à partir d un référentiel des exigences (source Smartesting) Figure 2-1: Niveaux de la stratégie de test Figure 2-2: Etapes du pilotage du test par les risques Figure 3-1: Schéma du processus outillé de test fonctionnel Figure 3-2: Rôles utilisateur du référentiel de tests Figure 3-3: Interface de HP Quality Center Figure 3-4: Relation entre les artefacts Figure 3-5: Continuité de la chaîne outillée du test fonctionnel Figure 3-6: Exemple de diagramme de classes d un modèle de test d une application de gestion de vols Figure 3-7: Exemple de diagramme d états d un modèle de test d une application de gestion de vols Figure 3-8: Exemple de diagramme d états d un modèle de test d une application de gestion de vols Figure 3-9: Exemple de diagramme d objets d un modèle de test d une application de gestion de vols Figure 4-1: L approche du test boite-noire Figure 4-2: Méta-modèle des cas de tests logique / physique Figure 4-3: Classes d équivalence pour la règle métier «Tarification des ordres de bourse» 41 Figure 4-4: Valeurs aux bornes pour la règle métier «Tarification des ordres de bourse» Figure 4-5: Structure d un cas de test Figure 4-6: Positionnement de la génération de tests Figure 4-7: Intervenants dans la production et l exploitation du référentiel de tests Figure 4-8: Types de diagrammes UML utilisés pour la génération de tests Figure 4-9: ecinema Modèle de test Diagramme de classes Figure 4-10: ecinema Modèle de test Diagramme d énumérations Figure 4-11: ecinema Modèle de test Diagramme d états Figure 4-12: ecinema Modèle de test Définition OCL de l opération «login» Figure 4-13: ecinema Modèle de test Définition des données «utilisateurs» Figure 4-14: ecinema Modèle de test Définition des données «séances disponibles» Figure 4-15: ecinema Modèle de test Définition des données «tickets disponibles» Figure 4-16: ecinema Gestion des données Association entre données logique et données concrètes Figure 4-17: ecinema Génération de tests Interface de Smartesting Test Designer Figure 4-18: ecinema Génération de tests Détail d un test Figure 4-19: ecinema Publication des tests Vue Test Plan de HP Quality Center Figure 4-20: ecinema Modèle de tests Description de l opération «login» au niveau du modèle de test Figure 4-21: ecinema Modèle de tests Script du test «deletealltickets» Les figures utilisées dans ce document sont issues du livre "Industrialiser le test logiciel" 4

5 Introduction Ce document constitue le livrable 1.1 du projet TEST_INDUS. Il s'agit d'un guide méthodologique de l'industrialisation des tests et un référentiel des bonnes pratiques de mise en œuvre. L'objectif de ce document est de fournir un point de départ pour la mise en place d'une stratégie outillée de tests fonctionnels efficace. Certaines parties de ce document sont extraites du livre intitulé "Industrialiser le test fonctionnel", à paraitre chez Dunod. et rédigé par des membres du projet TEST_INDUS (Fabrice Bouquet Université de Franche-Comté, Bruno Legeard Smartesting). L'ensemble des participants du projet TEST_INDUS ont également contribué à la rédaction de ce document. L industrialisation de la qualification fonctionnelle constitue un enjeu essentiel pour la maîtrise de la qualité et des coûts des développements logiciels que ce soit dans le domaine des progiciels de gestion intégrés (customisation, migration) ou pour les applications spécifiques. Les principaux points d appui (les piliers) de cette industrialisation sont maintenant connus et permettent de définir les clés du succès en la matière : 1. Définir un budget pour la qualification fonctionnelle applicative. La qualification fonctionnelle applicative 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 va garantir 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 est toujours une activité difficile. Mais, 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 fiabilité de ces estimations. 2. 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 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érentes 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, 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, formée aux outils et maîtrisant les savoir-faire spécifiques des activités de test. 3. Démarrer les activités de recette dès le début du projet. Une erreur courante consiste à positionner l ensemble des activités de recette fonctionnelle applicative en fin de projet : lorsque le projet est en retard et qu il est urgent de livrer. La bonne solution consiste à commencer la production des tests dès les phases de spécification terminées, voire encore 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 5

6 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 de spécifications, permettant un bénéfice immédiat pour le projet grâce à leur consolidation. 4. Piloter la production des tests à partir des exigences métiers et prenant en compte le niveau de risque applicatif. 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étiers. Ainsi, les tests de qualification fonctionnelle doivent être élaborés à partir des exigences métiers 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étiers. Ces exigences doivent être qualifiées en termes de niveau de criticité pour permettre un pilotage du test par les risques. 5. 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 œuvre), ni le time-to-market (trop long dans sa mise en œuvre lors des tests de non régression), ni la maîtrise des coûts (trop cher du fait de la répétition). A partir de 3 ou 4 livraisons prévues de l application, et donc 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 maitrisé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 œuvre 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. 6. 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 mettre en place les indicateurs et leur suivi qui permettent 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 indicateurs de qualité mais aussi participent à la maitrise des schémas de sous-traitance. La qualification fonctionnelle peut ainsi être vue comme partie intégrante du système d information de la gouvernance des applications informatiques. 7. 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 tests et des premières exploitations terrain. Il s agit de procéder à la mise en place d un processus continu de qualification. Les équipes qui ont pris en charge 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 6

7 exigences fonctionnelles, mais aussi faire le lien entre le référentiel de test et les retours du terrain. Ces sept piliers de la sagesse pour les activités de recette fonctionnelle sont au cœur des démarches réussies en matière d assurance de la qualité du logiciel. Ils correspondent aux enjeux clés des organisations IT amenées à gérer l aversion des bugs des utilisateurs, la complexité croissante des applicatifs et la globalisation des démarches de développement. Nous proposons de capturer ces éléments clés dans le processus outillé présenté dans cette partie : depuis l expression des exigences fonctionnelles jusqu'à la mise en œuvre des tests automatisés et le suivi des indicateurs de qualité. La Figure 0-1 fournis un schéma de la qualification fonctionnelle et de sa relation avec les besoins métiers. Figure 0-1: Le cycle de la qualification fonctionnelle en lien avec les besoins métiers Ce schéma montre plusieurs aspects importants du processus de la qualification fonctionnelle tel que proposé dans ce livre : Les besoins métiers constituent le point d entrée de la qualification. Leur qualité est cruciale pour tout le processus ; nous présentons en chapitre 1 les bonnes pratiques pour développer des spécifications et exigences fonctionnelles exploitables pour la phase de qualification. Le cycle de qualification est en lui-même un processus itératif et incrémental. Les étapes de production des tests, d exécution des tests et d analyse/suivi des anomalies s enchainent au fil 7

8 des différentes phases de tests successives et jusqu'à l obtention de la couverture et du niveau de qualité requis. La gestion de la production des tests dirigée par les exigences fonctionnelles garantit un bon suivi et une terminaison claire du processus. Ce processus s appuie sur une chaine d outils, tel que montré par la Figure 0-2. Figure 0-2: Les outils de l industrialisation de la qualification fonctionnelle Les outils standards du cycle de qualification fonctionnelle sont de cinq ordres : La gestion des exigences fonctionnelles une bonne définition des exigences est essentielle pour la qualification; La génération des tests la génération automatique de tests permet de réduire les coûts de production et de maintenance du référentiel de tests ; La gestion du référentiel de tests, des campagnes de test et des anomalies il s agit d un outil clé de l industrialisation des tests qui permet une bonne gestion du référentiel de tests et des résultats associés à l exécution; L automatisation de l exécution des tests permet de gérer correctement les risques liés aux régressions fonctionnelles lors des corrections d anomalies et des évolutions. La gestion des données de test et la production des bases de recette constituent un élément important de la phase de qualification. Ces outils s appuient aussi sur une infrastructure qui permet l accès à l application et les services de base du poste de travail. Ce processus outillé doit être au service d une stratégie de test qui constitue le schéma directeur du processus de test. La suite de ce livrable s'organise de la façon suivante: Le chapitre 1 traite de la liaison entre les référentiels d exigences fonctionnelles associés à un projet applicatif, et le référentiel de tests qui vise à assurer la conformité de l application à ses spécifications. Il s agit aussi de préciser les concepts principaux de la gestion des exigences, de leur structuration, de leur traçabilité vers les tests, ainsi que de lister des bonnes pratiques de formalisation des exigences dans une perspective de test. 8

9 Le chapitre 2 aborde la définition de la stratégie de test pour un projet donné. La stratégie de test s inscrit dans la politique qualité globale définie pour l application et s incarne au travers d un Plan de test. Nous proposons un sommaire type pour le plan de test, puis développons une approche dirigée par les risques, c'est-à-dire permettant de gérer les efforts de test fonctionnel en fonction des risques identifiés au sein de l application sous test. Le chapitre 3 présente une vision globale du processus outillé, puis détaille chaque catégorie d outil utilisée dans cette chaîne. Il fait également référence au livrable 4.2 du projet. Le chapitre 4 introduit les méthodes et techniques de construction du référentiel de tests fonctionnels. Nous présentons d'abord les concepts principaux de la conception de tests fonctionnels. Nous décrivons ensuite la démarche de génération de tests à partir d un modèle de tests. 9

10 1 Les exigences 1.1 Des exigences métiers aux exigences de test Définir le concept d exigence La notion d exigence provient en fait d une traduction du mot «Requirements» issu du vocabulaire anglo-saxon dans le domaine. Ce mot «Requirements» est définit par Sommerville et Sawyer [Somm1997] «comme l expression de ce qui doit être implémenté dans l application considérée. Il s agit d une description du comportement attendu de l application, de ses propriétés et attributs, ou des contraintes qu elle doit respecter. Cela peut aussi recouvrir le processus de développement applicatif.». La terminologie française dans le domaine utilise le mot «spécifications» pour traduire ce même concept. Dans le vocabulaire utilisé dans ce document, «exigences» et «spécifications» seront donc considérés comme identique. L intérêt d utiliser le mot «exigence» est de mettre l accent sur le caractère atomique de l élément de spécification considéré, et donc permettant une traçabilité au sein du processus de développement, en particulier vis-à-vis des tests Différents types d exigence Comme le montre la définition de Sommerville et Sawyer, la notion d exigence recouvre un ensemble varié d informations décrivant ce que nous devrons obtenir à l issue du développement applicatif. Par exemple la «description du comportement attendu de l application» correspond aux exigences fonctionnelles, alors que «les contraintes que doit respecter l application» correspond à des exigences non-fonctionnelles (par exemple de qualité, de performance, ). D autres types d exigences peuvent recouvrir des propriétés nécessaires de l application, par exemple des propriétés de sécurité (contrôle d accès, authentification, confidentialité, intégrité). Enfin, les choix technologiques de la plate-forme de développement, d interopérabilité ou de support de certains systèmes d exploitation ou de l explorateur Internet, constituent un autre type d exigence. Cet ensemble d informations est listé dans le Tableau 1-1. Nature Type Description Fonctionnel Cas d utilisation Les cas d'utilisation sont utilisés pour représenter les différentes interactions entre un utilisateur (humain ou machine) et un système au travers de différents scénarios. Ils peuvent être représentés sous la forme de Diagramme de Cas d Utilisation en UML. Fonctionnel et non-fonctionnel Règles métiers (ou règles de gestion) Les règles métiers définissent des exigences comportementales, des standards métiers ou des règles internes à l entreprise que doit respecter l application. Ces règles constituent des éléments clés de la traçabilité du référentiel de test vers le référentiel des exigences. Non-Fonctionnel Critères qualité Les critères qualité expriment des contraintes sur l application en termes d utilisabilité, de performances, de disponibilité, de maturité et 10

11 Non-fonctionnel Exigences d interface de portabilité en particulier. Ces critères sont en général hors du champ du test fonctionnel. Ce type d exigences recouvrent d une part les exigences de type Interface Homme /Machine, et l ensemble des interfaces avec les systèmes tiers. Tableau 1-1: Eléments principaux participants à la définition des exigences applicatives Dans ce document, nous nous intéressons plus particulièrement aux exigences fonctionnelles, c'est-à-dire aux cas d utilisation et aux règles de gestion, pour lesquels le test fonctionnel devra assurer que l application à tester est conforme. Le référentiel de tests devra donc assurer la couverture de ces exigences, et montrer que chaque exigence est testée suivant une stratégie de test définie au préalable. 1.2 Traçabilité entre les exigences et les cas de tests Les exigences fonctionnelles, les cas d utilisation, les règles métiers, et d une manière générale l ensemble des éléments de description fonctionnelle de l application sous test, constituent le point de départ du processus de production du référentiel de tests. Figure 1-1: Lien entre le référentiel des exigences et le référentiel des tests Comme le montre la Figure 1-1, les relations entre les référentiels des exigences et le référentiel des tests sont d une part la production des tests, et d autre part la traçabilité bidirectionnelle 1 des exigences. Dans cette vision, le référentiel des exigences fonctionnelles est considéré comme préexistant au démarrage du projet de test. Ce référentiel des exigences fonctionnelles (appelé aussi référentiel métier) est sous la responsabilité des experts métiers (business analyst par exemple), de la même façon que le référentiel des tests est sous la responsabilité des architectes de test. Autant le référentiel des tests possède une structure bien définie, gérée en général par des outils de gestion des tests tels que HP Quality Center ou IBM Rational Quality Manager, autant le référentiel des exigences fonctionnelles prend dans la pratique des applications IT de formes très variées. Les quatre situations différentes de formalisation du référentiel des exigences qui peuvent être rencontrées sont les suivantes: 1 On appelle «Traçabilité bidirectionnelle» la capacité à suivre le lien entre deux artefacts du processus de développement logiciel en relation l un avec l autre. Dans notre cas, cela concerne la gestion du double lien : exigences vers tests et tests vers exigences. 11

12 Situation 1 - L absence totale de référentiel des exigences fonctionnelles sans aucune spécification, le référentiel métier est incarné dans ce cas directement et uniquement par l expert métier. C est évidement une situation qui rend difficile la traçabilité bidirectionnelle, et qui conduit à introduire des éléments de formalisation d exigences (voir cas suivants) si l on souhaite réaliser cette traçabilité. Situation 2 - Le référentiel fonctionnel est constitué de documents et matériels disparates c est une situation très courante en pratique sur les projets IT actuels, où coexistent différents matériels tels que des spécifications fonctionnelles générales et détaillées, des cas d utilisation, des exigences fonctionnelles non formalisées et éventuellement la description de processus métiers. Ce matériel constitue le point de départ du processus de production du référentiel des tests, et la traçabilité des exigences vers les cas de test est réalisée à partir d éléments référençables extraits de cet ensemble. Dans ce cas, nous préconisons un travail préliminaire à la production des tests, qui consiste à extraire de manière atomique les exigences à tester puis les faire valider par le métier. Les outils de gestion des référentiels de tests (voir chapitre 3) permettent pour la plupart cette étape. Les ambiguïtés de spécifications alors découvertes sont levées par l expert métier qui précise et actualise le référentiel fonctionnel. Situation 3 - Les exigences fonctionnelles sont explicitées, sans être gérées par un outil spécialisé - dans cette situation, un effort de formalisation des exigences fonctionnelles applicatives a été réalisé, permettant leur traçabilité bidirectionnelle avec les cas de tests, et en particulier leur référencement au sein du référentiel des tests. Le support de ce référentiel est typiquement sous forme de tableaux (type Excel) accompagné de documents textuels. L inconvénient principal de ce niveau de gestion provient du caractère manuel du suivi du changement pour ces exigences. Situation 4 Les exigences fonctionnelles sont explicitées et gérées dans un outil de gestion d exigences spécialisé dans cette situation, l effort de formalisation des exigences est supporté par des outils spécialisés, tels que Borland CaliberRM, IBM RequisitePro, Serena Dimension RM, Compuware Optimal Trace,. Ces outils facilitent le référencement des exigences et la gestion de leur évolution dans le temps et ils comportent en général des passerelles natives permettant d exporter un extrait des exigences métiers (les exigences à tester) vers les référentiels de tests. En termes de traçabilité des exigences, les situations 1 et 2 ne permettent pas la traçabilité, du fait de l absence du référentiel des exigences (situation 1), ou parce que son niveau de formalisation empêche un référencement explicite (absence d identifiants d exigences ou de garantie d unicité situation 2). Dans ce cas, pour permettre la traçabilité entre les exigences et les tests, il faudra se mettre en situation 3 ou 4, c'est-à-dire avec des exigences explicitées. Cela peut être réalisé par exemple en produisant un référentiel des exigences pour le test. C est ce que montre la Figure 1-2 avec une production du référentiel dans un tableau Excel. 12

13 Figure 1-2: Construction du référentiel des exigences par l expert métier ou à partir de documents de spécifications en Word Dans le cas des situations 3 et 4, c'est-à-dire à partir du moment où les exigences sont explicitement formalisées, la traçabilité est possible. Cependant, chaque évolution d exigences impose une mise à jour manuelle du référentiel. C est là un travail lourd et fastidieux et, en pratique, on constate souvent une désynchronisation de la matrice de traçabilité avec le référentiel des tests. Le support apporté par le processus outillé décrit dans cet ouvrage, et par la génération automatique des cas de test à partir d un modèle de test, permet d automatiser la gestion de la traçabilité bidirectionnelle entre les exigences et les tests. Cette automatisation garantit que la couverture des exigences par les tests soit à jour en permanence, et devient un outil de suivi de production et de certification applicative Génération des tests et traçabilité des exigences La génération de tests permet d automatiser la gestion de la traçabilité entre les exigences et les tests. Comme le présente la Figure 1-3, ce processus est réalisé en trois étapes : L expert métier en charge du référentiel des exigences publie, dans le gestionnaire des tests, les exigences fonctionnelles à tester dans le cadre du projet action ; L architecte de test développe le modèle de test en fonction des exigences à tester et produit avec le générateur des tests couvrant ces exigences action ; La fonction de publication du générateur de tests permet la publication automatique des tests générés (action a) et du lien de traçabilité (action b) dans le gestionnaire de test. 13

14 Figure 1-3: Traçabilité à partir d un référentiel des exigences (source Smartesting) Ce processus est itératif. C'est-à-dire que chaque évolution des besoins conduit à mettre à jour le référentiel des exigences et à le republier (action de l expert métier) et à mettre à jour le modèle de test, à générer et republier avec le générateur de tests (action de l architecte de test). La génération automatique des tests et leur publication dans le gestionnaire de test permet une prise en charge complète de la gestion de la traçabilité bidirectionnelle des exigences avec les tests au sein du gestionnaire de test. À tout moment, cela garantit la fiabilité du suivi de la couverture des exigences par les tests. Un autre intérêt de cette approche concerne la gestion du changement et la réduction du coût de maintenance. En effet, lorsqu une exigence est modifiée, l architecte de test répercute unitairement ce changement dans le modèle et utilise le générateur de tests pour propager tous les impacts dans tous les tests Bonnes pratiques et préconisations Les bonnes pratiques de développement et de gestion des exigences font parties des pratiques à plus forte valeur ajoutée du modèle CMMI [Chris2003], qui recommandent les éléments suivants en termes de gestion des exigences : 1. Comprendre ces exigences 2. Obtenir un engagement sur ces exigences (client, équipe projet, autre intervenant,..) 3. Gérer les changements d exigences 4. Maintenir une traçabilité bidirectionnelle entre les exigences et les changements associés et les produits d activité (tests entre autres) 5. Identifier les incohérences entre les exigences et les plans et produits d activité La pratique 4 se révèle souvent une des plus difficiles à mettre en œuvre si on ne peut s appuyer sur un processus outillé de bout-en-bout qui va alors faciliter cette tâche. 14

15 Rentrons plus dans le détail dans la recherche d amélioration de la gestion des exigences, par l approche inspirée de CMMI, mais plus appliquée, proposée dans le RMM (Requirement Management Maturity) 2. Celle-ci décrit en cinq niveaux de maturité un modèle relatif à la gestion des exigences qui sont : (1) écrit, (2) organisé, (3) structuré, (4) tracé, et (5) intégré (L atteinte du niveau 5 de RMM assure normalement l organisation IT d être au minima au niveau 3 du modèle CMMI). On peut y noter les différents points suivant : Niveau 1 (Exigences «Ecrites») : L un des bénéfices est la possibilité pour le testeur de commencer très tôt l écriture de ses cas de tests sur lesquels il peut ensuite baser ses procédures et scripts de tests. Niveau 2 (Exigences «Organisés») : Les exigences doivent être non seulement lisibles mais aussi non-ambigües et testables. Niveau 4 (Exigences «Tracées») : La traçabilité fournit la capacité de comprendre comment les exigences interagissent (Analyse d impact) et détermine leur complétude (Matrice de couverture). L effort et par conséquent le coût pour la mise en œuvre et la maintenance en est tout sauf trivial. Niveau 5 (Exigences «Intégrées») : Les tests basés sur les exigences (Requirement Based Testing) est l un des principes à respecter pour vérifier que le logiciel atteint ses objectifs. De plus, la capacité pour le chef de projets d accéder au statut du projet en lien avec les exigences est prépondérante avec bien évidement les métriques tests rattachées à chacune d elles. Nous avons mentionné précédemment et détaillé les différentes situations rencontrées au sein des organisations IT concernant leur maturité sur les exigences. Le Tableau 1-2 propose des préconisations pour mettre en œuvre la traçabilité des exigences avec en fonction de ces situations le reflet du niveau effectif atteint en termes de gestion des exigences. 2 Voir l article de Jim Heumann IBM/Rational Maturity_TheRationalEdge_Feb2003.pdf 15

16 Situation 1 - Absence totale de référentiel des exigences fonctionnelles 2 - Le référentiel fonctionnel est constitué de documents et matériels disparates 3 - Les exigences fonctionnelles sont explicitées, sans être gérées par un outil spécialisé 4 Les exigences fonctionnelles sont explicitées et gérées dans un outil de gestion d exigences spécialisé Bonnes pratiques Pour assurer la mesure de couverture fonctionnelle, une première étape consiste à définir, fonction par fonction, des exigences de test. L idée est d arriver au minimum au niveau de la situation n 3, c'est-à-dire d identifier et de stocker ces exigences dans un référentiel sous un tableau au format Excel par exemple. Ce tableau sera ensuite publié dans l outil de gestion des tests. De nouveau, l idée est de se mettre au minimum au niveau de la situation n 3. Les documents de spécifications doivent permettre de définir des exigences de tests qui seront saisies dans un référentiel sous la forme d un tableau Excel par exemple. Ce tableau sera ensuite publié dans l outil de gestion des tests. Les exigences formalisées, par exemple dans Excel, peuvent être importées dans l outil de gestion de test pour permettre la traçabilité. Ce cycle de publication doit être assuré à chaque mise à jour des exigences. Un extrait des exigences (les exigences à couvrir par les tests fonctionnels) sera publié dans le gestionnaire des tests (les outils de gestion des exigences possèdent en général cette fonction). La mise à jour sera assurée par re-publication à chaque évolution des exigences fonctionnelles. Tableau 1-2: Situation vis-à-vis de l expression des exigences et préconisation En conclusion, quelque soit votre niveau de maturité de gestion des exigences, la première démarche, si vous souhaitez démarrer votre industrialisation, est de structurer vos exigences dans un même référentiel. Ce référentiel peut être celui associé au référentiel de tests, ou à un référentiel spécialisé. Cela vous permettra non seulement de centraliser l information (B.A.- BA de l amélioration) mais aussi de mettre en œuvre une relation de traçabilité entre votre référentiel d exigence et votre référentiel de test. 16

17 2 Définition de la stratégie de test fonctionnel 2.1 Positionnement de la stratégie de test Stratégie de test et politique qualité La stratégie de test doit s inscrire dans la politique qualité de l entreprise et du projet considéré. Le test n est pas le seul moyen de l assurance qualité, mais participe d un ensemble de méthodes et processus qui concourent à la qualité de l application, tant au niveau de l expression de besoins que du développement et de la mise en exploitation. La norme IEEE Standard for Software Quality Assurance Plans [IEEE ] propose un contenu type pour le plan qualité logiciel. Ce document décrit les dispositions spécifiques pour un projet prises pour obtenir la qualité du logiciel considéré, et s inscrivant dans la politique globale du maitre d ouvrage en matière qualité. Le plan d assurance qualité définit les priorités en termes de facteurs, de caractéristiques et sous-caractéristiques et de métriques de la qualité applicables pour le projet de test concerné. Ces caractéristiques sont normalisées au sein du standard ISO 9126 [ISO-9126]. Les caractéristiques de qualité correspondent aux catégories suivantes : Capacité fonctionnelle : Est-ce que le logiciel répond aux besoins fonctionnels exprimés? Fiabilité : Est-ce que le logiciel maintient son niveau de service dans des conditions précises et pendant une période déterminée? Facilité d utilisation : Est-ce que le logiciel requiert peu d effort à l utilisation? Rendement : Est-ce que le logiciel requiert un dimensionnement rentable et proportionné à la plate-forme d hébergement en regard des autres exigences? Maintenabilité : Est-ce que le logiciel requiert peu d effort à son évolution par rapport aux nouveaux besoins? Portabilité : Est-ce que le logiciel peut être transféré d une plate-forme ou d un environnement à un autre? Le test fonctionnel visera en premier lieu la capacité fonctionnelle, en particulier au travers du respect des exigences de type cas d utilisation et règles métiers, mais la fiabilité sera aussi couverte. Le plan qualité logiciel couvre aussi les moyens de la qualité tant en termes de processus de développement, de méthodologies mises en œuvre que d outil d ingénierie logiciel utilisé. C est donc ce plan qualité qui donne le cadre au sein duquel s instancie la stratégie de test de l application. Enfin, le plan qualité définit le suivi de la mise en œuvre de l assurance qualité et la gestion des risques devant être appliquée tout au long du projet. De ce point de vue, les résultats des campagnes de test permettront d alimenter ce suivi, et de mettre en évidence les dérives éventuelles par rapport aux objectifs de qualité. En cela, le test tient un rôle central dans la politique d assurance qualité Niveaux stratégiques, tactiques et opérationnels de la stratégie de test La stratégie de test peut être vue de façon hiérarchique comme le montre la Figure 2-1 : Le plan de test définit le niveau stratégique : il caractérise la politique de test applicative et définit les aspects méthodologiques ; Le référentiel de tests implémente cette stratégie et constitue le niveau tactique de définition des tests à exécuter ; 17

18 L infrastructure et l outillage de test constitue le niveau opérationnel, permettant de supporter la stratégie et de mettre en œuvre de façon opérationnelle le référentiel de tests. Figure 2-1: Niveaux de la stratégie de test Les éléments clés de la définition de la stratégie de test sont les suivants : Sa définition doit impliquer tous les acteurs de la chaîne de validation La stratégie de test concerne les différents acteurs de la chaîne de validation : les analystes qui participent à la définition des exigences fonctionnelles de l application, les gestionnaires du produit logiciel qui sont concernés de façon directe par la qualité du logiciel produit, les chefs de projets et bien sur l équipe de test et validation qui mettra en œuvre cette stratégie. La stratégie de test n est pas statique Il faut voir la stratégie de test comme un élément dynamique de la construction et de la maintenance du logiciel. En fonction des retours terrains et des évolutions prévues dans la vie de l application, il faut faire évoluer la stratégie de test. La stratégie de test doit être réaliste et réalisable avec le budget Il est clair que définir des objectifs ambitieux en termes de couverture de test par exemple ou d automatisation, sans en avoir les moyens rend la stratégie de test inopérante en pratique. La stratégie de test doit intégrer les éléments de mesure et de contrôle des objectifs Les indicateurs d atteignabilité des objectifs doivent être explicitement définis de façon à permettre un suivi des résultats de la stratégie de test mise en œuvre Structuration du plan de test La documentation du test fait l objet de la norme IEEE 829 [IEEE ]. Cette norme recouvre le plan de test et les documents complémentaires tels que la spécification des cas de test, la structuration des rapports d exécution des tests et d anomalies, ainsi que la synthèse des activités de test. Cette documentation est conçue pour les différents niveaux de test mais est particulièrement adaptée pour les tests fonctionnels de niveau test système. La structure du plan de test proposée par la norme IEEE 829 est la suivante : Sommaire du Plan de test 1. Introduction a. Objet : Courte description des objectifs du plan de test. 18

19 b. Définition : Définition des termes et des acronymes utilisés dans le document. 2. Références Énumérer les références à d'autres documents appropriés. Normes & Standards Plan de projet et plan d assurance qualité Cahier des charges Documents d'analyse Documents de conception 3. Périmètre couvert par le plan de test Énumérer les éléments à tester (composants, produits, classe, module,...). Ainsi que la version du composant et autres informations techniques. 4. Propriétés testées Énumérer les propriétés testées par ce plan, d un point de vue Utilisateur. Mentionner le risque sur le produit en cas d échec. (élevé, médium, faible) Mentionner le risque potentiel de découvrir des défectuosités (élevé, aucun). 5. Exigences non couvertes par le plan de test Énumérer les propriétés qui ne sont pas testées par ce plan d un point de vue Utilisateur et expliquer les raisons. 6. Processus et stratégie de test Décrire les activités, techniques et outils qui seront utilisés pour les tests avec suffisamment de détail pour permettre l'estimation des ressources et du temps nécessaires. Cette section définit aussi la stratégie globale en termes de priorité de test. 7. Critères d'acceptation des tests Définir les critères de passage et d'échec des éléments testés. 8. Critères d arrêt des tests Décrire les circonstances où l exécution des essais est interrompue et les conditions pour continuer. 9. Identification des documents livrables Énumérer et définir les livrables qui doivent être élaborés durant les tests. Référentiel de tests Rapport d'exécution: verdict de chacun des cas de test lors de l'exécution Rapports des anomalies: Description et suivi des anomalies découvertes lors de l'exécution des tests. Rapport sommaire: Sommaire des activités et résultats des tests. 10. Gestion des anomalies Décrire comment rapporter, suivre et résoudre les anomalies détectées. 11. Définition des activités de test Description des différentes activités réalisées lors des phases de test 12. Outillage et infrastructure de test Définition des outils et de l infrastructure de test (environnement de test, base de recette, moyens matériels et réseau) 13. Responsabilité Niveaux de responsabilité lors de phases de test (répartition en Client, Développement et Equipe de test) 14. Equipe de test Définition de l équipe de test, et des compétences et du plan de formation nécessaire 15. Planning prévisionnel Planning prévisionnel global des phases de test incluant les principaux jalons. 19

20 16. Gestion des risques Risques identifiés et gestion prévisionnelle Dans le cas de projets complexes, la formalisation du plan de test est réalisée à plusieurs niveaux : définition d une politique globale pour le projet (par exemple en suivant le standard IEEE 1012 Verification and validation plan [IEEE ], accompagné de plan de test spécifiques par niveau de test. A noter que dans certaines méthodologies structurées de test, telle que TMap Next [TMap2006] de la société Sogeti, ce document de politique globale de vérification et validation est appelé «Test Master Plan» et vise à expliciter de façon globale la politique de test, l organisation de test, les environnements de test, les outils de test et les équipes de test. Ce plan de test maître est dérivé ensuite en plans de test par niveau de test. Couramment la stratégie de test peut faire l objet d un document à part du plan de test, qui sera validé en amont du plan de test. De la même manière les projets complexes comporteront une stratégie de tests globale et des stratégies de tests par phase de tests. 2.2 Stratégie de test dirigée par les risques L aphorisme célèbre du Professeur Edsger W. Dijkstra, en 1970: «Program testing can be used to show the presence of bugs, but never to show their absence!», est bien sur toujours valide 40 ans après. Le test de logiciel ne permet qu une vérification partielle de l application testée, et l explosion combinatoire inhérente à l activité même du test nécessite d appliquer des stratégies de sélection des cas de test et de la couverture fonctionnelle pour maîtriser le triptyque Qualité/Délai/Coût. Cette stratégie de sélection gagne à être dirigée par les risques pour maitriser au mieux l impact des anomalies et/ou défaillances applicatives en termes de coûts induits sur l activité associée à l application. En effet, quel serait l intérêt d une activité de test sur une application pour laquelle l impact d une quelconque défaillance serait nul. A l inverse, les systèmes critiques, qui mettent en jeu la vie humaine, s appuie sur des techniques de test qui garantissent un niveau élevé de couverture de code dépendant du niveau de criticité (cf. la norme DO-178B [DO178B-1992]). Le risque peut être analysé comme une fonction à deux composantes : la probabilité d occurrence d un événement indésirable et l impact de la défaillance en termes de coûts induits. La probabilité d occurrence d un événement sur une application logiciel dépend en général de la fréquence d utilisation de la fonction concernée par l événement, plus cette fonction est utilisée plus il est probable que l événement redouté se produise. Ce sont donc ces deux aspects, à la fois la probabilité d occurrence et les dommages induits, qui seront analysés dans l objectif de définir des niveaux de priorités et de sensibilité permettant de piloter la construction du référentiel de tests. La méthode TMAP Next, déjà mentionnée précédemment, fournit une approche structurée dite Analyse de Risque Produit pour l identification des risques à prendre en compte lors de l élaboration du plan de test et de la construction du référentiel de tests. La Figure 2-2: Etapes du pilotage du test par les risques s inspire du processus TMap et permet d illustrer la démarche de pilotage du test par les risques. L identification des risques sera réalisée à partir des différents éléments analytique de l application sous test : cas d utilisation, processus métiers, exigences, règles de gestion, 20

21 caractéristiques qualité, mais aussi à partir de sa décomposition en sous-systèmes et composants, qui peuvent porter chacun un niveau de risque, et impliquer un niveau de test. Figure 2-2: Etapes du pilotage du test par les risques La Figure 2-2 montre que le Client (la maîtrise d ouvrage) de l applicatif doit être au centre du pilotage de la politique de test par les risques. Les défaillances de l application peuvent être différentes suivant les types d utilisateur. Il s agit donc, lors de l analyse de risque, d identifier les services de l application utilisée par chaque type d utilisateur de façon à en tenir compte lors de la détermination des classes de risques par objectifs de test. La définition des classes de risques dépend de la nature de l application testée. Dans le cas des systèmes critiques aéronautiques, la norme DO-178B, déjà citée, en prévoit cinq : Niveau A : Problème catastrophique - Sécurité du vol ou atterrissage compromis - Crash de l'avion Niveau B : Problème majeur entraînant des dégâts sérieux, mettant en jeu la vie humaine Niveau C : Problème sérieux entraînant un dysfonctionnement des équipements vitaux de l'appareil Niveau D : Problème pouvant perturber la sécurité du vol Niveau E : Problème sans effet sur la sécurité du vol. 21

22 Dans le cas des systèmes d information, que cela soit des applications de type Progiciel métiers ou des applications spécifiques, trois niveaux de risques sont en général utilisés pour l analyse : A- Risque élevé, B Risque Moyen et C Risque Faible. Ces classes de risques sont associées à une matrice de risque absolue [Broek2002] qui croise la probabilité d occurrence d un événement avec l impact en cas de défaillance (cf. Tableau 2-1). Dommage en cas de défaillance Probabilité de défaillance Elevée Moyenne Faible Elevé A B B Moyen B B C Faible C C C Tableau 2-1: Tableau croisé des niveaux de risque (d après TMap Next) La détermination des classes de risques pour les différents objectifs de test peut être synthétisée dans un tableau qui croise les sous-systèmes (ou fonctionnalités) et les cas d utilisation ou exigences fonctionnelles avec un niveau de criticité, comme le montre le Tableau 2-2. Fonctionnalité Objet de test Niveau de risque Argumentaire Fonction # 1 Exigence 1 A.. Fonction # 2 Exigence 2 C.. Cas d utilisation 1. A Tableau 2-2: Croisement des fonctionnalités / objectifs de test avec le niveau risque associé. La synthèse de l analyse de risque est exploitée de façon directe lors du processus de production du référentiel de test, pour appliquer différentes stratégies de tests et de couvertures en fonction du classement associé à l objectif de test. 22

23 3 Les outils de test logiciel 3.1 Notion de Processus outillé Pourquoi un processus outillé Le test de logiciel a été historiquement une activité peu structurée, s appuyant sur des processus manuels peu reproductibles et donnant des résultats mitigés, tant en termes de détections d anomalies, que de maîtrise des coûts et des délais. Cette situation évolue rapidement depuis une dizaine d année sous la contrainte des impératifs budgétaires (une anomalie découverte en phase de production coûte souvent cher à corriger), de délais (tester le plus tôt possible) et de qualité. Le test fonctionnel joue ainsi un rôle central par rapport aux problématiques réglementaires (type loi Sarbanes-Oxley ou Normes Bale II) et dans la maitrise des risques liés à la globalisation des développements. La mise en place d un processus outillé, depuis l expression des exigences jusqu'à la mise en œuvre d un référentiel de tests automatisés permet d assurer à la fois la reproductibilité des activités de test, de mesurer leur qualité et de mieux maîtriser leurs coûts. Une activité centrale, telle que la traçabilité bidirectionnelle entre les exigences métiers et les cas de tests, est très difficile à réaliser et surtout à maintenir manuellement lorsque les exigences et l application à tester évoluent (ce qui constitue le cas usuel d une application informatique). Le processus outillé va donc permettre de structurer les activités de test et d automatiser nombres de tâches fastidieuses, garantissant une meilleure pérennité dans le temps du patrimoine de test. Il faut cependant noter que les outils en eux-mêmes ne constituent pas une méthodologie, et qu il faudra systématiquement les mettre en œuvre dans le cadre d une démarche structurée telle que proposée par les guides de bonnes pratiques de l ISTQB International Software Testing Qualification Board représenté en France par le Centre Français du Test Logiciel [Spill2007], ou la méthode TMap Next déjà citée. Il faut aussi prendre conscience que la mise en œuvre d un processus outillé va requérir des compétences spécialisées, correspondant à la professionnalisation des métiers du test logiciel. 23