politique de test - bosa · 2018-11-26 · politique de test 5 1. introduction 1.1. objet de ce...

POLITIQUE DE TEST

Van Caneghem Wouter Analyste fonctionnel - Fedict

Dussart Dirk Architecte - Fedict

Politique de test

2

Table des matières

1. Introduction ....................................................................................................... 5

1.1. Objet de ce document .................................................................................... 5

1.2. Pourquoi des tests ? ....................................................................................... 5

1.3. Les tests ..................................................................................................... 6

1.4. Principes de base .......................................................................................... 6

2. Le processus de test et les responsabilités générales ..................................................... 8

2.1. Le modèle V de Fedict .................................................................................... 8

2.2. Niveaux de test ............................................................................................ 8

2.2.1. Analyses ............................................................................................... 9

2.2.2. Niveau test unitaire ................................................................................. 9

2.2.3. Niveau d'intégration............................................................................... 10

2.2.4. Niveau de test système ........................................................................... 10

2.2.5. Niveau de test d'acceptation .................................................................... 11

2.3. Types de test ............................................................................................. 11

2.3.1. Tests fonctionnels ................................................................................. 11

2.3.2. Tests non fonctionnels ............................................................................ 12

2.3.3. Tests liés à des modifications (tests de confirmation et tests de régression) .......... 12

2.4. Classification des techniques de test ................................................................ 12

2.5. Processus de test ........................................................................................ 13

2.6. Tests basés sur les risques ............................................................................. 13

2.7. Responsabilités........................................................................................... 14

2.7.1. Généralités ......................................................................................... 14

2.7.2. Niveaux de test inférieurs ....................................................................... 14

1.1.1.1. Tests d'intégration système ...................................................................... 15

2.7.3. Tests d'acceptation ............................................................................... 15

2.8. Gravité .................................................................................................... 15

3. Exigences pour le fournisseur ................................................................................ 17

3.1. Généralités ............................................................................................... 17

3.2. Contenu des produits de travail à livrer ............................................................. 17

3.3. Produits de travail à livrer (Deliverables) ........................................................... 18

3.3.1. Documents généraux .............................................................................. 18

3.3.2. Tests unitaires ..................................................................................... 18

3.3.3. Tests d'intégration ................................................................................ 19

3.3.4. Tests système ...................................................................................... 20

3.3.5. Tests d'acceptation ............................................................................... 21

Politique de test

3

3.4. Critères d’échelonnement ............................................................................. 22

3.4.1. Degré de couverture .............................................................................. 23

3.4.2. Critères pour passer en TEST .................................................................... 23

3.4.3. Critères pour passer en ACCEPTATION......................................................... 24

3.4.4. Critères pour passer en PRODUCTION .......................................................... 25

4. Recommandations pour le fournisseur ..................................................................... 26

4.1. Matrice de test ........................................................................................... 26

4.2. Scénario couverture ..................................................................................... 28

1.1. Rôles et responsabilités ................................................................................ 29

4.2.1. Responsable du test ............................................................................... 29

4.2.2. Architecte du test ................................................................................. 29

4.2.3. Concepteur du test ................................................................................ 29

4.2.4. Testeur .............................................................................................. 29

4.2.5. Ingénieur d'automatisation des tests........................................................... 29

4.2.6. Spécialiste de la méthodologie des tests ..................................................... 30

4.3. Outils ...................................................................................................... 30

4.3.1. Selenium ............................................................................................ 30

4.3.2. JUnit ................................................................................................. 31

4.3.3. Hudson............................................................................................... 31

4.3.4. Jenkins .............................................................................................. 31

4.4. Processus de test ........................................................................................ 32

4.4.1. Spécifications des tests .......................................................................... 32

4.4.2. Exécution des tests ............................................................................... 32

4.4.3. Rapport des tests .................................................................................. 33

4.5. Documentation des tests ............................................................................... 33

4.5.1. Plan de test ......................................................................................... 33

4.5.2. Spécifications de la conception des tests ..................................................... 34

4.5.3. Spécifications des tests .......................................................................... 34

4.5.4. Journal des tests .................................................................................. 34

4.5.5. Rapport d'incident de test ....................................................................... 34

4.5.6. Rapport du résumé du test ...................................................................... 34

5. Annexes .......................................................................................................... 35

5.1. Annexe 1 – Modèles ...................................................................................... 35

5.1.1. Utilisation des modèles ........................................................................... 35

5.1.2. Liste des modèles ................................................................................. 35

Politique de test

4

Date Version Description Auteur 11/10/2011 1.0 Premier avant-projet Wouter Van Caneghem 17/10/2011 1.1 Ajout du chapitre Outils Wouter Van Caneghem 21/10/2011 1.2 Ajout des rôles et responsabilités Wouter Van Caneghem 17/11/2011 1.3 Ajout des tests unitaires Diederik Delen 12/12/2011 1.4 Ajout de la matrice de test Wouter Van Caneghem 13/12/2011 1.5 Ajout des critères d’échelonnement Wouter Van Caneghem 27/02/2012 1.6 Mise à jour des critères

d’échelonnement et ajout de l'annexe Wouter Van Caneghem

5/03/2012 1.7 Mise à jour de la matrice de test Dirk Dussart 13/04/2012 1.8 Révision Coralius nv Coralius nv 14/05/2012 1.9 Modification des gravités Wouter Van Caneghem

Politique de test

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.

1.2. 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 »).

Politique de test

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.

1.3. 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.

1.4. 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. 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.

Politique de test

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.

8

2. Le processus de test et les responsabilités générales

2.1. LE MODELE V DE FEDIC

Le modèle V de Fedict illustre les niveaux de test utilisés et les responsabilités générales deet du fournisseur.

2.2. 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 q

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.

Exigences, analyse

professionnelle et cahier

des charges

Documents fonctionnels

Documents de conception

Politique de test

Le processus de test et les responsabilités

LE MODELE V DE FEDICT

Le modèle V de Fedict illustre les niveaux de test utilisés et les responsabilités générales de

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

ue son approche est au moins équivalente à l'approche décrite par Fedict.

Documents de conception

Test d’acceptation

Test d'intégration

système

Test d'intégration

des composants

Test système

Test unitaire/des

composants

Le processus de test et les responsabilités

Le modèle V de Fedict illustre les niveaux de test utilisés et les responsabilités générales de Fedict

Les niveaux de test sont des groupes d'activités de test qui sont gérés ensemble et qui sont en

ue 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

ue son approche est au moins équivalente à l'approche décrite par Fedict.

Test d’acceptation

Test d'intégration

Test d'intégration

Test unitaire/des

FO

UR

NIS

SE

UR

Politique de test

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.

2.2.1. 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.

2.2.2. 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.

Politique de test

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.

2.2.3. 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.

2.2.4. 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.

Politique de test

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).

2.2.5. 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.

2.3. TYPES DE TEST

2.3.1. 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.

Politique de test

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.

2.3.2. 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.

2.3.3. 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.

2.4. 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.

Politique de test

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.

2.5. 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.

2.6. 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.

Politique de test

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.

2.7. RESPONSABILITES

Nous indiquons dans cette section où se situent les responsabilités du fournisseur et de Fedict.

2.7.1. 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.

2.7.2. 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.

Politique de test

15

1.1.1.1. 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.

2.7.3. 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.

2.8. 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.

Politique de test

16

Critique (Critical)

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.

Élevée (High)

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]

Politique de test

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.

3.2. 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]

Politique de test

18

3.3. PRODUITS DE TRAVAIL A LIVRER (DELIVERABLES)

3.3.1. Documents généraux

3.3.1.1 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.

3.3.1.2 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.

3.3.1.3 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é.

3.3.2. 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

Politique de test

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

3.3.3. 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]

Politique de test

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é


3.3.4. 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é


Politique de test

21

3.3.5. 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.

Politique de test

22

3.3.5.1 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

• Tests (conception de test et spécifications de test) • Matrices de traçabilité • Rapport du résumé du test principal

Sortie (Deliverables) de Fedict

• 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

Politique de test

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.

3.4.1. 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.

3.4.2. 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

Politique de test

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.

3.4.3. Critères pour passer en ACCEPTATION

3.4.3.1 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.

3.4.3.2 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.

Politique de test

25

3.4.4. Critères pour passer en PRODUCTION

3.4.4.1 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.

3.4.4.2 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.

Politique de test

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.

4.1. 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.

BUSINESS

ANALYSE

FUNCTIONELE

ANALYSEDESIGN BUILD CI 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


- Tester

- Supplier

I

n

t

e

g

r

a

t

i

e

t

e

s

t

e

n

Test Process:

- Test Design

Templates:



Tools:

- Selenium IDE

- Selenium Bromine


- Test Designer


- Supplier

Test Process:

- Test Execution

- Test Reporting

- Test Controle

Templates:

- Test Log


Tools:

- Maven


- Tester

- Supplier

Test Process:

- Test Execution

- Test Reporting

- Test Controle

Templates:

- Test Log


Tools:

- Selenium RC

- Selenium Grid


- Tester

- Supplier

S

y

s

t

e

e

m

t

e

s

t

e

n

Test Process:

- Test Design

Templates:



Tools:

- Selenium IDE

- Selenium Bromine


- Test Designer


- Supplier

A

c

c

e

p

t

a

t

i

e

t

e

s

t

e

n

Test Process:

- Test Design

Templates:



Tools:


- Test Designer


- Supplier

Test Process:

- Test Execution

- Test Reporting

- Test Controle

Templates:

- Test Log


Tools:


- Tester

- Fedict

TEST

Test Process:

- Test Execution

- Test Reporting

- Test Controle

Templates:

- Test Log


Tools:

- Selenium RC

- Selenium Grid


- Tester

- Supplier

4.2. SCENARIO COUVERTURE

Cette section donne un exemple des attentes de Fedict concernant le degré de couverture, tant en ce qui concerne le niveau de détail de l'explication sur la mesure de la couverture qu'en ce qui concerne le degré de couverture même.

Un scénario est une instance d'un cas qui présente et décrit un chemin spécifique pour un flux d'événements. Dans la documentation fonctionnelle, chaque cas est représenté par un schéma d'activités. Outre le flux de base, il existe différents flux alternatifs et flux d'erreurs. Pour résumer tous les scénarios possibles, l'on doit dessiner toutes les lignes possibles sur le graphique. L'illustration ci-dessous présente un graphe hypothétique représentant un cas de flux de base B ainsi que les flux alternatifs A1, A2, A3 et A4. Il existe manifestement davantage de scénarios que de flux alternatifs parce qu'il y en a un pour A1, un autre pour A2 et un scénario pour la combinaison des 2.

Les boucles qui reviennent devraient en théorie fournir un nombre infini de scénarios. Nous optons donc pour celui-là pour réaliser une fois le flux de base. Ensuite la boucle une fois et enfin la boucle une deuxième fois. Si le programme fonctionne pour les deux instances de la boucle, nous supposons qu'il fonctionnera également si la boucle est parcourue plusieurs fois.

Politique de test

29

Le but n'est pas de tester tous ces flux mais une partie de ceux-ci.

- Le flux de base doit au moins être couvert par un scénario de test. - Un scénario de test doit également être prévu pour chaque flux alternatif. - Chaque boucle du scénario est parcourue 0, 1 et 2 fois dans un scénario de test.

1.1. ROLES ET RESPONSABILITES

Dans tout le processus de test, les différentes activités seront réalisées par des personnes remplissant un rôle spécifique. En effet, chaque activité requiert des compétences spécifiques.

Nous décrivons dans cette section les rôles les plus importants. Cela donne au fournisseur une idée des compétences et profils nécessaires pour tester de manière adéquate et structurée. Il est possible qu'une même personne occupe plusieurs rôles.

4.2.1. Responsable du test

Le responsable du test est responsable de tout le processus de test. Il doit veiller à ce que les différentes phases de test soient réalisées correctement. Que les différentes ressources soient utilisées de manière optimale et que les décisions correctes soient prises sur la base des rapports. Dans la pratique, il est responsable jusqu'à la rédaction et l'implémentation du plan de test.

4.2.2. Architecte du test

L'architecte du test doit formuler une architecture de test intégrée soutenant tout le processus de test et utilisant l'infrastructure de test. Dans la pratique, il donnera son avis concernant les environnements de test, les outils, l'automatisation, etc.

4.2.3. Concepteur du test

Le concepteur du test doit documenter les tests. Il procède sur la base des exigences et les convertit en tests concrets qui peuvent être réalisés par le testeur ou être transformés en scripts automatiques.

4.2.4. Testeur

Le testeur réalise les différents tests, fait rapport des résultats, consigne les défauts et exécute l'analyse de couverture du test. Dans la pratique, cela doit être une personne différente pour chaque niveau de test. Il s'agit principalement d'analystes commerciaux, d'analystes fonctionnels, d'architectes et de développeurs ou d'experts des tests.

4.2.5. Ingénieur d'automatisation des tests

L'ingénieur d'automatisation des tests doit décrire les tests par l'automatisation de la conception des tests à l'aide des outils proposés par l'architecte des tests. Dans la pratique, il s'agit d'analystes, d'architectes et de développeurs.

Politique de test

30

4.2.6. Spécialiste de la méthodologie des tests

Le spécialiste de la méthodologie des tests est chargé de définir et de tenir à jour la méthodologie utilisée pour les tests. Sur la base des résultats d'un processus de test, la méthodologie est adaptée le cas échéant. Il évalue la stratégie de test, fournit les modèles et veille à ce que la méthodologie soit appliquée dans la pratique.

4.3. OUTILS

Nous illustrons ci-dessous une série d'outils qui peuvent être utilisés pour simplifier et accélérer les tests. Nous conseillons aux fournisseurs, pour chacun des outils qu'ils utilisent, de tenir compte du retour sur investissement ainsi que des formations et du temps d'apprentissage nécessaires.

Cette section se base sur les informations de Wikipedia.

4.3.1. Selenium

La suite selenium comprend plusieurs parties.

Selenium IDE : environnement de développement intégré pour les scripts Selenium. Il est implémenté comme une extension firefox et permet d'enregistrer, d'éditer et de déboguer des cas de test.

Selenium RC : outil de test qui permet d'écrire des tests d'interface utilisateur d'application web automatiquement dans n'importe quel langage de programmation. Pour n'importe quel site Internet http à l'aide d'un navigateur activé javascript.

Selenium Grid : outil qui permet d'effectuer plusieurs cas de test en parallèle sur plusieurs machines et dans un environnement hétérogène.

Selenium Bromine : un outil d'assurance qualité basé sur le web pour Selenium. Il permet d'effectuer des tests Selenium RC et d'en analyser les résultats.

Si nous fusionnons tous ces composants, nous obtenons l'architecture logique suivante avec 1/ l'exécution automatique des tests et 2/ l'exécution manuelle des tests :

Politique de test

31

4.3.2. JUnit

JUnit est un cadre de test unitaire pour le langage de développement Java. Il est important dans le développement piloté par des tests. JUnit est une instance de l'architecture xUnit pour les cadres de tests unitaires.

4.3.3. Hudson

Hudson est un outil d'intégration continue écrit en Java qui tourne dans un conteneur de servlets, comme Apache Tomcat ou un serveur d'application GlassFish. Il prend en charge des outils SCM tels que CVS, Subversion, Git et Clearcase. Il peut également exécuter des projets basés Apache Ant et Apache Maven.

4.3.4. Jenkins

Jenkins est un outil d'intégration continue d'exploitation libre écrit en Java. Jenkins offre des services d'intégration continue pour des développements logiciels principalement écrits en Java. Il s'agit d'un système basé serveur qui tourne dans un conteneur de servlets, comme Apache Tomcat. Il prend en charge des outils SCM tels que CVS, Subversion, Git, Mercurial, Perforce et Clearcase. Il peut également exécuter des projets basés Apache Ant et Apache Maven.

Politique de test

32

4.4. PROCESSUS DE TEST

Nous illustrons dans cette section un processus de test simple basé sur IEEE-829 que le fournisseur peut utiliser pour satisfaire aux exigences posées dans ce document.

Nous distinguons trois phases dans le processus de test :

• « Spécifications du test » • « Exécution du test » • « Rapport du test »

Le but est de parcourir ces trois phases. Chaque phase possède ses propres activités et générera des documents spécifiques.

4.4.1. Spécifications des tests

Les spécifications des tests peuvent être scindées en deux parties. D'une part, « Planning et contrôle » et d'autre part, « Analyse, conception et implémentation ». La partie planning et contrôle est l'activité de vérification de la mission, de définition des objectifs et des spécifications des activités de test pour répondre aux objectifs. Le contrôle est un processus continu de comparaison des requêtes actuelles vis-à-vis du plan de test et de rapport du statut, y compris les modifications du plan de test. Planning et contrôle peuvent contenir les activités suivantes :

- Détermination de la portée et des risques et définition des objectifs des tests. - Définition de la stratégie. - Décisions sur les éléments à tester, les rôles, le déroulement des activités de test et la

manière dont les résultats des tests sont implémentés. - Planning des activités de conception des tests. - Planning de l'exécution et de l'évaluation.

Pendant l'analyse, la conception et l'implémentation, les objectifs des tests seront transformés en conditions de tests et tests concrets. Cela peut comprendre les activités suivantes :

- Analyse de la base des tests (comme les exigences, l'architecture, la conception, les interfaces).

- Évaluation de la testabilité de la base et des objets des tests. - Identification et priorisation des conditions des tests. - Conception des tests - Identification des données de test nécessaires pour soutenir les tests. - Conception de l'environnement de test et identification des infrastructures et des outils.

4.4.2. Exécution des tests

L'exécution des tests est la phase où les procédures de test et les scripts sont réalisés et où les résultats (y compris les incidents) sont consignés. Cela peut comprendre les activités suivantes :

- Exécution des tests, manuellement ou via un outil. - Consignation des résultats de l'exécution.

Politique de test

33

- Comparaison des résultats avec le résultat attendu. - Rapport des problèmes sous la forme d'incidents et leur analyse pour en connaître la cause. - Répétition des tests comme conséquence des incidents décelés.

4.4.3. Rapport des tests

Le rapport des tests est la phase où l'exécution des tests est comparée aux objectifs. Cela peut comprendre les tâches suivantes :

- Le contrôle des journaux des tests et de la liste des défauts par rapport aux critères spécifiés dans le plan de test.

- Vérifier si des tests supplémentaires sont nécessaires. - Rédaction d'un rapport de résumé.

4.5. DOCUMENTATION DES TESTS

Différents documents doivent être créés pendant le déroulement du processus de test. Nous décrivons ces documents ci-dessous. Il existe pour chacun de ces documents un modèle qui peut servir de fil conducteur.

4.5.1. Plan de test

Le plan de test contient une description de la manière dont les tests sont gérés, planifiés et exécutés. Un plan de test est un document qui est adapté tout au long du cycle de test complet et qui décrit ce qui doit se passer, selon quelle norme de qualité, avec quelles ressources, selon quelle échelle de temps, et indique quels sont les risques et comment ceux-ci peuvent être résolus.

Nous attendons au moins les informations suivantes dans un plan de test :

- S Scope (Portée) : ce qui doit être testé et ce qui ne doit pas l'être. - P People (Personnel) : formation, responsabilités et planning. - A Approach (Approche) : approche suivie pour les tests. - C Criteria (Critères) : critères d'entrée/sortie et critères de suspension/reprise. - E Environment (Environnement) : exigences des environnements de test. - D Deliverables (Produits) : ce qui est livré dans le cadre du processus de test. - I Incidentals (Frais accessoires) : introduction, identification et approbation. - R Risks (Risques) : risques qui peuvent se produire. - T Tasks (Tâches) : activités de test.

Il est possible de définir un plan de test principal valable pour tout le processus de test. Mais on peut également choisir de définir un plan de test par niveau de test. Par exemple un plan de test pour les tests unitaires, les tests système, etc. Le choix est libre.

En effet, indépendamment du choix ci-dessus, on doit savoir avec certitude ce qui doit être testé précisément à quel niveau de test.

Politique de test

34

4.5.2. Spécifications de la conception des tests

Le document de spécification de la conception des tests décrit à un niveau logique ce qui doit être testé à l'aide des exigences. Ces exigences sont transformées en conditions de test concrètes.

Ce document ne contient pas de données de test ou une description de la manière dont les conditions de test peuvent être testées. Il décrit les exigences pour ces données de test et constitue simplement un lien entre les exigences et les tests.

4.5.3. Spécifications des tests

Les spécifications des tests sont les conditions de test à joindre aux tests concrets en y ajoutant des données de test, des pré-conditions et les résultats attendus. Les tests peuvent être réalisés lorsque la conception des tests est terminée. Un test peut comprendre une ou plusieurs conditions de test. Un test doit contenir :

- Les données de test nécessaires pour exécuter le test. Ceci est une combinaison des données d'entrée, des données d'application et des données système.

- Le résultat attendu et le résultat. - Les pré-conditions qui déterminent le point de départ de chaque test. - Le plan par étapes qui doit être suivi pour exécuter le test.

4.5.4. Journal des tests

Le journal des tests conserve les détails des tests réalisés et des résultats de ceux-ci. Cela peut d'une part signifier qu'un test est réussi, ce qui signifie que le résultat attendu est identique au résultat réel obtenu. D'autre part, cela peut signifier qu'un test a échoué. Cela a pour conséquence qu'un rapport d'incident de test doit être créé et que les détails du problème doivent y être décrits. Un journal de test suit l'évolution de l'exécution du test et donne également des informations sur la cause des incidents.

4.5.5. Rapport d'incident de test

Le rapport d'incident de test documente tout incident qui doit être analysé. Les incidents apparaissent dans le journal de test. Le rapport d'incident de test doit contenir tous les détails de l'incident tels que le résultat attendu et le véritable résultat, lorsqu'il a échoué, et toutes les informations qui peuvent aider à résoudre l'incident. Ce rapport peut éventuellement également avoir un impact sur le test de l'incident.

4.5.6. Rapport du résumé du test

Le rapport du résumé du test contient les résultats des activités de test et l'évaluation des résultats. Cela donne une image globale des activités de test et de la qualité du logiciel.

Politique de test

35

5. Annexes

5.1. ANNEXE 1 – MODELES

Cette politique comporte plusieurs modèles. Ils sont livrés sous la forme de fichiers distincts et sont tous rédigés en anglais. Reportez-vous au point 5.1.2 pour la liste des modèles.

5.1.1. Utilisation des modèles

Le but est d'utiliser les modèles comme liste de contrôle pour vérifier que les documents livrés contiennent suffisamment d'informations et les informations correctes.

Le texte bleu plus clair dans les modèles contient des indications (guidance) et doit être interprété de manière pragmatique. évitez les redondances et toute prolixité superflue dans tous les documents.

Si une section complète n'est pas d'application, il suffit d'ajouter la mention « sans objet » ou s.o., suivie d'une brève explication (généralement 1 ligne maximum) de la raison.

Il est autorisé, mais pas obligatoire, d'utiliser ces modèles pour établir les documents correspondants. Dans de nombreux cas (par exemple pour les rapports d'incident, les spécifications des tests et le journal de test) il est probablement plus efficace d'utiliser les outils adéquats que de traiter ces informations sous forme de document.

5.1.2. Liste des modèles

• Modèle Spécifications des tests. • Modèle Spécifications de la conception des tests. • Modèle Rapport des incidents des tests. • Modèle Journal des tests. • Modèle Rapport de résumé des tests. • Modèle Plan des tests.