FR 2884339 A1 20061013 FR 0503466 A 20050407 -1/31- 1. Description de la méthode La présente invention concerne une méthode de conception et de réalisation des tests de logiciels. Les logiciels (programmes informatiques) présentent aujourd'hui de nombreux défauts (bugs) qui n'ont pas été détectés avant la mise sur le marché de ces produits. La plupart des fournisseurs de logiciels mettent en place une démarche de validation de leurs produits mais cette démarche reste souvent insuffisante dans la mesure où elle n'est pas formalisée et que l'organisation nécessaire aux tests n'est pas mise en place de manière permanente. La méthode selon l'invention présente les résultats d'une étude menée auprès de 18 entreprises qui permet de mieux appréhender les difficultés rencontrées par les entreprises dans le domaine des tests des logiciels. Elle recense ensuite les éléments indispensables à la mise en place de tests efficaces: les différents types de tests possibles (typologie des tests), les étapes à accomplir dans le processus de test des logiciels, un glossaire définissant les termes utilisés dans la démarche de test des logiciels, des règles de nommage s'appliquant aux fichiers manipulés durant les test, un modèle de fiche de test, un modèle de scénario de test et la description d'un outil de génération des fiches de tests. 1.1. Etude des tests de logiciels en entreprise Cette étude avait pour but de recueillir des éléments concernant l'état actuel des tests de logiciels dans les entreprises françaises. Elle a servi de base à la conception de la méthode. 1.1.1. La base de l'étude 1.1.1.1. Les sociétés contactées 111 sociétés ont été contactées dans le cadre de cette étude; elles sont réparties de la manière suivante: Contactés Participants Pourcentage Editeurs 100 13 13% Utilisateurs 11 5 46% Total 111 18 17% -2/31-Certaines sociétés qui ont refusé de participer à l'étude ont motivé leur refus par les raisons suivantes: - Les processus de test sont des sujets sensibles et confidentiels. Certaines sociétés se réfèrent à la norme ISO 9000 pour justifier cette confidentialité. - Les Processus de test ne sont pas assez structurés pour les mettre en visibilité à l'extérieur de la société. 1.1.1.2. Les sociétés qui ont participé à l'étude - Nombre total de sociétés interrogées: 18 É Mode d'interview des sociétés: Questionnaire Entretien Total Editeurs 5 8 13 Utilisateurs 2 3 5 Total 7 11 18 Typologie des sociétés interrogées en fonction de leur âge et de leur nombre de 15 salariés. Nb: Pour faciliter les comparaisons, le nombre de salariés retenu pour les sociétés utilisatrices correspond au nombre de salariés du département Informatique. 1.1.2. Les Enjeux des tests pour les entreprises interrogées 1.1.2. 1. Le produit - Un produit maîtrisé qui tend vers le zéro bug É Livrer aux utilisateurs un produit qui fonctionne É Eviter les bugs bloquants en production É Maîtriser les fonctionnalités et les limites du produit (on doit pouvoir communiquer sur ce qui ne marche pas ou qui ne marche pas comme c'était 25 prévu) É Assurer la qualité des outils de production de données à destination des clients É Assurer la robustesse (tolérances aux actions non prévues) des produits É Améliorer la sécurité des produits 3/31- É Assurer la continuité de la production de l'utilisateur (Pas de droit à l'erreur sur les traitements au coeur du métier du client ou sur des domaines sensibles (communication de données aux banques)) - Un produit qui répond aux besoins des utilisateurs É Satisfaire les besoins des utilisateurs É Fournir des outils efficaces pour le coeur de métier des clients/utilisateurs É Garantir le respect des réglementations en vigueur É Respecter le cahier des charges É Respecter des niveaux de qualité attendus au lancement du projet (temps de réponses, fonctionnalités adéquates) - Un produit facile à utiliser É Améliorer l'efficacité du produit É Améliorer la facilité d'utilisation pour réduire le recours à l'assistance et à la formation É Améliorer l'ergonomie du produit grâce aux remarques de personnes qui ne connaissent pas (ou peu) le produit. 1.1.2.2. Les relations avec les clients/utilisateurs - Image de marque É Eviter l'effet Classe A de Mercedes où le produit est pris en défaut lors de son premier contact avec le futur utilisateur. Le manque à gagner induit par ces situations est énorme. É Respecter les délais annoncés pour la mise sur le marché des produits É Etre crédible: communiquer sur les bugs qui subsistent dans le produit, favoriser la transparence vis-à-vis des clients. É Etre le plus transparent possible: le client est prêt à entendre que l'on va être en retard si on lui explique les raisons et qu'on lui donne une date fiable de livraison. Dans le cas contraire, il y a un risque de perte de crédibilité et de perte de confiance de la part du client É Valoriser (faire preuve de respect envers) le client en lui livrant des produits qui fonctionnent correctement - 4/31- -Commercialisation É Faciliter le discours des commerciaux en mettant un produit de qualité sur le marché É Améliorer la confiance dans le produit: aussi bien la confiance externe des clients que la confiance interne des personnes qui vendent le produit (commerciaux, formateurs, ingénieurs support, consultants, ...) - Fidélisation des clients É Eviter de perdre des clients uniquement pour des problèmes techniques (exemple: si l'application Web qui ne répond pas, le client va voir le site du concurrent) É Satisfaire le client pour qu'il reste client de la société É Améliorer le contact ente le client et la société : si le client est satisfait du produit, les relations qu'il aura avec la société émettrice seront plus détendues. 1.1.2.3. La société - Maîtriser les coûts É Eviter les sur-coûts de production dus à la non implication des utilisateurs dans les projets. É Diminuer le coût de production du produit par une meilleure maîtrise de tout le processus: de la conception jusqu'à la mise sur le marché. É Diminuer les coûts de correction des bugs: Rapport de 1 à 1000 entre le coût de correction d'un bug découvert lors du développement et celui d'un bug découvert en production. É Diminuer les coûts de l'infrastructure grâce à l'optimisation des programmes (temps de réponses améliorés sans augmenter les ressources matérielles. É Diminuer les besoins en assistance (support technique). É Respecter les coûts et les délais annoncés - Améliorer l'organisation de la société et la communication entre les équipes É Améliorer la qualité du développement: Les testeurs demandant un niveau de qualité suffisant lorsqu'ils reçoivent un module pour le tester, les développeurs sont obligés de faire au moins les tests unitaires avant la livraison en test. -5/31- É Améliorer le processus de production des logiciels: il serait vain de ne vouloir structurer que le processus de test qui arrive en fin du processus de production, s'engager dans la structuration du processus de test entraînera la structuration en amont notamment des processus de développement, de gestion des versions, ... É Faire gagner du temps aux développeurs: pour cela, il ne faut pas se contenter de remplir la fiche d'anomalie en disant que ça ne marche pas, mais il faut aller plus loin dans le diagnostic. Ceci améliore la communication entre les testeurs et les développeurs, les testeurs devenant des alliés dans l'amélioration du produit et non pas des juges sévères du travail effectué. É Mobiliser (et motiver) les équipes internes vers un même objectif: la réalisation d'une version du produit de qualité dans les délais annoncés É Sensibiliser les équipes de R&D aux besoins des utilisateurs lorsque les testeurs sont des représentants des utilisateurs, c'est apporter aux équipes R&D une vision plus large de ce que va devenir le produit, ceci leur permet de mieux s'impliquer. É Améliorer la compréhension entre l'équipe R&D et le client : les testeurs sont à la fois membres de la société et représentants des clients, ils sont plus proches de l'équipe R&D et sont donc mieux placer pour expliquer les problèmes rencontrer et faire passer les messages. É Garder d'abord la confiance des équipes de développement (plusieurs équipes travaillent en parallèle, jusque là, elles ne savaient pas ce qui se passait dans les équipes voisines) par l'élaboration d'un Plan d'Assurance Qualité avec des réunions hebdomadaires de synchronisation: besoin de transparence, de savoir présenter les choses pour ne pas affoler donc ne pas démotiver les autres équipes. Si on ne fait pas ce travail de communication et de synchronisation, on risque d'avoir des équipes qui deviennent concurrentes les unes des autres. Si on ne fait pas ce travail de communication et de synchronisation, on risque d'avoir des équipes qui deviennent concurrentes les unes des autres É Sécuriser les équipes en charge de la mise en production des produits par la livraison de produits ou de versions fiables. Si l'équipe en charge de la mise en production est rassurée sur la qualité du produit livré, les opérations d'installation se passeront dans de très bonnes conditions É Améliorer le contact avec le client pour l'assistance téléphonique: un client satisfait du produit sera bien plus aimable au téléphone... -6/31-- Pérenniser la société É Pour les éditeurs, la survie de la société étant directement liée à la commercialisation des produits, l'augmentation de la qualité du produit est un facteur de survie de la société É Pour les grands comptes, des logiciels sont mis à la disposition des clients, ils sont alors la première vitrine de la société (Prise de commande sur le site Internet), d'autres logiciels interviennent sur le coeur de métier (gestion des flux logistiques). Dans un cas comme dans l'autre, ils sont indispensables à la survie de l'entreprise. 1.1.3. Quels tests effectuer ? 1.1.3.1. Les facteurs de choix quant aux tests à effectuer Quand nous demandons aux entreprises comment elles montent leurs plans de test, elles font souvent référence aux retours d'expérience des versions précédentes, aux statistiques qu'elles font sur les données du support aux utilisateurs et de leur connaissance du métier. Certaines sociétés commencent à parler d'analyse des risques qui soutient leur réflexion lors de la mise en place de leur plan de test. Mais cette notion reste pour le moment assez peu connue dans les sociétés interrogées. Trois notions cependant semblent importantes: - Le type de produit É Un produit qui intervient directement sur le coeur de métier du client sera testé avec beaucoup plus d'attention qu'un outil de reporting (par exemple). É Technologies utilisées pour le développement: Les applications développées grâce à des générateurs de code ou grâce à des modules standards réutilisables demandent moins de tests de validité et de qualité de code; les sociétés peuvent concentrer leurs efforts de tests sur les tests fonctionnels et les tests techniques (performance, volume, . ..) -7/31-- Le niveau d'exigence des clients/utilisateurs É PME/PMI: sont des petites sociétés qui ont peu de moyen et qui comprennent qu'un petit éditeur n'ait pas les moyens de faire tous les tests nécessaires. Ces clients seront alors très exigeants quant à la réactivité de l'éditeur lors de la détection d'un bug. É Distributeur qui veut revendre le produit va être très exigent quant à la qualité du produit car il joue aussi son image de marque et sa crédibilité auprès de ses clients. É Utilisateur final dans un domaine à forte concurrence: le niveau d'exigence est très élevé : si l'application ne répond pas, le client va chez le concurrent. - Gestion des risques: Les technologies deviennent de plus en plus complexes: on a de plus en plus de couches matérielles et logicielles donc de plus en plus de risque d'erreur. On ne pourra jamais faire des tests exhaustifs. Il faut donc faire de la gestion des risques pour que les tests soient efficaces et arbitrer entre le risque encouru et les tests à mener. É Une petite fonctionnalité peut être très importante parce qu'elle est utilisée par tous les clients É Une fonctionnalité peut être importante parce qu'elle touche un domaine sensible (ex: clôtures d'exercices comptable) É Une fonctionnalité peut être importante même si elle n'est utilisée que par 1 client mais que ce client a beaucoup de sites 1.1.4. Organisation de l'équipe technique Nombre de sociétés qui ont une équipe dédiée aux tests Oui Non Total Editeurs 4 31% 9 69% 13 Utilisateur 3 60% 2 40% 5 Total 7 11 18 NB: Une des sociétés rencontrées à une équipe dédiée à la qualité. Sa responsable nous dit qu'il lui est impossible de dissocier tests et qualité logicielle. - 8/31-1.1.4.1. Les compétences d'un testeur Qualités personnelles d'un bon testeur - Rigueur surtout dans l'application d'une démarche bien définie en fonction des objectifs fixés - Etre Méthodique et soucieux de la qualité - Imagination et bon sens pratique: surtout dans la phase de conception des tests - Capacité à se concentrer et à résister au stress: surtout dans la phase d'exécution - Aisance relationnelle pour faciliter le travail avec l'équipe R&D - Bon sens de l'observation et de la description des problèmes, aisance rédactionnelle - Capacité à conceptualiser et formaliser un plan de test, à gérer les risques pour trouver les tests indispensables - Capacité à faire un diagnostic lors de la détection d'une anomalie ce qui va de paire avec une curiosité technique pour comprendre comment fonctionne le produit et faire un diagnostic pertinent - Savoir communiquer avec les développeurs, savoir se faire accepter par eux notamment grâce au diagnostic - Savoir se mettre à la place du client pour faire des tests pertinents. Expert Métier ou Développeur confirmé ? La composition des équipes de tests (même lorsqu'elles sont ponctuelles) est très différente d'une société à l'autre. Dans certaines sociétés, les testeurs sont exclusivement des experts fonctionnels, pour d'autres ils viennent tous de l'équipe R&D, enfin nous trouvons aussi des équipes constituées de ces deux types de profils. Mais ce qui ressort des entretiens, c'est que le testeur doit être concentré sur la validité fonctionnelle des résultats alors que le développeur est d'abord concentré sur la technique. La plupart des sociétés mettent l'accent sur le fait que les testeurs doivent bien connaître le métier de l'utilisateur. Cet argument est notamment beaucoup utilisé comme frein vis-à-vis d'une externalisation des tests. -9/31- Nécessité de bien connaître le produit à tester ? Si une bonne connaissance du logiciel à tester est un atout indéniable dans la phase de conception des jeux d'essais, elle devient un frein lors de la phase d'exécution des tests. Certains clients définissent même leur Testeur idéal comme étant un utilisateur d'un des produits concurrents du leur. D'autres confient les tests à des personnes nouvellement arrivée dans la société pour mettre à profit leur regard neuf sur le produit à tester. Ce qui est surtout important pour faire de bons tests, c'est de bien comprendre la globalité du produit pour trouver les points sensibles à tester absolument. Le testeur doit aussi être curieux de l'architecture technique et fonctionnelle du produit pour être capable de faire un bon diagnostic lorsqu'il détecte une erreur. Formation La plupart des sociétés interrogées ne font pas suivre de formations externes ciblées sur les tests à leurs employés. En revanche, la plupart présentent leur démarche spécifique à leurs équipes. Les formations proposées par les organismes extérieurs sont jugées trop théoriques. Elles sont adaptées aux besoins des personnes qui sont en charge de la mise en place d'une démarche de tests mais pas aux équipes qui vont mener ces tests. La formation des testeurs est essentiellement basée sur: - La méthode de test spécifique à l'entreprise - La connaissance du métier des utilisateurs - La connaissance du produit à tester 1.1.4.2. Processus de test Toutes les sociétés interrogées utilisent des processus identifiés et connus des membres de l'équipe pour mener la phase de recette. Toutes ne vont cependant pas jusqu'à la formalisation de ces processus. Ils sont souvent déroulés par habitude. De même, les documents nécessaires aux tests: scénarios de test, fiches de suivi ne sont pas toujours formalisés. Les spécifications du produit servent de base aux tests; aucun scénario n'étant alors écrit. Il arrive aussi que les testeurs se basent uniquement sur leur connaissance du métier et du produit pour effectuer les tests qu'il leur semble bon de faire. -10/31-1.1.4.3. Les outils de tests L'utilisation d'outils de test est peu répandue dans les sociétés interrogées. Deux freins principaux sont évoqués à ce sujet: - Le coût de ces outils jugé prohibitif. Certaines sociétés ont même développé leurs propres outils en estimant que cela leur reviendrait moins cher. - Le manque de maîtrise du processus de test. Les sociétés n'investissent pas dans ces outils tant qu'elles ne sont pas suffisamment structurées pour être sur d'obtenir un retour sur investissement intéressant. Cependant, beaucoup d'entre elles utilisent des outils de suivi sous la forme de Base d'enregistrement et de suivi des bugs ou d'Outils de gestion des campagnes de test. Une société utilise un outil pour la mise en place des tests unitaires au cours du développement Deux sociétés utilisent des outils pour les tests de performance Deux sociétés utilisent des outils d'automatisation des scénarios de test 1.1.4.4. Perception des tests par l'équipe Recherche et Développement - Les sociétés qui ont initié une démarche de tests depuis plusieurs années notent une grande évolution dans la perception des tests par les membres de leur société. S'ils étaient souvent réticents au début, ils voient rapidement les bénéfices qu'ils peuvent tirer de cette démarche. En particulier, les équipes de développement acceptent l'idée qu'il sera toujours indispensable de faire des tests. Le tabou du Zéro défaut est en train de tomber. - Une étape nécessaire et incontournable du processus de production du logiciel - Parfois une remise en question de leur travail et de leurs compétences - Un stimulant dans la recherche de la qualité de leur produit - Une sécurité - Un moyen d'impliquer les utilisateurs sur le projet - Une vision complémentaire à la leur lors de la conception des tests (ils pensent surtout aux tests du code, les testeurs amènent les tests fonctionnels) - 11/31 - Les nouveaux embauchés dans les équipes Recherche et Développement sont souvent surpris lorsqu'ils arrivent dans une société dont la démarche de test est bien ancrée. Ceci tend à prouver que: - La démarche de test n'est pas encore une partie importante de la formation initiale des informaticiens - La démarche de test n'est pas encore mise en place dans toutes les entreprises En fonctions de l'organisation de la société, les testeurs sont perçus comme: - Des prestataires de l'équipe Recherche et Développement (3 sociétés) : ils prennent alors à leur charge une partie du travail de l'équipe de Recherche et Développement. Il est important de définir les rôles et les prérogatives des testeurs, en particulier de définir très clairement comment sera prise la décision de mettre le logiciel sur le marché. La formalisation des processus de communication entre les équipes de tests et de développement ainsi que des engagements mutuels est alors primordiale. - Des clients de l'équipe Recherche et Développement (4 sociétés) : ils sont alors les représentants des clients qui assurent la réception du produit. Ils ont alors la charge de signer le Procès Verbal de Recette qui équivaut dans ce cas à une autorisation de mise sur le marché. 1.1.5. Les résultats constatés Les entreprises qui ont mis en place une démarche de tests de leurs logiciels, ont constaté rapidement les résultats décrits dans les chapitres suivants. 1.1.5.1. Résultats qualitatifs - Meilleure qualité du produit: Moins de blocages en production, le produit devient aussi plus accessible aux non-initiés (plus de trace en cas de problème, messages d'erreur plus explicites, facilité d'utilisation, ...). - Satisfaction du client: Amélioration des retours clients, Moins d'agressivité lors des appels au support Indicateurs: É Enquête de satisfaction client. -12/ 31- É Comptes-rendus de réunions de suivi des clients (ou réunions internes entre services) - Meilleure connaissance interne du produit: Les tests permettent à ceux qui y participent de mieux connaître toutes les subtilités du produit. Dans certaines sociétés, ce sont les testeurs qui prennent le support second niveau à la place des développeurs. Indicateurs: É Nombres de demandes du support utilisateur transmises à l'équipe de test - Confort de la mise en production d'une nouvelle version: Les mises en production des nouvelles versions se passent mieux puisque l'on évite la détection de bugs bloquants chez le client. Les équipes en charge des mises en production chez le client en sont beaucoup moins stressées. Indicateurs: É Temps de mise en production d'une version -Meilleure organisation de tout le processus de production: Pour faire des tests correctement, il faut aussi intervenir sur le processus de développement et sur le processus de gestion de versions. Indicateurs: É Documents de formalisation des rôles de chacun. - Maîtrise du processus de production: les phases de recette sont être menées comme des projets, elles concourent ainsi à la maîtrise du processus global. Indicateurs: É Nombre de jours de retard lors de la mise sur le marché É Indicateurs de pilotage du projet É Nombre d'anomalies détectées / Nombre de jour Hommes de test É Comparaison entre ce qui a été prévu au Plan de développement et ce qui a été produit. Attention là aussi aux explications: il vaut mieux ne pas sortir une fonctionnalité buggée. Possibilité de ne la sortir que pour le client concerné et de ne pas perturber tous les autres avec, ça c'est un gage de qualité !!! - 13/31 1.1.5.2. Résultats quantitatifs - Diminution du nombre de bugs détectés en production: selon certaines sociétés, 80% des anomalies seraient détectés avant la mise en production Indicateurs: É Nombre de défauts enregistrés lors des campagnes de tests (critiques, majeurs, mineurs) É Nombre de défauts en production par version (critiques, majeurs, mineurs) É Nombre de versions correctives nécessaires pour une version majeure du produit É Types d'appels reçu par le support (anomalie, information, ...) Diminution du coût de correction des bugs: Plus les anomalies sont détectées tôt dans le cycle de vie du logiciel, moins leur correction est coûteuse (Rapport de 1 pour 1000 entre le développement et la production). Indicateurs: É Temps de correction et de livraison des programmes suite à une anomalie - Diminution de la charge du support: Plus un logiciel est stable et moins les clients ont besoin d'appeler le support. La société peut augmenter sont nombre de clients sans avoir à doubler ses ressources au support. Indicateurs: É Statistiques sur les appels au support - Diminution des besoins en formation: un logiciel dont l'ergonomie répond à des normes et qui a été testé devient plus facile d'approche pour un nouvel utilisateur. Indicateurs: É Nombre de jours de formation par client É Nombre d'appels au support qui correspondent à un complément de formation 1.1.5. 3. Retours d'expériences sur la mise en place de la démarche de test - Il faut du temps pour convaincre: les sociétés qui ont mis en place une démarche structurée pour les tests parlent de 2 ans pour que cette démarche devienne naturelle - On sera toujours obligé de faire des tests. C'était un tabou dans l'équipe de développement, c'est en train de changer. Lors du développement, on a un certain nombre de règles demandées par les spécifications. Lors du développement, on -14/ 31- obtient en plus des règles induites et des règles oubliées. Le but des tests est de supprimer ces règles induites ou oublier. - Nécessité d'une démarche itérative: on ne peut pas tout mettre en place en une seule étape. Il est important de définir des priorités, de faire évoluer les choses petit à petit. Définir les objectifs pour une version, faire le bilan à la fin de la campagne et déterminer alors les axes d'améliorations pour la version suivante. - Les résultats sont les alliés de la démarche: les chiffres et les bilans sont les meilleurs alliés de la méthode car ils permettent de rendre objectifs les améliorations obtenues. - Les équipes ne voudraient pas revenir en arrière: Les équipes R&D, même si elles ont eu du mal à accepter que d'autres personnes viennent vérifier leur travail, ne souhaitent pas revenir en arrière une fois que la démarche est acquise: elles trouvent sans cette démarche un meilleur confort de travail. 1.1.6. Le budget 1.1.6.1. Imputation du budget de test Peu de sociétés parmi celles qui ont été interrogées ont un budget spécifique pour les tests (2 sur 14). Les tests sont réalisés mais ne sont pas très visibles: il sont effectuées en temps et en budget masqué. Pour la majorité des sociétés, le budget des tests est imputé au budget de développement. 20 1.1.6.2. Evaluation du budget des tests Chaque société a sa manière d'évaluer le budget nécessaire pour les tests: - 5% du budget global du projet - 15% du budget total du projet -25% par rapport au temps complet du projet - 1/3 du budget global du projet - 40% du budget total du projet pour les tests, 30% pour les spécifications, 30% pour les développements -15/31- - 50% du coût global du projet répartis en 25% pour la conception, 30% pour l'exécution, 15% pour la gestion des environnements, 15% pour le pilotage, 15% pour la livraison - 2 fois la charge de développement - Connaissance du temps de passage d'un jeu de test, à multiplier par le nombre de versions à évaluer dans l'année Evaluation globale annuelle par taux sur somme conception+ développement Lorsque l'on parle de budget ici, la plupart des sociétés parlent de temps passé. 1.1.7. L'externalisation 1.1.7.1. Expérience actuelle: Les sociétés et l'externalisation Externalisation des développements: Externalisés Non externalisés Total Editeur 5 38% 8 62% 13 Utilisateur 4 80% 1 20% 5 Total 9 9 18 Externalisation des tests: Externalisés Non externalisés Total Editeur 3 23% 10 77% 13 Utilisateur 1 20% 4 80% 5 Total 4 22% 14 78% 18 1.1.7.2. Les avantages de l'externalisation des tests - Formalisation des spécifications du produit, les exigences en terme de qualité, ... et de faire évoluer ces documents en même temps que le produit - Maîtrise du processus de test: un société ne peut bien externaliser que les activités qu'elle maîtrise. - Organisation des fonctionnements interne et externe (avec la société prestataire) : Elaborer le Plan d'Assurance Qualité, la Convention de Service, les Engagements de résultats, ... -16/ 31- - Allègement des charges des ressources internes: les consultants, formateurs, ... mobilisés pour la validation de chaque version du produit seraient plus disponibles pour leur métier principal. 1.1.7.3. Les freins évoqués à l'externalisation des tests - La connaissance Métier : É Manque de connaissance métier pour bien tester: les salariés de la société externe ne peuvent pas connaîtreparfaitement le métier, d'où un coût très important de formation. Beaucoup de sociétés interrogées considèrent que le métier outillé par leur logiciel est trop spécifique. É Dilution de la connaissance du produit: les tests permettent d'acquérir une bonne connaissance du produit, notamment pour les équipes de support et de maintenance. Si la société externalise les tests, elle perd cet avantage, ou alors, elle devrait externaliser aussi le support et la maintenance. É Transfert de cette connaissance vers la concurrence: la société externe pourrait apprendre les ficelles du métier au travers de la connaissance du logiciel - Le secret de fabrication: la société externe pourrait reproduire la manière de concevoir le logiciel. - L'organisation: É Mauvaise maîtrise du processus de test: Les sociétés ne sont pas assez bien organiser pour envisager une externalisation des tests. É La maîtrise du processus devient encore plus cruciale avec l'intervention d'un prestataire externe. Maîtriser les coûts et les délais des phases de recette, demande aussi de maîtriser la conduite du projet d'externalisation. - La perte de réactivité : Aujourd'hui, la réactivité de l'équipe R&D est essentiellement basée sur la proximité des équipes de développement et des testeurs. Beaucoup de sociétés craignent une perte de réactivité du fait de la délocalisation des tests donc un manque d'efficacité du processus. - Les coûts: la plupart des sociétés rencontrées n'ont pas de budget spécifique pour les tests, cet effort n'est pas visible, il est consommé sur d'autres budgets. L'externalisation mettrait en lumière ce budget qui paraîtrait du même coup démesuré. -17/31- - La langue de travail peut être un frein si le prestataire et le client ne partagent pas une langue commune. 1.1.8. Les leçons à en tirer 1.1.8.1. Des sociétés pas encore mures pour l'externalisation - Processus de test non maîtrisé É Pas de formalisation de l'organisation ou des méthodes (Qui, Quand, Comment) É Pas d'indicateurs (Combien) É Objectifs et plans de tests pas formalisés (Pourquoi) É Scénarios inexistants (Quoi) > Budget de tests non identifié > Documentation du produit mal maîtrisée > Une démarche globalement mal connue (les nouveaux embauchés sont surpris lorsqu'ils trouvent cette démarche) - Les éditeurs ont peur de perdre leur connaissance (connaissance métier, secret de fabrication de leurs produits) L'externalisation peut être un objectif à long terme dont la mise en place nécessite des missions de préparation. Les sociétés rencontrées sont conscientes de leurs problèmes d'organisation dans le domaine des tests et seront plus facilement intéressées par des missions visant à améliorer leur organisation dans un premier temps. 1.1.8.2. Les freins à l'externalisation - Connaissance du métier insuffisante Commencer d'abord par les tests non fonctionnels (validité et qualité du code, ergonomie, performances, ...) Spécifications et fiches de tests écrites par le client avec accompagnement Abelsin 4 Externaliser l'exécution, pas la conception des tests (c'est-à-dire la partie fastidieuse) 25 -18/ 31- Collaboration sur le long terme 4 la connaissance s'enrichit au fur et à mesure. Une des réponses possibles à ce frein est de prendre l'exemple des développeurs qui, eux non plus, ne sont pas des experts du métier mais des experts du développement. - Perte de réactivité Convaincre sur la maîtrise du processus Trouver le moyen de fonctionner par petits lots - Manque d'organisation interne Missions d'organisations pour maîtriser le processus avant l'externalisation Mise en place d'outil de suivi des campagnes pour maîtrise du processus - Mauvaise visibilité des coûts actuels Mise en place d'indicateurs avant de parler d'externalisation - Communication avec une équipe distante (langue de travail) Il faut garder la langue de travail du client 4 quelles garanties lui offrir ? La modélisation, une langue commune ? - Perte de la connaissance du produit en interne 25 1.1. 8.4. Le temps: un allié de la démarche - Retour d'expérience: il faut 2 ans pour que la démarche porte ses fruits et commence 30 à être acceptée 10 - Divulgation du secret professionnel Les concurrents potentiels peuvent aussi acheter le produit et s'en inspirer 1.1.8.3. Tests = Tests fonctionnels Dès que l'on parle de test, les clients potentiels entendent Tests fonctionnels donc connaissance métier Communiquer sur les autres types de test possibles Commencer par externaliser les tests non fonctionnels -19/ 31- > Résistance initiale de la part de l'équipe R&D - Besoin de résultats pour convaincre Missions d'accompagnement du changement Mise en place itérative de la démarche 1.1.8.5. La mutualisation des outils: un atout pour Abelsin - Des outils trop chers > Des outils difficiles à maîtriser C'est Abelsin qui fait l'investissement et qui se forme aux outils 1.1.8.6. L'analyse des risques: une aide à la structuration Difficulté principale: savoir que tester et définir les priorités des plans de tests Missions spécifiques à l'élaboration des plans de test: démarche structurante pour aborder le sujet 1.1.8.7. La documentation du produit: la brique essentielle 1.1.8.8. La Formation: une piste intéressante - Faire participer toute la société à la démarche de test > Mobiliser toutes les équipes autour d'un objectif: la qualité des produits > Les formations proposées autour des tests sont destinées aux personnes qui vont 20 piloter la mise en place d'une démarche de test dans leur société ; il n'existe pas ou peu de formations pour les personnes impliquées dans le processus de test. Créer des formations (ou journées de sensibilisation) spécifiques aux méthodes de test dans le contexte des sociétés clientes 1.1.8.9. Les tests: un point d'entrée sur la qualité logiciel - 20/31- 1.2. Eléments de la méthode 1.2.1. Typologie des tests La typologie des tests décrit les différents types de tests qu'il est possible d'effectuer pour aboutir à la validation d'un logiciel. 1.2.1.1. Tests de conformité du code Tests de validité du code Vérifier que - tous les chemins logiques sont parcourus au moins une fois, - Tests aux limites (champs numériques, Base de données vide, champ vide, Champs obligatoires Intégrité référentielle) - la plage de validité des données d'entrée et de sortie a été explorée, - Les entrées/sorties de MAJ se font correctement dans la base, - Les fonctions de tri fonctionnent correctement - les résultats sont conformes au dossier de conception détaillée, - Les fonctionnalités NON METIER sont correctement codées Tests de qualité du code Vérifier que le code de l'application réponde aux normes de développement Tests d'assemblage des composants=Tests d'intégration Les tests d'assemblage permettent de vérifier que les composants d'un système applicatif fonctionnent correctement ensemble. Ils permettent également de vérifier que les fonctionnalités d'un ou plusieurs composant et/ou éléments de configuration logiciels fonctionnent correctement par rapport aux spécifications fonctionnelles. (Exemple: intégration avec EXCEL et le logiciel 3D) 1.2.1.2. Tests Utilisateurs Tests d'ergonomie ou Tests d'IHM Tester l'interface Homme- Machine de l'application livrée en se plaçant du côté de l'utilisateur: - 21/31- S'assurer de l'aspect général de l'application et de sa conformité aux chartes graphique et ergonomique - Tester l'état et le comportement des objets de l'IHM (Menus, propriétés des fenêtres, -Tester la navigation à l'intérieur d'un écran - Tester l'enchaînement des écrans Tests fonctionnels Tester l'application livrée en se plaçant du côté de l'utilisateur: - Exécuter l'application de sorte à parcourir un ensemble de fonctionnalités prévues à l'avance - S'assurer de la conformité de ces fonctionnalités aux Spécifications Générales > Détecter les fonctions incorrectes ou manquantes 1.2.1.3. Tests de documentation - Vérifier que le manuel utilisateur correspond aux fonctionnalités proposées - Vérifier que l'aide en ligne correspond à ces mêmes fonctionnalités - Vérifier la cohérence des messages d'erreur 1.2.1. 4. Tests de sécurité Tests de sécurité d'accès Vérifier que l'application fonctionne correctement pour les différents profils d'utilisateurs définis. Tests de sécurité du code Vérifier que le code ne peut pas être piraté Tests d'intrusion Vérifier que le système est protégé contre les attaques extérieures 1.2.1.5. Tests de fiabilité Tests de robustesse Tester l'application livrée en se plaçant du côté de l'utilisateur: -22/31- Exécuter l'application de sorte à parcourir un ensemble d'actions non valides prévues à l'avance - Tester la tolérance aux fautes - Tester la possibilité de récupération - Modes dégradés: Vérifier que l'application fonctionne encore lorsque la souris tombe en panne, le lecteur de CD ou de disquette ne fonctionne pas, le serveur ne répond plus... Tests de performance Tester les unités de l'application (fonction, procédure, module, sous-système...) concernées par les exigences de performances. Valider la capacité qu'ont les serveurs et les réseaux à supporter des charges d'accès importantes. On cherche ici surtout à valider la configuration matérielle et la structure de la base de données installée sur le serveur. Tests de volume ou Tests de montée en charge Vérifier qu'il n'y a pas de dégradation de temps de réponse lorsqu'un volume important de données doit être traité par le serveur Tests de stress Valider le comportement de l'application dans des conditions extrêmes d'exploitation. On vérifiera par exemple que l'application fonctionne correctement avec une quantité de mémoire donnée ou qu'un faible débit du réseau local ne perturbe pas l'application. Ces tests doivent permettre de définir un environnement matériel minimal pour que l'application et le serveur puissent fonctionner correctement. 1.2.1.6. Tests techniques de mise en place Tests d'installation Tester, sur toutes les configurations matérielles et logicielles cible, les procédures d'installation, de bascule ou de chargement de données, de retour arrière, etc.. Tester la documentation d'installation de l'application Tests de désinstallation Vérifier que la désinstallation de l'application laisse le système en état de fonctionner et que tous les éléments installés par l'application disparaissent lors de la désinstallation. - 23/31- Tests de portage ou Test de configuration Comment se comporte l'application dans les différents environnements où elle est censée fonctionner 1.2.1.7. Tests de non-régression Les tests de non régression ne sont pas à proprement parlé un type de test, mais plutôt une étape dans la démarche de test qui consiste à repasser certains tests (fonctionnels, ergonomiques, techniques, ...) pour s'assurer que la nouvelle version du produit fonctionne au moins aussi bien que la précédente. Ils servent à vérifier la non régression entre le logiciel n+1 et n en suivant les tâches ci dessous: - Non régression fonctionnelle: tests fonctionnels n sur logiciel n+1 - Non régression de performance: tests de performance n sur logiciel n+1 - Non régression d'ergonomie: tests d'ergonomie n sur logiciel n+1 - Non régression de robustesse: tests de robustesse n sur logiciel n+1 1.2.2. Processus de test Le processus de test décrit les étapes nécessaires à la validation d'un logiciel 1.2.2.1. Tests de modules Tests unitaires Vise à vérifier la conformité d'un composant de logiciels (ou de toute autre partie isolée de l'application), aux exigences définies dans ses spécifications de conception détaillée. On vérifie ici les fonctionnalités et la structure des modules. Responsabilité de ces tests: Equipe de développement Documents de référence: Conception détaillée Tests d'assemblage Vise à démontrer que les modules de l'application à tester communiquent et interagissent de manière correcte, stable et cohérente entre eux. Garantit que les règles de gestion inter modules sont appliquées et que les données circulent correctement entre les différents sous-ensembles d'un domaine d'activité. Responsabilité de ces tests: Equipe de développement Documents de référence: Conception -24/31-1.2.2.2. Tests de validation Concernent l'application dans son intégralité. On vérifie que l'application et la documentation correspondent à l'attente des utilisateurs et qu'elles s'intègrent bien dans le système d'information. On cherche à montrer que chaque élément des spécifications est réalisé. Test Système Vise à donner l'assurance que l'application à tester sera acceptée par les utilisateurs. Responsabilité de ces tests: Equipe de test (Equipe de validation) Documents de référence: Spécifications Test d'intégration Vise à démontrer que l'application s'intègre correctement à l'architecture de référence. Responsabilité de ces tests: Equipe de test (Equipe de validation) Documents de référence: Spécifications Test de Recette (Test de réception) Vise à confirmer la conformité du système avec ses spécifications et à donner confiance en son fonctionnement correct, avant sa livraison officielle aux utilisateurs. Tests de recette utilisateur Recetter fonctionnellement les applications développées au regard des spécifications de référence. Responsabilité de ces tests: Utilisateurs sous la responsabilité de l'équipe de test ou Equipe de validation Documents de référence: Expression des besoins Tests de recette d'exploitation, Certification Certifier que la solution informatique dans son ensemble est bonne. Responsabilité de ces tests: Service exploitation sous la responsabilité de l'équipe de test ou Equipe de validation Documents de référence: Expression des besoins Pré-production Certifier que la solution informatique est déployable en production et respecte les contraintes de performance. Responsabilité de ces tests: Utilisateurs sous la responsabilité de l'équipe de test ou Equipe de validation - 25/31-Documents de référence: Expression des besoins 1.2.3. Glossaire Campagne de tests: Une campagne de test est l'enchaînement des scénarios de test nécessaires à la validation d'une version du logiciel. Couverture de test: La couverture de test représente l'ensemble des tests prévus par rapport à l'ensemble des tests réalisables sur un système donné. Elle résulte des décisions prises lors de la définition de la stratégie de test. Elle s'exprime en pourcentage ou en ratio par rapport au nombre total de fonctionnalités, de modules, d'instructions, etc. Scénario de test: Un scénario de test décrit les éléments nécessaires à la validation d'une fonctionnalité du logiciel ou d'une règle de gestion particulière: - Objectifs et description du scénario - Pré-requis - Constitution des jeux de données de test Un scénario de test se décompose en une ou plusieurs fiches de test qui décrivent les actions unitaires nécessaires à l'accomplissement du test. Fiche de test: Description des étapes nécessaires pour le test. = Mode opératoire pour accomplir le test. Une fiche de test nécessite un jeu de données en entrée à partir duquel le test va être exécuté et la description des résultats attendus qui seront comparés aux résultats obtenus. Plan de test: Document qui permet de formaliser la stratégie de test Jeu de données: Ensemble des données nécessaires à l'exécution d'un test. Un jeu de données peut être utilisé par une ou plusieurs fiches de tests. Jeu d'essai: Idem Jeu de données Template: Document Word qui sert de modèle pour la génération des fiches de test grâce à la fonctionnalité de publipostage de Word. Test d'ergonomie: Tester l'interface Homme-Machine de l'application livrée en se plaçant du côté de l'utilisateur: - S'assurer de l'aspect général de l'application et de sa conformité aux chartes graphique et ergonomique Tester l'état et le comportement des objets de l'IHM (Menus, propriétés des fenêtres, ...) - 26/31- - Tester la navigation à l'intérieur d'un écran - Tester l'enchaînement des écrans Test fonctionnel: Tester l'application livrée en se plaçant du côté de l'utilisateur: - Exécuter l'application de sorte à parcourir un ensemble de fonctionnalités prévues à l'avance - S'assurer de la conformité de ces fonctionnalités aux Spécifications Générales - Détecter les fonctions incorrectes ou manquantes Tests de validité du code: Vérifier que - tous les chemins logiques sont parcourus au moins une fois, - Tests aux limites (champs numériques, Base de données vide, champ vide, Champs obligatoires Intégrité référentielle) - la plage de validité des données d'entrée et de sortie a été explorée, - Les entrées/sorties de MAJ se font correctement dans la base, - Les fonctions de tri fonctionnent correctement - les résultats sont conformes au dossier de conception détaillée, - Les fonctionnalités NON METIER sont correctement codées Environnement de test: Ensemble des moyens techniques permettant d'exécuter un logiciel de façon indépendante et stable. 1.2.4. Règles de nommage Dans toutes méthodologie, les règles de nommage des différents éléments manipulés sont importantes. Il a été décidé de commencer la nomenclature des objets dès les premières missions réalisées par la société de manière à pouvoir ensuite enrichir cette nomenclature au fil des missions. Les objets manipulés dans la démarche de test sont les suivants: Type Signification SCT SCénario de Test JDO Jeu de DOnnées FTE Fiche de TEst RES-ATT RESultats ATTendus RES-OBT RESultats OBTenus - 27/31 - Le nom de ces objets est constitué de la manière suivante: - Scénario de test: SCT Exemple: SCT-ACT-FTR: Scénario de test pour le domaine Actifs / Frais de Transaction - Jeux de données: JDO- - - Le libellé en clair est optionnel Exemple: JDO-ACT-FTR-001: 1er jeu de données pour les tests du domaine Actifs/frais de transaction - Fiches de test: FTE - - Exemple: FTE-ACT-FTR-001-002: 2nde fiches de test pour le ter jeu de données pour les tests du domaine Actifs/frais de transaction - Résultats attendus: RES-ATT- Exemple: RES-ATT-ACT-FTR-001-002: Résultats attendus pour la 2nde fiches de test pour le 1e1 jeu de données pour les tests du domaine Actifs/frais de transaction - Résultats obtenus: RES-OBT- Exemple: RES-OBT-ACT-FTR-001-002: Résultats attendus pour la 2nde fiches de test pour le 1e7 jeu de données pour les tests du domaine Actifs/frais de transaction - 28/31-1.2.5. Modèle de fiche de test Fiche de test n : Date & Testeur: Famille de tests: Identification du test: Description du test: (objectifs, fonctions testées, interfaces testées, ...) Traitements préalables: (état initial, contexte initial, environnement du test, ...) Fichier des données en entrée: Fichier des résultats attendus: Fichier des résultats obtenu: Procédure: (stimuli, mode d'entrée, actions opérateurs, séquencement des événements, ...) 1.2.6. Modèle de Scénario de test Liens avec d'autres scénarios Scénario de test n : Famille de tests: Date & Rédacteur: Libellé du scénario: Objectifs du scénario: Description du test: Pré-requis: Constitution des Jeux de données: Tableau récapitulatif des Jeux de données et Fiches de test Jeu de données Fiche de test Eléments testés - 29/31-1.2.7. Outil de génération des fiches de test 1.2.7.1. Principes La génération des fiches de tests s'appuie sur les fonctionnalités de publipostage de Word. Un document Word sert de template, ou modèle, de fiches de test: il contient toutes les informations communes à plusieurs fiches de test (manipulations à effectuer quelque soit le test). Un fichier Excel contient les données spécifiques à chaque fiche de test comme le numéro de la fiche, le nom du fichier de données à ouvrir, le nom de la simulation à lancer, .... Ce document contient une ligne par fiche de test à générer. 1.2.7.2. Ajout/Modification des informations concernant une fiche de test Les informations spécifiques à une fiche de test sont saisies dans le fichier Excel qui servira de source de données pour le publipostage. Attention: Ne pas utiliser de retour à la ligne (Alt=Entrée) dans les cellules du tableau Excel 1.2.7.3. Génération des fiches de test à partir d'un template 1. Ouvrir Word. Si la barre d'outil de publipostage n'est pas affichée, la faire afficher (Menu Outil/Lettres et publipostage/Afficher la barre d'outil Fusion et publipostage 2. Ouvrir le fichier template 3. Choisir la source de données (fichier excel qui contient les données spécifiques de chaque fiche) : en utilisant le bouton Ouvrir la source de données de la barre d'outils et en parcourant les répertoires à la recherche du ficher. Choisir la feuille excel qui contient les données (en général Feuille 1) 4. Choisir les fiches que l'on veut générer en utilisant le bouton Fusion et publipostage: Destinataires . Par défaut toutes les fiches de tests sont sélectionnées. 5. Effectuer la fusion en utilisant le bouton Vérifier la fusion et l'option Effectuer la fusion en marquant une pause à chaque erreur 6. Word créée alors un nouveau document dans lequel chaque fiche de test sélectionnée est présente dans une nouvelle section. - 30/31- 2. Revendications 1. Méthode pour mener à bien les tests de logiciel caractérisée en ce qu'elle comporte une étude du domaine des tests logiciels en entreprise et les éléments constitutifs de la méthode. 2. Méthode selon la revendication 1 caractérisée en ce que l'étude de l'état actuel des tests de logiciels porte sur les enjeux des entreprises en matière de test (par rapport au produit, aux relations avec les clients, à l'entreprise elle-même), les tests effectués actuellement, l'organisation des équipes informatiques (compétences des testeurs, processus de test, outils de tests, perception des tests par l'équipe Recherche et Développement), les résultats quantitatifs et qualitatifs des entreprises qui ont mis en place une démarche de test de logiciel, le budget attribué aux tests et la position des entreprises par rapport à l'externalisation des tests et que cette étude présente des conclusions quant à l'état du marché des tests logiciels. 3. Méthode selon la revendication 1 caractérisée en ce que les éléments de la méthode se décomposent en une typologie des tests, une formalisation du processus de test, un glossaire, des règles de nommage, un modèle de fiche de test, un modèle de scénario de test, la description d'un outil de génération des fiches de tests. 4. Méthode selon les revendications 1 et 3 caractérisée en ce que la typologie des tests définit les différents types de tests qu'il est possible d'effectuer pour aboutir à la validation d'un logiciel: Tests de conformité du code (Tests de validité du code, Tests de qualité du code, Tests d'assemblage des composants=Tests d'intégration), Tests Utilisateurs (Tests d'ergonomie ou Tests d'IHM, Tests fonctionnels), Tests de documentation, Tests de sécurité (Tests de sécurité d'accès, Tests de sécurité du code, Tests d'intrusion), Tests de fiabilité (Tests de robustesse, Tests de performance, Tests de volume ou Tests de montée en charge, Tests de stress), Tests techniques de mise en place (Tests d'installation, Tests de désinstallation, Tests de portage ou Test de configuration) et Tests de non-régression 5. Méthode selon les revendications 1 et 3 caractérisée en ce que le processus de test décrit les étapes nécessaires à la validation d'un logiciel: Tests de modules (Tests unitaires, Tests d'assemblage), Tests de validation (Test Système, Test d'intégration, Tests de Recette par les utilisateurs et par l'équipe d'exploitation), Pré-production. - 31/31- 6. Méthode selon les revendications 1 et 3 caractérisée en ce que les règles de nommage présentent la manière de codifier les fichiers contenant les scénario de test, les jeux de données, les fiches de test, les résultats attendus, les résultats obtenus. 7. Méthode selon les revendications 1 et 3 caractérisée en ce que l'outil de génération des 5 fiches de test utilise les fonctionnalités de publipostage du logiciel Microsoft Office.