POLITIQUE DE TEST. Van Caneghem Wouter Analyste fonctionnel - Fedict. Dussart Dirk Architecte - Fedict

Transcription

1 POLITIQUE DE TEST Van Caneghem Wouter Analyste fonctionnel - Fedict Dussart Dirk Architecte - Fedict

2 Table des matières 1. Introduction Objet de ce document Pourquoi des tests? Les tests Principes de base Le processus de test et les responsabilités générales Le modèle V de Fedict Niveaux de test Analyses Niveau test unitaire Niveau d'intégration Niveau de test système Niveau de test d'acceptation Types de test Tests fonctionnels Tests non fonctionnels Tests liés à des modifications (tests de confirmation et tests de régression) Classification des techniques de test Processus de test Tests basés sur les risques Responsabilités Généralités Niveaux de test inférieurs Tests d'intégration système Tests d'acceptation Gravité Exigences pour le fournisseur Généralités Contenu des produits de travail à livrer Produits de travail à livrer (Deliverables) Documents généraux Tests unitaires Tests d'intégration Tests système Tests d'acceptation

3 3.4. Critères d échelonnement Degré de couverture Critères pour passer en TEST Critères pour passer en ACCEPTATION Critères pour passer en PRODUCTION Recommandations pour le fournisseur Matrice de test Scénario couverture Rôles et responsabilités Responsable du test Architecte du test Concepteur du test Testeur Ingénieur d'automatisation des tests Spécialiste de la méthodologie des tests Outils Selenium JUnit Hudson Jenkins Processus de test Spécifications des tests Exécution des tests Rapport des tests Documentation des tests Plan de test Spécifications de la conception des tests Spécifications des tests Journal des tests Rapport d'incident de test Rapport du résumé du test Annexes Annexe 1 Modèles Utilisation des modèles Liste des modèles

4 Date Version Description Auteur 11/10/ Premier avant-projet Wouter Van Caneghem 17/10/ Ajout du chapitre Outils Wouter Van Caneghem 21/10/ Ajout des rôles et responsabilités Wouter Van Caneghem 17/11/ Ajout des tests unitaires Diederik Delen 12/12/ Ajout de la matrice de test Wouter Van Caneghem 13/12/ Ajout des critères d échelonnement Wouter Van Caneghem 27/02/ Mise à jour des critères Wouter Van Caneghem d échelonnement et ajout de l'annexe 5/03/ Mise à jour de la matrice de test Dirk Dussart 13/04/ Révision Coralius nv Coralius nv 14/05/ Modification des gravités Wouter Van Caneghem 4

5 1. Introduction 1.1. OBJET DE CE DOCUMENT Ce document a pour but de définir clairement quelles sont les exigences posées par Fedict dans le cadre du processus de test et d'indiquer qui est responsable de quelles parties de ce processus. Les exigences mentionnées dans ce document s'appliquent à tous les projets. Dans les cahiers des charges spécifiques des documents d'exigences, elles peuvent toutefois être adaptées aux besoins du projet ou du produit. Le but de ce document est également d'aider le fournisseur à fournir le meilleur produit possible, dès la première livraison, afin de créer une situation dont tout le monde sort gagnant. Nous voulons de cette manière réduire au minimum les efforts consentis pour les tests et les nouvelles séries de test par Fedict mais aussi la révision des produits par le fournisseur. Le chapitre 2 donne un aperçu général du processus de test sur la base du modèle V. Nous indiquons ici les niveaux de tests qui relèvent de la responsabilité de Fedict, ainsi que ceux qui relèvent de la responsabilité du fournisseur des logiciels. Nous donnons dans le chapitre 3 un aperçu des produits à livrer (deliverables) et des exigences auxquelles ils doivent répondre. Le chapitre 4 reprend des recommandations complémentaires sur la manière dont un fournisseur peut répondre aux exigences posées, sans toutefois vouloir imposer un cycle ou une méthode de développement déterminé. Nous reprenons à l'annexe 1 une liste des modèles relatifs à cette politique et expliquons leur utilisation POURQUOI DES TESTS? Les tests constituent une condition indispensable au développement et à l'implémentation réussies de systèmes d'informations. La complexité des logiciels modernes est telle qu'il est presque impossible de les implémenter correctement dès la première fois sans aucune vérification. Les tests sont nécessaires pour détecter le plus rapidement possible les problèmes logiciels de manière à pouvoir les corriger à moindres coûts. Les tests sont également réalisés pour développer la confiance et la connaissance du produit livré. Les défauts d'un logiciel peuvent avoir de lourdes conséquences pour les «affaires» et pour les utilisateurs. Outre le fait de pouvoir éviter le plus de fautes possibles, les tests permettent également de montrer à la direction et aux utilisateurs que le produit livré répond à leurs exigences («fit-for-purpose»). 5

6 À noter ici que tant les fonctionnalités que les caractéristiques non fonctionnelles du logiciel sont ici importantes pour pouvoir affirmer qu'un produit est conforme aux exigences posées et utilisable dans son contexte opérationnel LES TESTS Tester un logiciel est le processus utilisé pour vérifier et valider qu'un programme, une application ou un produit : répond aux exigences techniques et professionnelles telles que décrites dans le cahier des charges, les exigences (requirements), les documents d'analyse et de conception. fonctionne comme prévu et est utilisable dans son environnement opérationnel. est implémenté avec les caractéristiques logicielles non-fonctionnelles présupposées. La vérification et la validation doivent ici être interprétées au sens de la norme ISO-9000 : vérification : confirmation par le biais de preuves objectives que les exigences fixées sont satisfaites. validation : confirmation par le biais de la livraison de preuves objectives que les exigences posées sont remplies pour un usage ou une application spécifique. On peut interpréter cela en indiquant que la vérification implique que l'on a développé le logiciel alors que la validation implique que l'on a créé le logiciel PRINCIPES DE BASE Plusieurs principes s'appliquent à tous les tests : - Principe 1 : Les tests permettent de déceler les défauts. Les tests montrent les défauts présents mais ne peuvent pas prouver qu'il n'y a pas de défauts. Les tests réduisent les risques de présence de défauts non décelés dans le logiciel mais le fait qu'aucun défaut n'ait été trouvé ne doit pas être considéré comme une preuve qu'il n'y a pas de défauts. - Principe 2 : Il est impossible de réaliser des tests exhaustifs. Tout tester (toutes les combinaisons d'entrées/sorties et de pré-conditions) n'est pas réalisable sauf dans les cas banals. Au lieu d'effectuer des tests poussés, il convient d'utiliser une analyse des risques et des priorités pour limiter les efforts de test aux tests pertinents. - Principe 3 : Tester rapidement. 6 Les activités de test doivent démarrer le plus rapidement possible dans le cycle de développement du logiciel. Cela permet de détecter les défauts rapidement et de les résoudre à moindres coûts.

7 - Principe 4 : Regroupement des défauts. Quelques-uns des modules contiennent la plupart des défauts qui sont décelés pendant les tests avant sortie et/ou sont responsables de la plupart des erreurs opérationnelles. - Principe 5 : Paradoxe des pesticides. Si le même ensemble de cas de tests est réalisé à plusieurs reprises, ces tests ne présenteront plus au final de nouveaux défauts. Les ensembles de tests doivent donc être régulièrement réévalués. Des nouveaux tests doivent être écrits pour vérifier d'autres parties du logiciel pour trouver d'éventuels nouveaux défauts. - Principe 6 : Les tests dépendent du contexte. La manière d'effectuer les tests dépend du contexte dans lequel le produit sera utilisé. Par exemple, un logiciel de protection est testé différemment qu'un site Internet d'e-commerce. - Principe 7 : Absence d'erreurs. Trouver et résoudre des défauts n'est pas intéressant si le système n'est pas utilisable et/ou ne correspond pas aux besoins et attentes des utilisateurs finaux. 7

8 2. Le processus de test et les responsabilités générales 2.1. LE MODELE V DE FEDICT Exigences, analyse professionnelle et cahier des charges Test d acceptation Documents fonctionnels Test d'intégration système Test système Documents de conception Test d'intégration des composants Test unitaire/des composants FOURNISSEUR Le modèle V de Fedict illustre les niveaux de test utilisés et les responsabilités générales de Fedict et du fournisseur NIVEAUX DE TEST Les niveaux de test sont des groupes d'activités de test qui sont gérés ensemble et qui sont en rapport direct avec les responsabilités telles que définies dans un projet. Fedict utilise les niveaux de test tels que décrits dans le reste de cette section. Lorsqu'un fournisseur utilise d'autres dénominations ou d'autres niveaux de test, il doit pouvoir indiquer quelle est le rapport entre la terminologie qu'il utilise et celle de Fedict et il doit pouvoir montrer que son approche est au moins équivalente à l'approche décrite par Fedict. 8

9 Notez qu'un niveau de test n'est pas la même chose qu'une phase de test. Dans un modèle de développement incrémentiel ou itératif, on pourra par exemple développer à différentes phases d'un projet chaque fois de nouvelles tâches qui appartiennent à un certain niveau de test. Le modèle V est utilisé dans cette politique pour indiquer qui effectue quelles activités et non pour imposer un cycle de développement logiciel spécifique Analyses Les analyses constituent un excellent moyen de détecter des erreurs rapidement et à moindres frais. Lorsque le fournisseur attend une analyse de Fedict pour un ou plusieurs documents, il doit l'indiquer dans l'offre, avec mention des documents à analyser et une estimation des efforts nécessaires dans le chef de Fedict pour ce faire. L'on peut partir du principe qu'une vitesse d'analyse de 6 pages par heure permet une bonne détection des erreurs Niveau test unitaire Les tests unitaires (également appelés tests des composants) recherchent la présence de défauts, vérifient le fonctionnement des modules, programmes, objets, classes de logiciel testables séparément. Les tests unitaires peuvent vérifier tant les fonctionnalités que les caractéristiques non fonctionnelles spécifiques. Les exemples de test sont basés sur des produits de travail comme les spécifications d'un composant, la conception du logiciel ou le modèle de données. Les tests unitaires sont utilisés pour s'assurer que les composants individuels fonctionnent correctement. Les tests unitaires utilisent surtout la technique de test de la boîte blanche et sont donc réalisés en connaissance du code qui est testé et éventuellement avec le soutien de l'environnement de développement (cadre test unitaire, outil de débogage, etc.). Ces tests sont dès lors souvent exécutés par le développeur qui a écrit le code ou qui possède un profil similaire. Les défauts trouvés sont résolus dès qu'ils sont détectés. Pour Fedict, les tests unitaires constituent une bonne alternative aux commentaires dans le code pour autant qu'ils soient bien structurés et lisibles. Un test unitaire donne généralement davantage de détails que le texte en style commentaire. Les tests unitaires sont donc entretenus avec le code où le commentaire est souvent oublié et où le commentaire peut donc rapidement être dépassé. Les tests unitaires possèdent également certaines caractéristiques qui ont une influence sur l'entretenabilité de l'application. Les tests devraient avoir une structure simple et doivent pouvoir être implémentés facilement. Les dépendances doivent être limitées, l'utilisation de cadres principaux et de remplacement doit permettre de simplifier une configuration test. Si l'écriture d'un test est complexe, on doit réfléchir, en tant que développeur, à implémenter la fonctionnalité différemment. Le code difficile à tester est souvent trop complexe, ce qui augmente le risque d'erreur. La recommandation est de conserver autant que possible en-dessous de 15 la complexité cyclomatique des fonctions et des méthodes individuelles. 9

10 Les tests disposent d'une dénomination claire. Nous décrivons ce que fait le test dans la méthode ou le nom du test. Les noms tels que test1, test2 sont interdits. Pensez aussi que les tests unitaires doivent également pouvoir être vérifiés par Fedict. Les tests unitaires sont donc indépendants et doivent donc pouvoir être exécutés de manière autonome Niveau d'intégration Dans les tests d'intégration, les interfaces entre les différents composants et les interactions avec les différentes parties du système sont testées (comme le système d'exploitation, le système de fichiers, le matériel, etc.). Il peut y avoir plusieurs niveaux de test d'intégration et ils peuvent être réalisés sur des objets de test de taille différente. Nous faisons une distinction entre 2 niveaux de test d'intégration distincts : - Tests d'intégration des composants : test de l'interaction entre les composants logiciels. Ils sont réalisés après les tests unitaires. - Tests d'intégration système : test de l'interaction entre les différents systèmes. Ils sont réalisés après les tests système. Plus l'étendue de l'intégration est importante, plus il est difficile d'isoler les défauts dans un composant ou un système spécifique. À chaque instant de l'intégration, les testeurs se concentrent uniquement sur l'intégration même. Par exemple, un nouveau module A est intégré avec un module B. Lors des tests d'intégration l'on est principalement intéressé par la communication entre les modules et non par la fonctionnalité des modules même Niveau de test système Dans les tests système, nous souhaitons tester le comportement de tout un système, comme défini dans le projet. Pour les tests système, aucune connaissance de la conception interne ou de la logique du système n'est a priori nécessaire, l'on utilise en effet surtout des techniques de test de boîte noire. Dans les tests système, l'environnement doit autant que possible correspondre à l'environnement de production final afin de minimiser le risque de défauts spécifiques à l'environnement. Les tests système sont déduits des spécifications des risques, des spécifications des exigences, des processus professionnels, des utilisations ou des autres descriptions de haut niveau. Ils sont réalisés dans le contexte des exigences fonctionnelles. Les tests système examinent ensuite également les exigences non fonctionnelles (attributs de qualité). Les tests système contiennent typiquement les types de test suivants : tests d'interface graphique utilisateur, tests de convivialité, tests de régression, tests de performances, tests de gestion des erreurs, tests de maintenance, tests de compatibilité, tests de charge, tests de sécurité, tests d'extensibilité, etc. 10

11 Le but est qu'à la fin de l'exécution du test système le fournisseur soit convaincu que le système répond à toutes les exigences fixées et qu'il est prêt à être transféré au client (éventuellement à l'exception de l'interaction avec les systèmes homologues) Niveau de test d'acceptation Les tests d'acceptation sont souvent la responsabilité des clients ou des utilisateurs (finaux) d'un système. D'autres intervenants peuvent aussi y être impliqués. Le but des tests d'acceptation est de gagner la confiance dans le système, dans des parties du système ou dans des propriétés non fonctionnelles. Trouver des défauts n'est pas l'objectif principal des tests d'acceptation. Les tests d'acceptation nous permettent de vérifier l'adéquation d'un système pour une utilisation. Les tests d'acceptation peuvent se produire comme davantage qu'un seul niveau de test. Par exemple : - les tests d'acceptation d'utilisabilité d'un composant peuvent être réalisés pendant les tests unitaires. - Les tests d'acceptation d'une nouvelle amélioration fonctionnelle peuvent être réalisés pour les tests système. Les tests d'acceptation contiennent généralement les éléments suivants qui peuvent être considérés comme un niveau de test distinct : - Tests d'acceptation des utilisateurs : vérification par des utilisateurs professionnels qu'un système est prêt à l'emploi. - Tests d'acceptation opérationnels : l'acceptation du système par les administrateurs système, contient des tests de sauvegarde/restauration, de récupération après sinistre, de gestion des utilisateurs, des tâches de maintenance, etc. - Tests contractuels et de directives (test de conformité) : les critères d'acceptation doivent être convenus pendant les négociations relatives au contrat. L'acceptation s'effectue alors visà-vis de ces critères pour la production du logiciel. Cela comprend aussi les normes (gouvernement, juridique, sécurité, etc.). - Sans accord spécifique, le système doit également satisfaire aux exigences fixées telles que décrites dans le cahier des charges (signé) et dans les documents correspondants ainsi qu'aux exigences décrites dans tous les documents plus techniques approuvés par Fedict. - Tests alpha et béta : retour des clients potentiels ou existants avant la commercialisation du produit. Les tests alpha sont réalisés au sein de l'organisation du développeur. Les tests béta (tests de terrain) sont réalisés sur le site TYPES DE TEST Tests fonctionnels Les tests fonctionnels vérifient les fonctions qu'un système, un sous-système ou un composant doivent réaliser. Ceux-ci peuvent être décrits dans les produits de travail tels que les spécifications des exigences, les utilisations, les spécifications fonctionnelles, etc. 11

12 Ils décrivent «ce que» fait le système. Les tests fonctionnels sont basés sur les fonctionnalités et leur interopérabilité avec des systèmes spécifiques. Les tests fonctionnels peuvent être réalisés à chaque niveau de test. Par exemple, les tests pour les composants peuvent être basés sur des spécifications des composants. Les tests fonctionnels considèrent le comportement externe des logiciels et sont donc principalement développés à l'aide des techniques de test de la boîte noire Tests non fonctionnels Les tests non fonctionnels comportent (liste non exhaustive) des tests de performances, des tests de charge, des tests de stress, des tests d'utilisation, des tests de fiabilité, etc. Ils testent «comment» fonctionne le système. Les tests non fonctionnels peuvent être réalisés à chaque niveau de test. Les tests non fonctionnels vérifient les caractéristiques non fonctionnelles des systèmes. Souvent, ils fonctionnent en mesurant des informations quantifiables qui peuvent être comparées avec des limites pré-établies. Par exemple, les temps de réponse pour les tests de performance Tests liés à des modifications (tests de confirmation et tests de régression) Lorsqu'un défaut est trouvé et résolu, le logiciel doit à nouveau être testé pour s'assurer que le défaut original a été parfaitement résolu. C'est ce que l'on appelle les tests de confirmation. On parle dans ce cas de «nouveaux tests». Remarque : Le débogage du code est une activité de développement, pas une activité de test. Les tests de régression sont de nouveaux tests d'un code de programme déjà testé après modifications, afin de découvrir des défauts (dans les aspects non modifiés du logiciel) causés par des modifications au logiciel ou à l'environnement. Ces tests sont réalisés chaque fois que l'environnement ou le logiciel change. Des tests de régression peuvent également être réalisés à chaque niveau de test et peuvent être réalisés tant pour les tests fonctionnels que non fonctionnels et structurels. Des tests de régression sont souvent réalisés et concernent les fonctionnalités les plus critiques pour être un candidat idéal pour l'automatisation CLASSIFICATION DES TECHNIQUES DE TEST Les techniques de test sont des méthodes de travail formelles pour déduire les cas de test des documents, des modèles de logiciel ou de code. 12

13 Nous pouvons scinder les différentes sortes de techniques de test en deux groupes. Les tests de boîte blanche et les tests de boîte noire. Les tests de boîte blanche sont basés sur le code de programme, les descriptions des programmes ou le projet technique. L'on utilise explicitement les connaissances sur la structure interne du système. Ces tests sont généralement réalisés par les développeurs et il s'agit d'un test réalisé par le développeur pour démontrer qu'un programme (ou un module) ou une série de programmes (ou de modules) satisfait aux exigences posées dans les spécifications techniques. Les tests de boîte noire sont basés sur les spécifications fonctionnelles et les exigences de qualité. Dans ces tests, le système est considéré dans la forme tel qu'il fonctionnera lors de son utilisation finale. Le logiciel est considéré comme une «boîte noire» sans connaissance de l'implémentation interne ni de la structure interne. Généralement, plusieurs tests sont implémentés, basés sur les spécifications et exigences fonctionnelles. Même si les deux groupes des techniques de test peuvent être utilisés sur tous les niveaux, l'on applique principalement des techniques de test de boîte blanche sur les niveaux de test inférieurs et des techniques de test de boîte noire sur les niveaux supérieurs. Les tests d'acceptation réalisés par Fedict sont principalement utilisés dans les techniques de test de boîte noire PROCESSUS DE TEST Libre au fournisseur de choisir un processus de test qui correspond à sa méthode de développement pour autant qu'il réponde aux exigences telles que fixées au chapitre 3. Le chapitre 4 reprend des directives à ce sujet sans toutefois imposer un processus spécifique TESTS BASES SUR LES RISQUES Dans le cadre des tests basés sur les risques, sur la base d'une analyse des risques (du produit), les efforts de tests sont ciblés sur les parties ou aspects d'une application qui comportent le plus gros risque. Cela est considéré comme une bonne pratique pour déterminer la stratégie de test au moins partiellement sur la base d'une analyse des risques. Deux possibilités : Fedict a joint une analyse des risques dans le cahier des charges ou dans les documents correspondants. Fedict n'a pas joint d'analyse des risques dans le cahier des charges ou dans les documents correspondants. 13

14 Dans le premier cas, nous conseillons au fournisseur d'utiliser cette analyse et éventuellement de l'affiner lorsque les aspects techniques du système en test sont plus clairs. Dans le deuxième cas, le fournisseur peut lui-même réaliser une analyse. Fedict peut éventuellement donner ici sont avis concernant l'impact des risques. Lorsque le fournisseur de Fedict attend un effort en lien avec l'analyse de risques, il doit reprendre dans l'offre : une description de son approche relative à l'analyse de risque et au rôle de Fedict. une estimation du temps nécessaire à Fedict pour remplir ce rôle RESPONSABILITES Nous indiquons dans cette section où se situent les responsabilités du fournisseur et de Fedict Généralités Nous partons du principe que le fournisseur est un professionnel dans le développement de logiciels et dispose des connaissances nécessaires. Lorsque le fournisseur, de par ses connaissances, découvre des défauts dans les spécifications qui pourraient entraîner que le système sous test ne soit pas adéquat pour l'usage visé, nous estimons que Fedict doit immédiatement en être averti de manière à ce qu'une solution puisse être trouvée au plus vite. Il est clair que l'affirmation ci-dessus peut parfois dépasser les dispositions contractuelles mais il est toujours dans l'intérêt des deux parties de livrer un système utilisable. Le but est que le fournisseur livre à Fedict un système entièrement testé et fonctionnant correctement. Cela comprend également la livraison de la documentation de test telle que décrite dans le chapitre suivant et éventuellement spécifiée dans un cahier des charges ou un document d'exigences. Fedict effectuera alors sur ce système des tests d'acceptation pour vérifier si toutes les exigences sont effectivement satisfaites Niveaux de test inférieurs Les niveaux de tests unitaires (tests des composants), tests d'intégration et tests systèmes ou les niveaux correspondants, tels qu'utilisés par le fournisseur relèvent entièrement de la responsabilité du fournisseur. Fedict vérifiera par échantillonnage si les produits de travail répondent aux exigences fixées. 14

15 Tests d'intégration système Dans les tests d'intégration système, il est possible que les systèmes du fournisseur doivent être intégrés avec les systèmes d'autres fournisseurs ou des autorités. Une collaboration est indispensable à ce sujet. Fedict jouera à cet égard un rôle de facilitation mais la responsabilité finale reviendra au fournisseur du système testé. Fedict vérifiera par échantillonnage si les produits de travail répondent aux exigences fixées Tests d'acceptation L'analyse, la conception et l'implémentation d'un ensemble de tests d'acceptation sont assurées par le fournisseur. Fedict vérifiera par échantillonnage si les produits de travail répondent aux exigences fixées et prévoira également des scénario de test supplémentaires. Fedict effectuera les tests et utilisera les résultats pour l'acceptation du système ou pour demander des corrections le cas échéant GRAVITÉ La gravité (severity) d'un défaut est souvent une source de discussion lors de l'acceptation d'un système. [Section normative] Fedict utilise les définitions suivantes pour les degrés de gravité. Toute dérogation à ces conventions doit être établie contractuellement avant le début d'un projet. 15

16 Critique (Critical) Élevée (High) Un test ne peut être terminé d'aucune manière. Ex. : l'envoi de données donne un message d'erreur, l'application bloque, etc. Un test peut être terminé mais le comportement de l'application n'est pas conforme aux spécifications. Ex. : un bouton annuler effectue un envoi, une liste de données n'est pas correctement affichée, etc. Moyenne (Medium) Un test peut être terminé conformément aux spécifications mais il y a des erreurs qui peuvent être évitées par des interventions manuelles (sans modifier le code source). Ex. : un contrôle erroné d'un champ de courriel, etc. Basse (Low) Nice to have Il y a des problèmes cosmétiques (orthographe, présentation, couleurs) qui influencent peu le fonctionnement de l'application. «pas conforme aux spécifications» doit être interprété ici comme ne fonctionne pas comme décrit dans le cahier des charges, le document d'exigences ou toutes autres spécifications approuvées par Fedict. Dans le cas où différentes spécifications ne sont pas cohérentes, l'interprétation la plus intéressante pour Fedict sera utilisée. [Fin de la section normative] 16

17 3. Exigences pour le fournisseur 3.1. GENERALITES Cette section contient les produits de travail standard à livrer, les critères de qualité associés et les exigences pour installer le système sous test dans les différents environnements. Ce chapitre est normatif, sauf où il est clairement indiqué que ce n'est pas le cas. Les exigences décrites ici peuvent être modifiées dans les cahiers des charges et dans les documents d'exigences correspondants ou dans les contrats entre le fournisseur et Fedict, tant pour imposer des exigences plus strictes que pour imposer des exigences moins strictes. Pour tous les aspects du processus de test qui ne sont pas explicitement modifiés dans les documents contractuels pertinents, le contenu de ce chapitre doit déjà être considéré comme des exigences de test CONTENU DES PRODUITS DE TRAVAIL A LIVRER Les produits de travail à livrer doivent en principe au moins contenir les données telles que mentionnées dans les modèles (templates) décrits à l'annexe 1. Les cahiers des charges, documents d'exigences ou contrats individuels peuvent imposer des exigences supplémentaires au contenu. S'il y est dérogé, le fournisseur doit en mentionner ici la raison ou dans les plans de test ou dans les documents faisant l'objet de la dérogation, chaque fois avec mention de la raison de la dérogation. Lorsque le fournisseur utilise ses propres modèles, il doit s'assurer qu'ils contiennent les informations nécessaires et il doit présenter à la demande de Fedict un mapping entre sa structure et celle des modèles de l'annexe. La transmission de ces modèles N'implique PAS que Fedict demande à utiliser ces modèles pour générer effectivement des documents. [non normatif] Il est clair qu'ils servent surtout de liste de contrôle. Dans certains cas, il est certainement conseillé d'enregistrer les informations demandées dans un outil plutôt que dans des documents MS Office.[fin de la section normative] 17

18 3.3. PRODUITS DE TRAVAIL A LIVRER (DELIVERABLES) Documents généraux Offre Le fournisseur doit décrire dans l'offre l'approche de test et le processus de test qu'il utilisera pour le marché. Les attentes de Fedict à cet égard sont qu'il s'agit d'un processus structuré et contrôlé, capable de livrer à temps et correctement les produits demandés Plan(s) de test Le fournisseur remettra un plan de test dans lequel il exposera les objectifs des tests et les différents buts par niveau de test. Ce plan peut se composer d'un seul document ou d'un plan de test principal et d'un plan de test par niveau. La fourniture du plan de test doit être réalisée au plus tard avant la première livraison du logiciel. Le plan de test principal doit être entretenu jusqu'à la livraison finale du logiciel. Le contenu comprend au moins les éléments cités dans le modèle correspondant en annexe. Fedict contrôlera si les plans livrés sont conformes aux exigences de cette politique et aux éventuelles normes et exigences supplémentaires imposées dans le cahier des charges, le document d'exigences ou toute autre convention contractuelle. Il va dans l'intérêt des deux parties que les plans soient livrés et contrôlés le plus rapidement possible afin d'éviter toute révision et retard éventuel lors de la phase d'acceptation Rapport du résumé du test principal Lors de chaque livraison de logiciel à Fedict, le fournisseur joindra un rapport de résumé du test (principal). Le contenu comprend au moins les éléments cités dans le modèle correspondant dans l'annexe et fait rapport sur chaque niveau de test qui est déjà exécuté Tests unitaires Lors de chaque livraison de logiciel à Fedict, le fournisseur remet un aperçu du test unitaire ainsi que quelques cas pertinents. Les autres tests doivent être mis à disposition à toute demande de Fedict. Il peut s'agir de code ou de tests manuels. Les tests unitaires comprennent au moins une suite de tests automatisée pouvant être exécutée dans tout environnement de test et dans l'environnement de production et possédant une couverture (statement coverage) de 75%. Cette couverture doit être démontrée sur la version 18

19 fournie du logiciel. Cela est réalisé à l'aide d'un utilitaire éventuellement mis à disposition pour Fedict. Un rapport du résumé du test (ou un tableau de test automatisé) est également livré. [non normatif] Nous conseillons au fournisseur d'utiliser ici un système d'intégration continue ou de développement quotidien avec des tests intégrés.[fin de la partie non normative] Fedict contrôlera par échantillonnage si les tests unitaires livrés sont conformes aux exigences de cette politique et aux éventuelles normes et exigences supplémentaires imposées dans le cahier des charges, le document d'exigences ou toute autre convention contractuelle. [non normatif] Pour les projets complexes ou critiques, le degré de couverture est augmenté ou il peut être procédé à une forme de couverture plus stricte comme par exemple la couverture décisionnelle ou conditionnelle. [fin de la section non normative] Entrée Documents fonctionnels Documents de conception techniques Code des composants individuels Actions Test des composants individuels Sortie (deliverables) Tests (spécification du test), y compris une suite de test automatisée Résultats des tests Rapport de résumé du test (ou tableau de bord) Rôle Fedict Contrôle par échantillonnage Tests d'intégration Lors de chaque livraison de logiciel à Fedict, le fournisseur remettra des tests d'intégration des composants Il peut s'agir de code ou de cas de tests manuels. Lors de toute livraison de logiciel à Fedict, le fournisseur remettra les tests d'intégration système pour autant que l'intégration système soit déjà effectuée et d'application. Il peut s'agir ici de tests automatisés ou manuels. Le fournisseur démontrera (par exemple en fournissant une matrice de traçabilité) que : tous les composants internes sont intégrés. toute interface externe est testée au niveau des aspects suivants : o la communication fonctionne sur cette interface. o l'interprétation des données échangées est la même pour les deux systèmes. Si cela est pertinent et dès que l'intégration système a eu lieu, le fournisseur démontrera que le flux de bout en bout de l'application a été testé au niveau fonctionnel (tests de bout en bout sur base de l'analyse commerciale, tests de chaîne). [non normatif] Nous conseillons au fournisseur de reprendre au moins une partie des tests d'intégration des composants dans un système d'intégration continue ou de développement quotidien. [fin de la section non normative] 19

20 Fedict contrôlera par échantillonnage si les tests d'intégration livrés sont conformes aux exigences de cette politique et aux éventuelles normes et exigences supplémentaires imposées dans le cahier des charges, le document d'exigences ou toute autre convention contractuelle. Entrée Analyse professionnelle (pour les tests d'intégration système) Documents fonctionnels Documents de conception Code source des composants à intégrer Artefacts des composants à intégrer Actions Test des interfaces entre les composants Tests des interfaces entre le système et ses systèmes homologues Tests de bout en bout des attributs de qualité fonctionnels et non fonctionnels Sortie Tests (conception de test et spécifications de test) Résultats des tests Rapport du résumé du test Matrices de traçabilité Rôle Fedict Contrôle par échantillonnage Tests système Lors de toute livraison de logiciel à Fedict, le fournisseur remettra les tests système pour autant qu'ils soient déjà d'application. Il peut s'agir ici de tests automatisés ou manuels. Le fournisseur démontrera (par exemple en livrant une matrice de traçabilité) que les fonctionnalités complètes telles que décrites dans les documents fonctionnels approuvés par Fedict sont couvertes et que l'analyse de risque a été effectivement respectée. Le fournisseur démontrera (par exemple en livrant une matrice de traçabilité) que les attributs de qualité non fonctionnels prévus pour des tests système sont couverts effectivement dans le plan de test correspondant. Fedict contrôlera par échantillonnage si les tests système livrés sont conformes aux exigences de cette politique et aux éventuelles normes et exigences supplémentaires imposées dans le cahier des charges, le document d'exigences ou toute autre convention contractuelle. Entrée Documentation fonctionnelle Actions Test des fonctionnalités du système intégré Test des attributs de qualité non fonctionnels du système intégré Sortie (deliverables) Tests (conception de test et spécification de test) Résultats des tests, y compris la liste de tous les défauts connus encore ouverts Rapport du résumé du test Matrices de traçabilité Rôle Fedict Contrôle par échantillonnage 20

21 Tests d'acceptation Le fournisseur remettra les exemples de test d'acceptation au plus tard deux semaines avant le début de l'exécution des tests d'acceptation. Il s'agit en principe de tests de boîte noire. Comme ils sont automatisés, le mode d'exécution de ces cas doit être bien documenté. Cette documentation fait donc partie des produits de travail à livrer. Le fournisseur remettra à Fedict la formation, les démonstrations ou les explications nécessaires comme décrit dans les critères d échelonnement de manière à ce que Fedict puisse exécuter les tests d'acceptation. [non normatif] L'objectif est que le fournisseur remette un ensemble complet et correct de tests d'acceptation. Fedict contrôlera cet ensemble de manière approfondie et effectuera ces tests. Il est possible que Fedict demande ou crée des tests supplémentaires après ce contrôle. Pour autoriser le contrôle et les corrections éventuelles, la livraison doit être réalisée bien avant le début de l'exécution des tests d'acceptation. [fin de la section normative] Le fournisseur démontrera (par exemple en livrant une matrice de traçabilité) que toutes les fonctionnalités, telles que décrites dans les documents d'exigences et/ou dans le cahier des charges et dans d'autres engagements contractuels éventuels, sont couvertes par l'ensemble de test fourni. Fedict contrôlera par échantillonnage si les tests d'acceptation livrés sont conformes aux exigences de cette politique et aux éventuelles normes et exigences supplémentaires imposées dans le cahier des charges, le document d'exigences ou toute autre convention contractuelle. Fedict peut, sur la base de ses connaissances dans le domaine, ajouter des tests de validation supplémentaires sauf si ceux-ci sont explicitement interdits (dans le contexte de l'acceptation) par des conventions contractuelles. Fedict mettra ces tests supplémentaires à la disposition du fournisseur avant le début de l'exécution des tests. [non normatif] Les éventuels tests complémentaires ont pour but de compléter la validation sur la base des connaissances des experts dans le domaine. Dans l'intérêt des deux parties, cela doit être réalisé le plus rapidement possible. [fin de la section normative] Fedict effectuera ces tests, éventuellement avec l'aide du fournisseur. Fedict établira également un rapport de résumé du test de ce niveau de test. Le fournisseur intégrera ce rapport de résumé de test dans le rapport de résumé de test principal final. Si les tests sont très complexes ou requièrent des connaissances approfondies des aspects internes de l'application, il est possible que Fedict observe l'exécution de ces tests lors de leur exécution par le fournisseur. Comme les exigences donnent une description de boîte noire du système en test, cette situation doit toutefois rester exceptionnelle et nécessite une approbation préalable de Fedict. 21

22 Gestion des incidents et des défauts dans les tests d'acceptation. Le fournisseur veillera dès le début de l'exécution des tests d'acceptation à ce que Fedict dispose d'un outil et/ou d'une procédure pour enregistrer les défauts et les incidents. Pour les projets non banals, préférence sera donnée à un outil de gestion des défauts (tel que par exemple JIRA, Mantis ou Bugzilla) plutôt qu'à un document ou une procédure basée sur la messagerie. Le fournisseur veillera cependant à ce que les défauts et les incidents ne se perdent pas et à ce qu'ils soient suivis jusqu'à leur clôture. Les défauts décelés par Fedict ne peuvent être clôturés que moyennant l'autorisation de Fedict. Dès que l'application est installée dans l'environnement d'acceptation et qu'elle est mise à la disposition de Fedict, aucun défaut ne peut être clôturé sans l'autorisation de Fedict. Cela s'applique tant aux défauts décelés par Fedict qu'à ceux décelés par d'autres parties (par exemple le fournisseur même ou un utilisateur final) ou aux défauts qui étaient encore ouverts de niveaux de test ou de phases antérieurs. Au début des tests d'acceptation dans l'environnement d'acceptation, le fournisseur remettra une liste de tous les défauts encore ouverts dans le cadre du rapport de résumé du test du niveau de test antérieur. Entrée Analyse commerciale Connaissance du domaine Spécifications contractuelles Normes et directives (gouvernement, juridique, sécurité) comme mentionnées dans le cahier des charges ou les documents correspondants Actions Tests d'acceptation des utilisateurs Tests d'acceptation opérationnels Tests d'acceptation contractuels Tests de conformité vis-à-vis des normes et directives comme mentionnés dans le cahier des charges ou les documents correspondants Sortie (Deliverables) du fournisseur Sortie (Deliverables) de Fedict Tests (conception de test et spécifications de test) Matrices de traçabilité Rapport du résumé du test principal Résultats des tests Rapport du résumé du test de niveau Fedict Contrôle par échantillonnage des cas de test et des matrices de traçabilité Exécution du test, y compris l'enregistrement des résultats du test et les anomalies éventuelles Réalisation d'un rapport de résumé du test de niveau 3.4. CRITERES D ECHELONNEMENT Les critères d échelonnementsont les exigences auxquelles le candidat doit satisfaire avant de pouvoir être installé sur un environnement supérieur. Nous décrivons dans ce paragraphe les 22

23 critères d échelonnement généraux mais les critères exacts doivent être établis pendant le projet même ou dans le cahier des charges, ou encore ultérieurement en concertation avec le fournisseur. Si aucun autre accord ou exigence n'est spécifié, les critères ci-dessous sont d'application. Nous distinguons les environnements d'application suivants : - Développement : c'est ici que sont réalisés le développement et les tests d'intégration des composants et les tests unitaires. - Test : tests système. - Acceptation : tests d'acceptation. - Production : environnement réel d'application. Il doit être déterminé projet par projet si les tests d'intégration système sont réalisés sur l'acceptation ou sur l'environnement de test Degré de couverture Lorsque nous affirmons dans les critères d échelonnement qu'une fonctionnalité ou qu'un critère de qualité non fonctionnel est couvert, nous entendons : Qu'un ou plusieurs tests ont été écrits pour cette fonctionnalité ou ce critère de qualité non fonctionnel. Que ces tests sont effectivement réalisés et qu'en cas d'échec, un défaut est généré. Que les tests vérifient de manière adéquate la fonctionnalité à tester ou le critère de qualité non fonctionnel dans ce sens qu'ils sont développés à l'aide des techniques décrites dans un plan de test inspecté et approuvé par Fedict. Étant donné qu'il n'est parfois pas réalisable, pour des raisons de temps et d'argent, de couvrir de manière adéquate 100% des fonctionnalités ou des critères de qualité non fonctionnels, des degrés de couverture minimum inférieurs peuvent être mentionnés dans le cahier des charges. Le fournisseur peut également proposer dans les plans de test des degrés de couverture inférieurs, de préférence associés à l'exposition aux risques des critères de qualité correspondants. Les plans de test mentionneront toujours la manière dont le degré de couverture est mesuré. Nous illustrons les attentes de Fedict à l'aide d'un exemple non normatif dans la section 4.2. Le degré de couverture doit toujours être approuvé explicitement par Fedict et il est donc toujours conseillé de négocier rapidement ces degrés de couverture avec Fedict Critères pour passer en TEST - Une couverture de 75% (statement coverage) du code par ensemble de tests unitaires automatisés - 100% des tests unitaires doivent être réussis 23

24 Le fournisseur informatique de l'application doit joindre un rapport clair reprenant ces chiffres lors de chaque livraison. Pour mesurer le degré de couverture, le fournisseur informatique doit utiliser un outil. Sur simple demande de Fedict, le fournisseur doit démontrer explicitement cette mesure. - Le plan de test qui décrit les tests d'intégration des composants et les tests d'intégration unitaires est inspecté et approuvé par Fedict. - Le rapport de résumé des tests et/ou le tableau de bord relatif aux tests d'intégration unitaires et des composants est transmis à Fedict Critères pour passer en ACCEPTATION Bogues Il ne peut subsister de bogues bloquant l'exécution des cas de test et pour lesquels il n'existe aucune solution provisoire (workaround). Ce sont les bogues affublées de l'indice de gravité «Majeur» ou «Critique» Il doit subsister moins de 5 bogues non résolues de gravité «Moyenne» et ceux-ci sont connus et acceptés (pour l'installation dans l'environnement d'acceptation) par Fedict. Il doit subsister moins de 20 bogues non résolues de gravité «Basse» et ceux-ci sont connus et acceptés (pour l'installation dans l'environnement d'acceptation) par Fedict Degré de couverture Les fonctionnalités complètes telles que décrites dans les documents fonctionnels approuvés par Fedict sont couvertes. Les attributs de qualité non fonctionnels prévus pour les tests au niveau système sont couverts dans le plan de test correspondant. L'ensemble de tests unitaires automatisés est réalisé dans l'environnement de test sur la dernière version du logiciel. Cette exécution a démontré que : le degré de couverture (statement coverage) est encore 75%. chacun des tests unitaires a réussi. Autres - Le plan de test qui décrit les tests système est inspecté et approuvé par Fedict. - Le rapport de résumé des tests relatif aux tests système est transmis à Fedict. - Le fournisseur a remis les tests d'acceptation à Fedict et a donné à Fedict la formation nécessaire ou une démonstration pour permettre à Fedict d'effectuer les tests d'acceptation. Cela peut éventuellement se produire après l'installation dans l'environnement d'acceptation mais avant le transfert formel de l'application à Fedict pour acceptation. 24

25 Critères pour passer en PRODUCTION Bogues Il ne peut y avoir de bogues présentant le degré de gravité «Majeur» ou «Critique». Il doit subsister moins de 5 bogues non résolues de gravité «Moyenne» et ceux-ci sont connus et acceptés (pour l'installation dans l'environnement de production) par Fedict. Il doit subsister moins de 20 bogues non résolues de gravité «Basse» et ceux-ci sont connus et acceptés (pour l'installation dans l'environnement de production) par Fedict. Un plan destiné à résoudre les défauts restants est établi par le fournisseur et approuvé par Fedict. Lorsqu'il est décidé, en accord entre le fournisseur et Fedict de ne pas résoudre certains défauts, cela doit être explicitement documenté et approuvé par Fedict, par exemple dans le plan ci-dessus Degré de couverture Toutes les fonctionnalités et les attributs de qualité non fonctionnels tels que décrits dans le cahier des charges et/ou dans les documents d'exigences sont couverts. Fedict peut toutefois décider de n'exécuter qu'une partie des tests prévus. L'ensemble de tests unitaires automatisés est réalisé dans l'environnement d'acceptation sur la dernière version du logiciel. Cette exécution a démontré que : le degré de couverture (statement coverage) est encore 75%. chacun des tests unitaires a réussi. Autres - Le plan de test qui décrit les tests d'acceptation est inspecté et approuvé par Fedict. - Le rapport de résumé de test relatif aux tests d'acceptation est fourni et est intégré dans le rapport de résumé de test principal. - Le fournisseur a cédé les tests (tous les produits de travail livrés en lie avec le test de l'application) à l'équipe qui doit gérer ou entretenir l'application pour autant qu'il ne s'agisse pas du fournisseur même. 25

26 4. Recommandations pour le fournisseur Cette section contient des informations non normatives susceptibles d'aider le fournisseur à satisfaire aux exigences de Fedict, d'autant plus si le fournisseur ne possède que peu d'expérience des tests structurés MATRICE DE TEST Cette section illustre comment les tâches de test s'intègrent dans un cycle de développement et illustre les outils utilisables. 26

27 BUSINESS ANALYSE FUNCTIONELE ANALYSE DESIGN BUILD CI TEST ACCEPTATIE U n i t t e s t e n Test Process: - Test Design - Test Execution Templates: - Test Design Specifications - Test Case Specifications Tools: - JUnit4, Jmock, easymock - XML-unit Roles&Responsibilities: - Test Designer - Test Automation Engineer - Supplier Test Process: - Test Execution - Test Reporting - Test Controle Templates: - Test Log - Test Incident Report Tools: - Maven - SonarJ Roles&Responsibilities: - Tester - Supplier I n t e g r a t i e t e s t e n S y s t e e m t e s t e n Test Process: - Test Design Templates: - Test Design Specifications - Test Case Specifications Tools: - Selenium IDE - Selenium Bromine Roles&Responsibilities: - Test Designer - Test Automation Engineer - Supplier Test Process: - Test Design Templates: - Test Design Specifications - Test Case Specifications Tools: - Selenium IDE - Selenium Bromine Roles&Responsibilities: - Test Designer - Test Automation Engineer - Supplier Test Process: - Test Execution - Test Reporting - Test Controle Templates: - Test Log - Test Incident Report Tools: - Maven Roles&Responsibilities: - Tester - Supplier Test Process: - Test Execution - Test Reporting - Test Controle Templates: - Test Log - Test Incident Report Tools: - Selenium RC - Selenium Grid Roles&Responsibilities: - Tester - Supplier Test Process: - Test Execution - Test Reporting - Test Controle Templates: - Test Log - Test Incident Report Tools: - Selenium RC - Selenium Grid Roles&Responsibilities: - Tester - Supplier A c c e p t a t i e t e s t e n Test Process: - Test Design Templates: - Test Design Specifications - Test Case Specifications Tools: Roles&Responsibilities: - Test Designer - Test Automation Engineer - Supplier Test Process: - Test Execution - Test Reporting - Test Controle Templates: - Test Log - Test Incident Report Tools: Roles&Responsibilities: - Tester - Fedict