Gestion des tests logiciels - fnac-static.comGestion des tests logiciels pour l’industrialisation des tests Gestionjets fonctionnels des tests logiciels Gestion des tests logiciels

Emmanuel ITIÉ

45 €

isbn

: 978

-2-4

09-0

0030

-0

Bonnes pratiques à mettre en œuvre pour l’industrialisation des tests

Ges

tion

des t

ests

logi

ciel

s Gestion des tests logiciels

Gestion des tests logiciels Bonnes pratiques à mettre en œuvre pour l’industrialisation des testsCe livre sur la gestion des tests logiciels s’adresse principalement aux Chefs de pro-jets fonctionnels, Assistants Maîtrise d’Ouvrage et éventuellement aux Déve-loppeurs, qui souhaitent embrasser l’ensemble des processus de recette indépen-damment de leur niveau préalable de connaissances sur le sujet.L’objectif de ce livre est donc unique : permettre au lecteur d’assimiler tant la théorie que la pratique des tests afin de lui donner les moyens de les mettre en œuvre concrètement ensuite : évaluation des charges, bilan des tests en passant par l’organisation, la préparation et l’exécution des tests. L’auteur présente aussi bien les tests pour les applications Web que pour les terminaux mobiles, les flux et les traitements de masse.Ce livre est la description des bonnes pratiques à mettre en œuvre dans les dif-férentes situations qu’un chef de projet sera amené à gérer. Il est le fruit d’un retour de 18 ans d’expérience : il ne se veut pas une vague théorie industrielle appliquée mais le résultat d’une succession d’échecs, de tâtonnements, d’échanges avec d’autres ingénieurs, développeurs et acteurs de tout type à commencer par le plus important de tous : le client, l’utilisateur final.Cette nouvelle édition propose la mise en œuvre de cette méthodologie dans l’outil gratuit ProjeQtOr.Des kits méthodologiques avec des modèles de documents qui vous permet-tront de passer de la théorie à la pratique sont en téléchargement sur www.editions-eni.fr.

Emmanuel ITIÉ, est titulaire d’une maîtrise d’informatique de l’Université de Montpellier avec une spécialisation en algo-rithmique renforcée et théorie des langages. Il s’est intéressé très tôt à l’expertise en homo-logation, pressentant l’avenir de ce marché. Aujourd’hui, chef d’entreprise et consultant indé-pendant, il prend en charge des missions d’accompagnement au changement, notamment pour la mise en œuvre de processus d’amélioration de la qualité logicielle chez plusieurs acteurs importants du e-Commerce.

Téléchargementwww.editions-eni.fr.fr

sur www.editions-eni.fr : b Kits méthodologiques permettant :

de conduire des tests unitaires de conduire une recette d’urgence de conduire une recette technico-fonctionnelle

Avant-propos • Généralités • Organiser les tests unitaires • Définir un périmètre de tests : la stratégie • Gérer les données : la principale contrainte • Organiser une recette • Gérer les observations • Piloter une recette • Outiller une recette sous ProjeQtOr • Kits pratiques et exemple commenté

Les chapitres du livre

2e édition

Nouvelle édition

Pour plus d’informations :

1Table des matières

Avant-propos 1. Pourquoi ce livre ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2. Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3. Avertissements : pourquoi une réédition ? . . . . . . . . . . . . . . . . . . . . . 22

Chapitre 1Généralités

1. Principaux concepts et cycle projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.1.1 Premières considérations : parlons la même langue ! . . . 231.1.2 Schéma général du cycle projet. . . . . . . . . . . . . . . . . . . . . 24

1.2. L'avant-projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.2.1 Étude d'opportunité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.2.2 Étude d'impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.2.3 Le choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.3. Le projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.3.1 Lancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.3.2 Conception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.3.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.3.4 Recette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351.3.5 Recette fonctionnelle ou métier . . . . . . . . . . . . . . . . . . . . 361.3.6 Recette usine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371.3.7 Recette d'homologation ou VABF . . . . . . . . . . . . . . . . . . 371.3.8 Déploiement et montée en charge . . . . . . . . . . . . . . . . . . 39

Les exemples à télécharger sont disponibles à l'adresse suivante :http://www.editions-eni.fr

Saisissez la référence ENI de l'ouvrage DP2GTL dans la zone de rechercheet validez. Cliquez sur le titre du livre puis sur le bouton de téléchargement.

2 Gestion des tests logiciels

1.4. L'après-projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.4.1 Clôture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.4.2 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2. Types de test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.1. Pendant le projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.1.1 Relecture des spécifications . . . . . . . . . . . . . . . . . . . . . . . 412.1.2 Types de tests unitaires. . . . . . . . . . . . . . . . . . . . . . . . . . . 422.1.3 Types de tests techniques . . . . . . . . . . . . . . . . . . . . . . . . . 442.1.4 Tests d'intégration ou d'interface . . . . . . . . . . . . . . . . . . . 482.1.5 Tests de validation fonctionnelle . . . . . . . . . . . . . . . . . . . 48

2.2. Et après le projet ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.2.1 Tester la performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.2.2 La maintenance : les tests de non-régression. . . . . . . . . . 512.2.3 Capitaliser le référentiel de tests. . . . . . . . . . . . . . . . . . . . 51

3. Contextes de mise en œuvre des tests . . . . . . . . . . . . . . . . . . . . . . . . 523.1. Côté maîtrise d'œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.1.1 Maîtrise d'œuvre externe . . . . . . . . . . . . . . . . . . . . . . . . . 523.1.2 Maîtrise d'œuvre interne. . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2. Côté maîtrise d'ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.1 Maîtrise d'ouvrage externe ou interne non mature

en tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.2 Maîtrise d'ouvrage interne mature en tests . . . . . . . . . . . 54

3.3. Cas d'une cellule de tests indépendante . . . . . . . . . . . . . . . . . . . 543.3.1 Cellule externe à l'entreprise . . . . . . . . . . . . . . . . . . . . . . . 543.3.2 Cellule interne à l'entreprise . . . . . . . . . . . . . . . . . . . . . . . 55

Chapitre 2Organiser les tests unitaires

1. Organisations possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571.1. Le développeur livré à lui-même, seul ou en équipe . . . . . . . . . . 57

1.1.1 Hiérarchiser son travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 581.1.2 Mesurer le temps passé . . . . . . . . . . . . . . . . . . . . . . . . . . . 59


1.2. Le travail en équipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601.2.1 Sensibiliser l'équipe : le rôle du chef de projet . . . . . . . . . 601.2.2 S'assurer que les besoins en test sont couverts . . . . . . . . 611.2.3 Anticiper les dépendances de tâches. . . . . . . . . . . . . . . . . 611.2.4 Les tests croisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2. Tests unitaires élémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.1. Tester un écran ou un formulaire . . . . . . . . . . . . . . . . . . . . . . . . 63

2.1.1 Libellés statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.1.2 Libellés dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.1.3 Champs cachés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.1.4 Liens et images cliquables . . . . . . . . . . . . . . . . . . . . . . . . . 642.1.5 Champs alphanumériques . . . . . . . . . . . . . . . . . . . . . . . . 652.1.6 Champs multilignes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662.1.7 Champs numériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672.1.8 Champs de type date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672.1.9 Champs de type heure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 692.1.10 Champs de type numéro de semaine . . . . . . . . . . . . . . . . 692.1.11 Listes déroulantes et non déroulantes . . . . . . . . . . . . . . . 692.1.12 Boutons radio, cases à cocher

et autres composants graphiques . . . . . . . . . . . . . . . . . . . 702.2. Tester un flux ou un traitement de masse . . . . . . . . . . . . . . . . . 70

2.2.1 Pouvoir exécuter le traitement "à blanc" . . . . . . . . . . . . . 712.2.2 Vérifier la volumétrie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.2.3 Tests par échantillonnage . . . . . . . . . . . . . . . . . . . . . . . . . 732.2.4 Tests étendus, tests fragmentés . . . . . . . . . . . . . . . . . . . . 74

3. Formaliser les tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.1. Dans un projet géré en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.1.1 Pourquoi formaliser les tests unitaires ?. . . . . . . . . . . . . . 753.1.2 Le rapport de tests unitaires . . . . . . . . . . . . . . . . . . . . . . . 76

3.2. Validation en méthodes Agiles . . . . . . . . . . . . . . . . . . . . . . . . . . 773.2.1 Rappel des principes des méthodes Agiles . . . . . . . . . . . . 773.2.2 Le flux des stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.2.3 La formalisation des tests dans le backlog . . . . . . . . . . . . 81


3.2.4 Validation des stories et périmètre des tests après livraison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4. Risques projet liés à la gestion des tests unitaires . . . . . . . . . . . . . . . 834.1. Impact sur la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.1.1 Vers une augmentation de la charge de réalisation ? . . . 834.1.2 Prendre le risque de la sur-qualité. . . . . . . . . . . . . . . . . . . 84

4.2. Impact sur l'équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.2.1 Une meilleure cohésion, de meilleures performances . . . 844.2.2 Prendre le risque de démotiver l'équipe . . . . . . . . . . . . . . 85

Chapitre 3Définir un périmètre de tests : la stratégie

1. Périmètre fonctionnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871.1. Parties prenantes, risques et exigences . . . . . . . . . . . . . . . . . . . . 88

1.1.1 Lister les parties prenantes . . . . . . . . . . . . . . . . . . . . . . . . 881.1.2 Lister les risques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881.1.3 Lister les exigences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

1.2. Hiérarchiser le périmètre fonctionnel . . . . . . . . . . . . . . . . . . . . . 931.2.1 Qu'est-ce qu'une criticité ? Qu'est-ce qu’une priorité ?. . 931.2.2 Rapprocher les risques des exigences . . . . . . . . . . . . . . . . 981.2.3 Matrice de criticité et périmètre

d'une recette fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 1021.2.4 Matrice de criticité et périmètre théorique

d'une recette technique . . . . . . . . . . . . . . . . . . . . . . . . . . 1051.2.5 Exigence fonctionnelle, technique et niveau de test . . . 107

2. Périmètre disponible : gérer les dégradations . . . . . . . . . . . . . . . . . . 1102.1. Environnement dégradé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

2.1.1 Des traitements en moins . . . . . . . . . . . . . . . . . . . . . . . . 1112.1.2 Des données en moins. . . . . . . . . . . . . . . . . . . . . . . . . . . 113


2.2. Application dégradée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142.2.1 Mode de fonctionnement d'une application . . . . . . . . . 1142.2.2 Suppression de composants externes,

dégradation de version . . . . . . . . . . . . . . . . . . . . . . . . . . 1172.2.3 Dégradation des applications web . . . . . . . . . . . . . . . . . 118

2.3. Périmètre de tests et dégradations. . . . . . . . . . . . . . . . . . . . . . . 1192.3.1 Améliorer la matrice du périmètre des tests . . . . . . . . . 1192.3.2 Représentation du périmètre des tests

et des dégradations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

3. Périmètre des configurations matérielles . . . . . . . . . . . . . . . . . . . . . 1223.1. La gestion des configurations matérielles . . . . . . . . . . . . . . . . . 123

3.1.1 En recette fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . 1233.1.2 En recette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243.1.3 Pour quel résultat ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253.1.4 Quelle stratégie adopter ? . . . . . . . . . . . . . . . . . . . . . . . . 127

3.2. Quelques retours d'expérience . . . . . . . . . . . . . . . . . . . . . . . . . . 1303.2.1 Les clients lourds sur PC et les applications Java. . . . . . 1303.2.2 Les applications web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1323.2.3 Pocket PC et Palm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1353.2.4 Des architectures très variées : iPhone, smartphone… . 136

4. Périmètres thématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394.1. Tester l'ergonomie et le ressenti graphique global . . . . . . . . . . 140

4.1.1 Tester la navigation : les applications web . . . . . . . . . . 1404.1.2 Tester la cinématique : les clients lourds . . . . . . . . . . . . 141

4.2. Tester le multilinguisme, la langue d'une application . . . . . . . 1424.2.1 Les fautes d'orthographe . . . . . . . . . . . . . . . . . . . . . . . . . 1424.2.2 Le multilinguisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142


Chapitre 4Gérer les données : la principale contrainte

1. Définir des jeux d'essai pertinents . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451.1. Construire le périmètre des données . . . . . . . . . . . . . . . . . . . . . 147

1.1.1 Démarche de construction des jeux de donnéesd'une recette fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 147

1.1.2 Démarche de construction des jeux de donnéesd'une recette technique . . . . . . . . . . . . . . . . . . . . . . . . . . 153

1.1.3 Impact de l'organisation sur la constitution du jeu d'essai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

1.1.4 Impact du planning projet sur la constitution du jeu d'essai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

1.1.5 Anticiper la consommation des données . . . . . . . . . . . . 1601.1.6 Dépendances fonctionnelles et jeux d'essai . . . . . . . . . . 1631.1.7 Impact du support technique du jeu de données . . . . . 1641.1.8 Un jeu d'essai qui a du sens. . . . . . . . . . . . . . . . . . . . . . . 165

1.2. Sauvegardes et restaurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671.2.1 Intérêts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671.2.2 Les limites et inconvénients . . . . . . . . . . . . . . . . . . . . . . 1681.2.3 Un service à offrir ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

2. Les données en environnement dégradé . . . . . . . . . . . . . . . . . . . . . . 1692.1. Modifier le jeu de données en cours d'exécution . . . . . . . . . . . 170

2.1.1 Qu'est-ce qu'une simulation ?. . . . . . . . . . . . . . . . . . . . . 1702.1.2 Comment gérer les simulations ? . . . . . . . . . . . . . . . . . . 1702.1.3 Les limites des simulations . . . . . . . . . . . . . . . . . . . . . . . 172

2.2. Les bouchons : des données artificielles . . . . . . . . . . . . . . . . . . 1732.2.1 Qu'est-ce qu'un bouchon ? . . . . . . . . . . . . . . . . . . . . . . . 1732.2.2 Un exemple concret : un système de banque en ligne . 1742.2.3 Comment gérer des bouchons lors d'une recette ? . . . . 1752.2.4 Les limites des tests des applications bouchonnées. . . . 176

2.3. Impact sur le bilan des tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762.3.1 Décrire ce qui n'a pas pu être testé . . . . . . . . . . . . . . . . . 1762.3.2 Émettre des réserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177


2.3.3 Déterminer une stratégie de continuité . . . . . . . . . . . . . 178

Chapitre 5Organiser une recette

1. Concepts généraux dans l'organisation du travail . . . . . . . . . . . . . . 1791.1. Le diagramme de Crosby Turtle . . . . . . . . . . . . . . . . . . . . . . . . 1791.2. Les diagrammes de PERT et de GANTT . . . . . . . . . . . . . . . . . . 1801.3. Les types de recette. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

2. La recette "pompier" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832.1. Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

2.1.1 Quand ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832.1.2 Pourquoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

2.2. Gérer une recette d'urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842.2.1 ORGANISER - Définir un périmètre

de manière pragmatique . . . . . . . . . . . . . . . . . . . . . . . . . 1842.2.2 PRÉPARER - Est-il utile de formaliser les tests ? . . . . . . 1852.2.3 EXÉCUTER - Collecter les anomalies

de manière centralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 1862.2.4 EXÉCUTER - L'équipe de développement

est un partenaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1862.2.5 CLÔTURER - Mettre en place un protocole

d'acceptation pour les prochaines livraisons . . . . . . . . . 187

3. La recette d'un patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883.1. Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

3.1.1 Quand ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883.1.2 Quelles contraintes ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

3.2. Gérer la recette d'un patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1893.2.1 ORGANISER - Définir un périmètre . . . . . . . . . . . . . . . 1893.2.2 PRÉPARER - Est-il utile de formaliser les tests ? . . . . . . 1913.2.3 EXÉCUTER - Doit-on formaliser les anomalies

d'un patch ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191


3.2.4 CLÔTURER - Comment gérer les anomalies d'un patch ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

3.2.5 CLÔTURER - Gérer une cartographie et les livraisons . 192

4. La recette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1944.1. Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

4.1.1 Quand ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1944.1.2 Pourquoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1944.1.3 Vers une professionnalisation. . . . . . . . . . . . . . . . . . . . . 195

4.2. Gérer la recette technique d'une release . . . . . . . . . . . . . . . . . . 1964.2.1 ORGANISER - L'étape la plus critique. . . . . . . . . . . . . . 1964.2.2 PRÉPARER - Anticiper la capitalisation. . . . . . . . . . . . . 2014.2.3 EXÉCUTER - S'appuyer sur un plan

de test réutilisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2054.2.4 CLÔTURER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

4.3. Gérer la recette technique d'une maintenance évolutive . . . . . 2104.3.1 ORGANISER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2114.3.2 PRÉPARER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2144.3.3 EXÉCUTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2154.3.4 CLÔTURER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

5. La recette fonctionnelle "pure" ou VABF. . . . . . . . . . . . . . . . . . . . . . 2175.1. Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

5.1.1 Quand ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2175.1.2 Pourquoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

5.2. Gérer la recette fonctionnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . 2185.2.1 ORGANISER - Formaliser une homologation. . . . . . . . 2185.2.2 PRÉPARER - Mettre l'accent sur le jeu d'essai . . . . . . . . 2205.2.3 EXÉCUTER - Prendre un recul fonctionnel. . . . . . . . . . 2205.2.4 CLÔTURER - Homologuer ou ne pas homologuer ? . . 221


Chapitre 6Gérer les observations

1. Rappels importants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2231.1. Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

1.1.1 L'observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2231.1.2 Anomalie, bug, dysfonctionnement

et non-conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2251.1.3 La demande d'évolution . . . . . . . . . . . . . . . . . . . . . . . . . 227

1.2. Processus documentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2281.2.1 Les états d'un document . . . . . . . . . . . . . . . . . . . . . . . . . 2281.2.2 Processus et formalisation : de l'usage des graphes

d'états finis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2291.2.3 Les triggers (déclencheurs) . . . . . . . . . . . . . . . . . . . . . . . 2301.2.4 Les notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

1.3. Les processus de gestion des observations : un survol . . . . . . . 2321.3.1 Les incidents de production . . . . . . . . . . . . . . . . . . . . . . 2321.3.2 Les demandes d'évolution . . . . . . . . . . . . . . . . . . . . . . . . 2331.3.3 Les observations faites pendant une recette

fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2331.3.4 Les observations faites pendant une recette technique . 234

2. Processus de gestion des incidents de production . . . . . . . . . . . . . . 2352.1. Principes organisationnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

2.1.1 Formaliser le ou les workflows documentaires . . . . . . . 2352.1.2 Définir un support de collecte : outil ou

simple fichier ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2382.1.3 Interactions avec la collecte des demandes d'évolution . 2382.1.4 La gestion des dépendances transverses . . . . . . . . . . . . . 238

2.2. Les risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2392.2.1 Confondre incident et demande d'évolution . . . . . . . . . 2392.2.2 Ne pas valoriser la criticité de signalement . . . . . . . . . . 2402.2.3 Ne pas détecter une dépendance . . . . . . . . . . . . . . . . . . 2412.2.4 Mal implémenter le processus dans un outil . . . . . . . . . 2412.2.5 Abandonner l'usager, ne pas le former . . . . . . . . . . . . . . 242


3. Les anomalies remontées par la maîtrise d'ouvrage . . . . . . . . . . . . . 2433.1. Principes organisationnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

3.1.1 Avec ou sans équipe de recette technique ? . . . . . . . . . . 2433.1.2 Définir un support de collecte . . . . . . . . . . . . . . . . . . . . 2433.1.3 Formalisation du processus. . . . . . . . . . . . . . . . . . . . . . . 2443.1.4 Le lotissement des corrections : préparer

les vérifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2463.2. Les risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

3.2.1 Ne pas indiquer clairement que l'anomalie a une origine métier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

3.2.2 Mal implémenter l'outil . . . . . . . . . . . . . . . . . . . . . . . . . 2473.2.3 Mal gérer les retours . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

4. Les anomalies détectées lors d'une recette technique. . . . . . . . . . . . 2484.1. Principes organisationnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

4.1.1 Formaliser le workflow documentaire . . . . . . . . . . . . . . 2494.1.2 Définir un support de collecte : outil ou

simple fichier ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2514.1.3 Interactions avec la collecte des demandes d'évolution . .2524.1.4 Gérer les points de blocage . . . . . . . . . . . . . . . . . . . . . . . 2534.1.5 Gérer les retours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

4.2. Les risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2554.2.1 Mal paramétrer un outil (encore et toujours) . . . . . . . . 2554.2.2 Doubler le processus de livraison dans l'outil . . . . . . . . 2564.2.3 Ne pas être pertinent. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2574.2.4 Émettre un flux inconstant, mal communiquer

avec la MOE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Chapitre 7Piloter une recette

1. Le pilotage budgétaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2611.1. La recette technique d'un projet de release . . . . . . . . . . . . . . . . 262

1.1.1 Évaluer la charge de l'organisation . . . . . . . . . . . . . . . . . 2621.1.2 Évaluer la charge de la préparation. . . . . . . . . . . . . . . . . 262


1.1.3 Évaluer la charge de l'exécution . . . . . . . . . . . . . . . . . . . 2651.1.4 Évaluer la charge de la clôture. . . . . . . . . . . . . . . . . . . . . 2671.1.5 Cas particulier des tests automatiques . . . . . . . . . . . . . 2671.1.6 Ajouter la charge de pilotage. . . . . . . . . . . . . . . . . . . . . . 2681.1.7 Suivre la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

1.2. La recette technique d'un projet de maintenance. . . . . . . . . . . 2721.2.1 Évaluer la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2721.2.2 Suivre la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

1.3. La recette fonctionnelle ou VABF . . . . . . . . . . . . . . . . . . . . . . . 2741.3.1 Évaluer la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2741.3.2 Suivre la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

2. Risques et reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2762.1. Les risques d'un projet de recette . . . . . . . . . . . . . . . . . . . . . . . . 276

2.1.1 En recette fonctionnelle ou VABF . . . . . . . . . . . . . . . . . 2762.1.2 En recette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2762.1.3 Suivre les risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

2.2. Le formalisme du reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Chapitre 8Outiller une recette sous ProjeQtOr

1. Prérequis à installer et avertissements. . . . . . . . . . . . . . . . . . . . . . . . 2811.1 Installer Wamp puis ProjeQtOr. . . . . . . . . . . . . . . . . . . . . . . . . 281

1.1.1 Installer Wamp : votre plateforme technique . . . . . . . . 2811.1.2 Installer ProjeQtOr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

1.2 Modifier les types de ProjeQtOr . . . . . . . . . . . . . . . . . . . . . . . . 2891.2.1 Type de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2891.2.2 Type de tickets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2901.2.3 Type d'activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2921.2.4 Type de jalons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2931.2.5 Type de risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2941.2.6 Type de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2951.2.7 Type de contextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297


1.2.8 Type d'exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2981.2.9 Type de cas de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2991.2.10 Type de sessions de test . . . . . . . . . . . . . . . . . . . . . . . . . 301

1.3 Modifier les listes de valeurs de ProjeQtOr. . . . . . . . . . . . . . . . 3041.3.1 Les sévérités, probabilités et criticités d'un risque . . . . . 3041.3.2 Les priorités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3081.3.3 L'urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3101.3.4 Les fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3131.3.5 Les niveaux de qualité et situations d'un projet . . . . . . 3141.3.6 Les niveaux de risque. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3151.3.7 Autres listes à connaître . . . . . . . . . . . . . . . . . . . . . . . . . 316

1.4 Fonctions clés à connaître . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3161.4.1 Paramètres globaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3161.4.2 Paramétrage des calendriers : les jours fériés . . . . . . . . . 3171.4.3 Habilitations, profils et accès . . . . . . . . . . . . . . . . . . . . . 3171.4.4 Lancer les CRON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

2. Organiser des projets de test dans ProjeQtOr . . . . . . . . . . . . . . . . . 3192.1 Importer des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3192.2 Gérer les produits et composants . . . . . . . . . . . . . . . . . . . . . . . 321

2.2.1 Gérer les composants. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3212.2.2 Gérer les versions des composants . . . . . . . . . . . . . . . . . 3222.2.3 Gérer les produits et sous-produits. . . . . . . . . . . . . . . . . 3242.2.4 Gérer les versions des produits . . . . . . . . . . . . . . . . . . . . 326

2.3 Définir les équipes de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3282.3.1 Les équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3282.3.2 Les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3292.3.3 Les ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3302.3.4 Les contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

2.4 Définir la plateforme de test . . . . . . . . . . . . . . . . . . . . . . . . . . . 3322.4.1 Gérer les terminaux de test : les contextes . . . . . . . . . . 3322.4.2 Le référentiel documentaire . . . . . . . . . . . . . . . . . . . . . . 336


2.5 Définir des projets de tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3442.5.1 Introduction et prérequis . . . . . . . . . . . . . . . . . . . . . . . . 3442.5.2 Utiliser la gestion de projet correctement . . . . . . . . . . . 3452.5.3 Les affectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3522.5.4 Les phases et jalons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3542.5.5 Les tâches de la phase PILOTER. . . . . . . . . . . . . . . . . . . 3592.5.6 Les tâches de la phase ORGANISER . . . . . . . . . . . . . . . 3642.5.7 Les tâches de la phase PRÉPARER . . . . . . . . . . . . . . . . . 3642.5.8 Les tâches de la phase EXÉCUTER. . . . . . . . . . . . . . . . . 3652.5.9 Les tâches de la phase CLÔTURER . . . . . . . . . . . . . . . . 366

3. Organiser les tests dans ProjeQtOr . . . . . . . . . . . . . . . . . . . . . . . . . . 3673.1 Cartographier les exigences fonctionnelles . . . . . . . . . . . . . . . . 368

3.1.1 Créer des groupes d'exigences fonctionnelles . . . . . . . . 3683.1.2 Définir une exigence fonctionnelle. . . . . . . . . . . . . . . . . 371

3.2 Cartographier les exigences techniques. . . . . . . . . . . . . . . . . . . 3723.2.1 Créer une exigence technique pour tester un écran . . . 3723.2.2 Gérer une exigence technique transverse . . . . . . . . . . . . 373

3.3 Gérer les risques sur le produit. . . . . . . . . . . . . . . . . . . . . . . . . . 3753.3.1 Définir les risques sur le produit. . . . . . . . . . . . . . . . . . . 3753.3.2 Définir la criticité à reporter sur les exigences

à partir de celle de leurs risques . . . . . . . . . . . . . . . . . . . 3783.3.3 Rédiger le dossier de stratégie . . . . . . . . . . . . . . . . . . . . . 379

4. Préparer les tests dans ProjeQtOr . . . . . . . . . . . . . . . . . . . . . . . . . . . 3804.1 Préparer les jeux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

4.1.1 Le cahier des jeux d'essai . . . . . . . . . . . . . . . . . . . . . . . . . 3804.1.2 Saisir les données : quelques astuces utiles . . . . . . . . . . 381

4.2 Préparer les cas de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3824.2.1 Définir les cas de test. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3834.2.2 Rédiger et faire rédiger les cas de test . . . . . . . . . . . . . . . 3894.2.3 Regrouper des cas de test d'un point

de vue fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389


4.3 Préparer les sessions des cas de test . . . . . . . . . . . . . . . . . . . . . . 3914.3.1 Créer une session : regrouper des cas de test . . . . . . . . . 3914.3.2 Définir l'enchaînement des sessions, les regrouper . . . . 394

5. Exécuter des tests avec ProjeQtOr . . . . . . . . . . . . . . . . . . . . . . . . . . 3965.1 Dérouler des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

5.1.1 Quelques contrôles préliminaires pour le référentiel. . . 3965.1.2 Quelques contrôles préliminaires pour la plateforme . . 3965.1.3 Dérouler les sessions de test : GO ! . . . . . . . . . . . . . . . . 397

5.2 Gérer des tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4005.2.1 Créer un ticket pendant l'exécution d'une session . . . . 4005.2.2 Créer un ticket en dehors de l'exécution d'une session . .4015.2.3 Qualifier les tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

6. Piloter votre projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4036.1 Gérer l'avancement et la charge . . . . . . . . . . . . . . . . . . . . . . . . . 403

6.1.1 Saisie, soumission et validation des imputations . . . . . 4036.1.2 Les indicateurs de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . 4046.1.3 Les plannings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

6.2 Pour la gestion de la qualité des produits . . . . . . . . . . . . . . . . . 4076.2.1 Le suivi des charges et le planning . . . . . . . . . . . . . . . . . 4076.2.2 Le plan de gestion des risques . . . . . . . . . . . . . . . . . . . . . 4096.2.3 Couverture des exigences . . . . . . . . . . . . . . . . . . . . . . . . 4106.2.4 Couverture des produits . . . . . . . . . . . . . . . . . . . . . . . . . 4116.2.5 Résumé des sessions de test . . . . . . . . . . . . . . . . . . . . . . 4126.2.6 Les rapports des tickets . . . . . . . . . . . . . . . . . . . . . . . . . . 412

7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415


Chapitre 9Kits pratiques et exemple commenté

1. Kits pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4171.1. Pour les tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4181.2. Pour la recette pompier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4181.3. Pour la recette technico-fonctionnelle d'une release. . . . . . . . . 419

1.3.1 ORGANISER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4191.3.2 PRÉPARER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4191.3.3 EXÉCUTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4201.3.4 CLÔTURER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4201.3.5 PILOTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

1.4. Pour une recette fonctionnelle "pure" ou VABF . . . . . . . . . . . . 421

2. Exemple commenté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

87

Chapitre 3Définir un périmètre de tests :

la stratégieDéfinir un périmètre de tests : la stratégie1. Périmètre fonctionnel

Le présent chapitre s'attachera à définir les notions de périmètre de tests et destratégie de recette, que celle-ci se déroule directement en sortie de développe-ment lors d'une recette technique ou plus en aval au niveau d'une recette fonc-tionnelle, toujours dans le cadre d'un chantier de release.

Nous aborderons ces notions en partant d'un sujet plus large que celui du test :l'analyse de risques. Cette démarche doit normalement être menée par l'équipeMOA en charge des études avant-projet et cela, bien avant le démarrage decelui-ci, comme nous l'avions précisé dans le chapitre Généralités qui exposaitdes généralités sur le processus de production logicielle.

Mais cette tâche n'est pas obligatoire : l'analyse de risques n'est pas toujoursréalisée. Malheureusement…

© E

diti

ons

ENI -

All

righ

ts r

eser

ved


1.1 Parties prenantes, risques et exigences

1.1.1 Lister les parties prenantes

Par partie prenante d'un projet, nous entendons une liste des types d'acteursdu projet et/ou de la solution logicielle produite.

Nous rencontrons donc des parties prenantes spécifiques à un projet (les déve-loppeurs, les chefs de projets MOE et MOA, les équipes de recette…) et desparties prenantes concernées par le produit réalisé, les types d'utilisateurs (parexemple, un administrateur, un contributeur et un rédacteur en chef pour uneapplication de gestion de contenus).

Une partie prenante peut d'ailleurs être concernée avant, pendant et après leprojet suivant son niveau d'implication. Elle peut être dans l'entreprise qui réa-lise le projet, comme elle peut être un anonyme à l'autre bout de la planète.

Quoi qu'il en soit, cette étape permet d'identifier toutes les typologies de per-sonnes interagissant à un moment ou un autre avec le projet et/ou le produit.

1.1.2 Lister les risques

Une fois les parties prenantes identifiées et réparties selon qu'elles sont impli-quées avec le projet ou le produit, s'en suit une phase pendant laquelle le res-ponsable de l'étude va identifier tous les risques dans la mesure du possible.

Deux familles de risques sont distinguées :

– Les risques sur projet, qui concernent les parties prenantes impliquées dansle processus de production logicielle.

– Les risques sur produit, qui concernent les parties prenantes qui interagirontavec le logiciel dès lors que celui-ci leur sera accessible en environnement deproduction. Ces risques-là n'existent donc pas pendant le projet, mais appa-raissent à son issue.

Remarque

Il est très important de ne pas confondre ces deux notions et en général d'évi-ter de faire une confusion entre le projet et le produit qui est son résultat.

89Définir un périmètre de tests : la stratégieChapitre 3

Cette phase d'identification constitue la première étape d'une analyse derisques. Ces derniers sont ensuite catégorisés : ils peuvent être techniques,financiers, organisationnels, contextuels, juridiques, sociaux…

S'en suit alors une valorisation des risques amenant à les classer selon unematrice de risques :

– Selon un axe de probabilité de survenance (chaque minute, chaque heure,quotidienne, hebdomadaire, mensuelle…).

– Selon un axe de gravité d'impact (sans conséquence, impact faible, impactmoyen, impact fort, très fort…).

L'analyse de risques consiste ensuite à définir les parades associées à chacun,c'est-à-dire des actions permettant d'éliminer ou réduire le risque, l'éviter enmettant en place un scénario de contournement… ou bien le prendre !

Le responsable de l'étude avant-projet identifiera aussi les points critiques,c'est-à-dire les moments du projet où on connaîtra un pic maximum de proba-bilité de survenance d'un risque.

Et une fois démarré, les chefs de projet MOA / MOE et Recette devront suivreces risques dans leur domaine respectif et "faire vivre" cette matrice qui n'a riende statique.

© E

diti

ons

ENI -

All

righ

ts r

eser

ved


Nous ne détaillerons pas davantage ce processus d'analyse de risques et nouspréférons renvoyer le lecteur sur l'abondante littérature relative à leur gestion,domaine qui est plus large que celui de l'organisation des tests.

Il est évident que les risques sur le projet peuvent impacter la recette qu'ellesoit fonctionnelle ou technique puisque ces étapes en font partie.

En revanche, les risques sur le produit intéresseront davantage les équipes detests comme nous allons le voir dans les sections qui suivent, car ils définissenttrès clairement les lieux de l'application à produire où la survenance d'une ano-malie est susceptible d'avoir un impact.

Ainsi, nous parlerons de "matrice des risques projet" et "matrice des risquesproduit", ces deux matrices intervenant de manière différente dans le projet.

La matrice des risques projet sera un outil décisionnel utilisé par l'instance depilotage du projet. À la fin du projet, cette matrice sera pour partie obsolète,tout du moins pour les risques qui disparaissent avec la fin du projet : seulssubsistent les risques "post-projet".

La matrice des risques produit sera elle aussi un outil décisionnel, mais elleaura un usage différent puisque c'est une fois le projet fini qu'elle trouve unintérêt plus important et doit impérativement être maintenue.

Remarque

La fréquence de survenance d'un risque produit varie dans le temps par défi-nition puisque le logiciel montera progressivement en puissance entre le pre-mier jour de son utilisation et le moment où sera atteinte une vitesse decroisière. En revanche, l'impact est le plus souvent constant.

C'est cette matrice des risques produit qui intéressera le chef de projet recettepour définir un périmètre de tests.

Un risque produit signifie en effet qu'il existe une probabilité de défaillance dulogiciel. La parade à mettre en œuvre pour chaque risque produit est donc unebatterie d'actions de vérification, ou tests logiciels, afin d'éprouver le produitdans son usage réel.

91Définir un périmètre de tests : la stratégieChapitre 3

Définir la matrice des risques sur produit revient donc à définir un périmètrede tests dans une démarche que l'on appellera Risk Based Testing ou RBT.

1.1.3 Lister les exigences

Nous pouvons comprendre le terme exigence comme une contrainte ou unbesoin selon le contexte – parfois les deux ensembles – une contrainte étantdéfinie comme un besoin impératif, notion qui se traduit en anglais par leterme requirement. Par exemple, avoir besoin de 10 postes de travail est une exi-gence du projet pour répondre à une contrainte logistique.

Un autre exemple serait de dire que le logiciel futur permette de réaliser unvirement bancaire – nous aurions alors une exigence fonctionnelle du produit –et simultanément d'être sécurisé comme le reste de l'application de banque enligne où cette fonction est accessible – nous aurions alors une exigencetechnique de fiabilité du produit dans sa globalité.

De ces exemples, nous comprenons que le mot exigence désigne de nom-breuses choses au sein d'un même projet et que seul il ne veut rien dire : unehiérarchie des exigences est donc nécessaire dont la base est la distinctionentre exigence projet et produit.

Les exigences du projet se décomposeront alors en fonction des différentesphases de son exécution : exigences organisationnelles, logistiques… dontcelles qui concernent l'équipe en charge des tests techniques et celle en chargedes tests fonctionnels.

Quant aux exigences du produit, elles répondent à une typologie différentemais nous pouvons déjà distinguer deux familles :

– Les exigences fonctionnelles et les règles de gestion à implémenter, c'est-à-dire une décomposition structurelle du produit à réaliser, une description dubut.

– Les exigences techniques, c'est-à-dire les qualités spécifiques auxquelles doi-vent répondre toutes les parties du produit.

© E

diti

ons

ENI -

All

righ

ts r

eser

ved


Le schéma ci-dessous reprend cette classification :

La démarche descriptive du projet que nous venons d'aborder ici se nomme"requirement analysis" en anglais ou "analyse des exigences". Conjointement àl'analyse des risques, elle constitue une autre manière d'aborder une étudeavant-projet en recensant non pas une probabilité de survenance d'un événe-ment désagréable, mais au contraire ce qui est souhaité et souhaitable.

Autre différence notable, autant une analyse des risques n'est pas toujoursmenée (ou bien très succinctement), autant une analyse des exigences estincontournable.

Le chef de projet recette s'intéressera donc par nécessité au résultat de cetteétude qui d'ailleurs définit le contour des spécifications fonctionnelles – dumoins la sous-arborescence des exigences fonctionnelles.

Documents

Gestion des tests logiciels - fnac-static.comGestion des tests logiciels pour l’industrialisation des tests Gestionjets fonctionnels des tests logiciels Gestion des tests logiciels