Ce livre sur la gestion des tests logiciels s'adresse principalement aux Chefs de projets fonctionnels, Assistants Maîtrise d'Ouvrage et éventuellement aux Développeurs, qui souhaitent embrasser l'ensemble des processus de recette indépendamment 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 diffé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 permettront de passer de la théorie à la pratique sont en téléchargement sur www.editions-eni.fr.


Les chapitres du livre :
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é

Téléchargements

• Des fichiers complémentaires (962 Ko)

Avant-propos

1. Pourquoi ce livre ?
2. Objectifs
3. Avertissements : pourquoi une réédition ?

Généralités

1. Principaux concepts et cycle projet
   1. 1. Introduction
      1. a. Premières considérations : parlonsla même langue !
      2. b. Schéma général du cycleprojet
   2. 2. L’avant-projet
      1. a. Étude d’opportunité
      2. b. Étude d’impact
      3. c. Le choix
   3. 3. Le projet
      1. a. Lancement
      2. b. Conception
      3. c. Réalisation
      4. d. Recette technique
      5. e. Recette fonctionnelle ou métier
      6. f. Recette usine
      7. g. Recette d’homologation ou VABF
      8. h. Déploiement et montée en charge
   4. 4. L’après-projet
      1. a. Clôture du projet
      2. b. Bilan
2. Types de test
   1. 1. Pendant le projet
      1. a. Relecture des spécifications
      2. b. Types de tests unitaires
      3. c. Types de tests techniques
      4. d. Tests d’intégration ou d’interface
      5. e. Tests de validation fonctionnelle
   2. 2. Et après le projet ?
      1. a. Tester la performance
      2. b. La maintenance : les tests de non-régression
      3. c. Capitaliser le référentiel de tests
3. Contextes de mise en œuvre des tests
   1. 1. Côté maîtrise d’œuvre
      1. a. Maîtrise d’œuvre externe
      2. b. Maîtrise d’œuvre interne
   2. 2. Côté maîtrise d’ouvrage
      1. a. Maîtrise d’ouvrage externe ou interne nonmature en tests
      2. b. Maîtrise d’ouvrage interne mature en tests
   3. 3. Cas d’une cellule de tests indépendante
      1. a. Cellule externe à l’entreprise
      2. b. Cellule interne à l’entreprise

Organiser les tests unitaires

1. Organisations possibles
   1. 1. Le développeur livré à lui-même,seul ou en équipe
      1. a. Hiérarchiser son travail
      2. b. Mesurer le temps passé
   2. 2. Le travail en équipe
      1. a. Sensibiliser l’équipe : le rôledu chef de projet
      2. b. S’assurer que les besoins en test sont couverts
      3. c. Anticiper les dépendances de tâches
      4. d. Les tests croisés
2. Tests unitaires élémentaires
   1. 1. Tester un écran ou un formulaire
      1. a. Libellés statiques
      2. b. Libellés dynamiques
      3. c. Champs cachés
      4. d. Liens et images cliquables
      5. e. Champs alphanumériques
      6. f. Champs multilignes
      7. g. Champs numériques
      8. h. Champs de type date
      9. i. Champs de type heure
      10. j. Champs de type numéro de semaine
      11. k. Listes déroulantes et non déroulantes
      12. l. Boutons radio, cases à cocher et autres composantsgraphiques
   2. 2. Tester un flux ou un traitement de masse
      1. a. Pouvoir exécuter le traitement "à blanc"
      2. b. Vérifier la volumétrie
      3. c. Tests par échantillonnage
      4. d. Tests étendus, tests fragmentés
3. Formaliser les tests unitaires
   1. 1. Dans un projet géré en V
      1. a. Pourquoi formaliser les tests unitaires ?
      2. b. Le rapport de tests unitaires
   2. 2. Validation en méthodes Agiles
      1. a. Rappel des principes des méthodes Agiles
      2. b. Le flux des stories
      3. c. La formalisation des tests dans le backlog
      4. d. Validation des stories et périmètredes tests après livraison
4. Risques projet liés à la gestion des tests unitaires
   1. 1. Impact sur la charge
      1. a. Vers une augmentation de la charge de réalisation?
      2. b. Prendre le risque de la sur-qualité
   2. 2. Impact sur l’équipe
      1. a. Une meilleure cohésion, de meilleures performances
      2. b. Prendre le risque de démotiver l’équipe

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

1. Périmètre fonctionnel
   1. 1. Parties prenantes, risques et exigences
      1. a. Lister les parties prenantes
      2. b. Lister les risques
      3. c. Lister les exigences
   2. 2. Hiérarchiser le périmètrefonctionnel
      1. a. Qu’est-ce qu’une criticité ? Qu’est-ce qu’unepriorité ?
      2. b. Rapprocher les risques des exigences
      3. c. Matrice de criticité et périmètred’une recette fonctionnelle
      4. d. Matrice de criticité et périmètrethéorique d’une recette technique
      5. e. Exigence fonctionnelle, technique et niveau de test
2. Périmètre disponible : gérer les dégradations
   1. 1. Environnement dégradé
      1. a. Des traitements en moins
      2. b. Des données en moins
   2. 2. Application dégradée
      1. a. Mode de fonctionnement d’une application
      2. b. Suppression de composants externes, dégradationde version
      3. c. Dégradation des applications web
   3. 3. Périmètre de tests et dégradations
      1. a. Améliorer la matrice du périmètredes tests
      2. b. Représentation du périmètredes tests et des dégradations
3. Périmètre des configurations matérielles
   1. 1. La gestion des configurations matérielles
      1. a. En recette fonctionnelle
      2. b. En recette technique
      3. c. Pour quel résultat ?
      4. d. Quelle stratégie adopter ?
   2. 2. Quelques retours d’expérience
      1. a. Les clients lourds sur PC et les applications Java
      2. b. Les applications web
      3. c. Pocket PC et Palm
      4. d. Des architectures très variées :iPhone, smartphone…
4. Périmètres thématiques
   1. 1. Tester l’ergonomie et le ressenti graphique global
      1. a. Tester la navigation : les applications web
      2. b. Tester la cinématique : les clients lourds
   2. 2. Tester le multilinguisme, la langue d’une application
      1. a. Les fautes d’orthographe
      2. b. Le multilinguisme

Gérer les données : la principale contrainte

1. Définir des jeux d'essai pertinents
   1. 1. Construire le périmètre des données
      1. a. Démarche de construction des jeux de donnéesd’une recette fonctionnelle
      2. b. Démarche de construction des jeux de donnéesd’une recette technique
      3. c. Impact de l’organisation sur la constitution du jeud’essai
      4. d. Impact du planning projet sur la constitution du jeud’essai
      5. e. Anticiper la consommation des données
      6. f. Dépendances fonctionnelles et jeux d’essai
      7. g. Impact du support technique du jeu de données
      8. h. Un jeu d’essai qui a du sens
   2. 2. Sauvegardes et restaurations
      1. a. Intérêts
      2. b. Les limites et inconvénients
      3. c. Un service à offrir ?
2. Les données en environnement dégradé
   1. 1. Modifier le jeu de données en cours d’exécution
      1. a. Qu’est-ce qu’une simulation ?
      2. b. Comment gérer les simulations ?
      3. c. Les limites des simulations
   2. 2. Les bouchons : des données artificielles
      1. a. Qu’est-ce qu’un bouchon ?
      2. b. Un exemple concret : un système de banqueen ligne
      3. c. Comment gérer des bouchons lors d’une recette?
      4. d. Les limites des tests des applications bouchonnées
   3. 3. Impact sur le bilan des tests
      1. a. Décrire ce qui n’a pas pu être testé
      2. b. Émettre des réserves
      3. c. Déterminer une stratégie de continuité

Organiser une recette

1. Concepts généraux dans l'organisation du travail
   1. 1. Le diagramme de Crosby Turtle
   2. 2. Les diagrammes de PERT et de GANTT
   3. 3. Les types de recette
2. La recette "pompier"
   1. 1. Le contexte
      1. a. Quand ?
      2. b. Pourquoi ?
   2. 2. Gérer une recette d’urgence
      1. a. ORGANISER - Définir un périmètrede manière pragmatique
      2. b. PRÉPARER - Est-il utile de formaliser lestests ?
      3. c. EXÉCUTER - Collecter les anomalies de manièrecentralisée
      4. d. EXÉCUTER - L’équipe de développementest un partenaire
      5. e. CLÔTURER - Mettre en place un protocole d’acceptationpour les prochaines livraisons
3. La recette d'un patch
   1. 1. Le contexte
      1. a. Quand ?
      2. b. Quelles contraintes ?
   2. 2. Gérer la recette d’un patch
      1. a. ORGANISER - Définir un périmètre
      2. b. PRÉPARER - Est-il utile de formaliser lestests ?
      3. c. EXÉCUTER - Doit-on formaliser les anomaliesd’un patch ?
      4. d. CLÔTURER - Comment gérer les anomaliesd’un patch ?
      5. e. CLÔTURER - Gérer une cartographieet les livraisons
4. La recette technique
   1. 1. Le contexte
      1. a. Quand ?
      2. b. Pourquoi ?
      3. c. Vers une professionnalisation
   2. 2. Gérer la recette technique d’une release
      1. a. ORGANISER - L’étape la plus critique
      2. b. PRÉPARER - Anticiper la capitalisation
      3. c. EXÉCUTER - S’appuyer sur un plan de testréutilisable
      4. d. CLÔTURER
   3. 3. Gérer la recette technique d’une maintenance évolutive
      1. a. ORGANISER
      2. b. PRÉPARER
      3. c. EXÉCUTER
      4. d. CLÔTURER
5. La recette fonctionnelle "pure" ou VABF
   1. 1. Le contexte
      1. a. Quand ?
      2. b. Pourquoi ?
   2. 2. Gérer la recette fonctionnelle
      1. a. ORGANISER - Formaliser une homologation
      2. b. PRÉPARER - Mettre l’accent sur le jeu d’essai
      3. c. EXÉCUTER - Prendre un recul fonctionnel
      4. d. CLÔTURER - Homologuer ou ne pas homologuer?

Gérer les observations

1. Rappels importants
   1. 1. Définitions
      1. a. L’observation
      2. b. Anomalie, bug, dysfonctionnement et non-conformité
      3. c. La demande d’évolution
   2. 2. Processus documentaires
      1. a. Les états d’un document
      2. b. Processus et formalisation : de l’usage des graphesd’états finis
      3. c. Les triggers (déclencheurs)
      4. d. Les notifications
   3. 3. Les processus de gestion des observations : un survol
      1. a. Les incidents de production
      2. b. Les demandes d’évolution
      3. c. Les observations faites pendant une recette fonctionnelle
      4. d. Les observations faites pendant une recette technique
2. Processus de gestion des incidents de production
   1. 1. Principes organisationnels
      1. a. Formaliser le ou les workflows documentaires
      2. b. Définir un support de collecte : outil ousimple fichier ?
      3. c. Interactions avec la collecte des demandes d’évolution
      4. d. La gestion des dépendances transverses
   2. 2. Les risques
      1. a. Confondre incident et demande d’évolution
      2. b. Ne pas valoriser la criticité de signalement
      3. c. Ne pas détecter une dépendance
      4. d. Mal implémenter le processus dans un outil
      5. e. Abandonner l’usager, ne pas le former
3. Les anomalies remontées par la maîtrise d'ouvrage
   1. 1. Principes organisationnels
      1. a. Avec ou sans équipe de recette technique?
      2. b. Définir un support de collecte
      3. c. Formalisation du processus
      4. d. Le lotissement des corrections : préparerles vérifications
   2. 2. Les risques
      1. a. Ne pas indiquer clairement que l’anomalie a une originemétier
      2. b. Mal implémenter l’outil
      3. c. Mal gérer les retours
4. Les anomalies détectées lors d'une recette technique
   1. 1. Principes organisationnels
      1. a. Formaliser le workflow documentaire
      2. b. Définir un support de collecte : outil ousimple fichier ?
      3. c. Interactions avec la collecte des demandes d’évolution
      4. d. Gérer les points de blocage
      5. e. Gérer les retours
   2. 2. Les risques
      1. a. Mal paramétrer un outil (encore et toujours)
      2. b. Doubler le processus de livraison dans l’outil
      3. c. Ne pas être pertinent
      4. d. Émettre un flux inconstant, mal communiqueravec la MOE

Piloter une recette

1. Le pilotage budgétaire
   1. 1. La recette technique d’un projet de release
      1. a. Évaluer la charge de l’organisation
      2. b. Évaluer la charge de la préparation
      3. c. Évaluer la charge de l’exécution
      4. d. Évaluer la charge de la clôture
      5. e. Cas particulier des tests automatiques
      6. f. Ajouter la charge de pilotage
      7. g. Suivre la charge
   2. 2. La recette technique d’un projet de maintenance
      1. a. Évaluer la charge
      2. b. Suivre la charge
   3. 3. La recette fonctionnelle ou VABF
      1. a. Évaluer la charge
      2. b. Suivre la charge
2. Risques et reporting
   1. 1. Les risques d’un projet de recette
      1. a. En recette fonctionnelle ou VABF
      2. b. En recette technique
      3. c. Suivre les risques
   2. 2. Le formalisme du reporting

Outiller une recette sous ProjeQtOr

1. Prérequis à installer et avertissements
   1. 1. Installer Wamp puis ProjeQtOr
      1. a. Installer Wamp : votre plateforme technique
      2. b. Installer ProjeQtOr
   2. 2. Modifier les types de ProjeQtOr
      1. a. Type de projets
      2. b. Type de tickets
      3. c. Type d’activités
      4. d. Type de jalons
      5. e. Type de risques
      6. f. Type de documents
      7. g. Type de contextes
      8. h. Type d’exigences
      9. i. Type de cas de test
      10. j. Type de sessions de test
   3. 3. Modifier les listes de valeurs de ProjeQtOr
      1. a. Les sévérités, probabilitéset criticités d’un risque
      2. b. Les priorités
      3. c. L’urgence
      4. d. Les fonctions
      5. e. Les niveaux de qualité et situations d’unprojet
      6. f. Les niveaux de risque
      7. g. Autres listes à connaître
   4. 4. Fonctions clés à connaître
      1. a. Paramètres globaux
      2. b. Paramétrage des calendriers : les jours fériés
      3. c. Habilitations, profils et accès
      4. d. Lancer les CRON
2. Organiser des projets de test dans ProjeQtOr
   1. 1. Importer des données
   2. 2. Gérer les produits et composants
      1. a. Gérer les composants
      2. b. Gérer les versions des composants
      3. c. Gérer les produits et sous-produits
      4. d. Gérer les versions des produits
   3. 3. Définir les équipes de test
      1. a. Les équipes
      2. b. Les utilisateurs
      3. c. Les ressources
      4. d. Les contacts
   4. 4. Définir la plateforme de test
      1. a. Gérer les terminaux de test : les contextes
      2. b. Le référentiel documentaire
   5. 5. Définir des projets de tests
      1. a. Introduction et prérequis
      2. b. Utiliser la gestion de projet correctement
      3. c. Les affectations
      4. d. Les phases et jalons
      5. e. Les tâches de la phase PILOTER
      6. f. Les tâches de la phase ORGANISER
      7. g. Les tâches de la phase PRÉPARER
      8. h. Les tâches de la phase EXÉCUTER
      9. i. Les tâches de la phase CLÔTURER
3. Organiser les tests dans ProjeQtOr
   1. 1. Cartographier les exigences fonctionnelles
      1. a. Créer des groupes d’exigences fonctionnelles
      2. b. Définir une exigence fonctionnelle
   2. 2. Cartographier les exigences techniques
      1. a. Créer une exigence technique pour testerun écran
      2. b. Gérer une exigence technique transverse
   3. 3. Gérer les risques sur le produit
      1. a. Définir les risques sur le produit
      2. b. Définir la criticité à reportersur les exigences à partir de celle de leurs risques
      3. c. Rédiger le dossier de stratégie
4. Préparer les tests dans ProjeQtOr
   1. 1. Préparer les jeux de données
      1. a. Le cahier des jeux d’essai
      2. b. Saisir les données : quelques astuces utiles
   2. 2. Préparer les cas de tests
      1. a. Définir les cas de test
      2. b. Rédiger et faire rédiger les casde test
      3. c. Regrouper des cas de test d’un point de vue fonctionnel
   3. 3. Préparer les sessions des cas de test
      1. a. Créer une session : regrouper des cas detest
      2. b. Définir l’enchaînement des sessions,les regrouper
5. Exécuter des tests avec ProjeQtOr
   1. 1. Dérouler des tests
      1. a. Quelques contrôles préliminairespour le référentiel
      2. b. Quelques contrôles préliminairespour la plateforme
      3. c. Dérouler les sessions de test : GO !
   2. 2. Gérer des tickets
      1. a. Créer un ticket pendant l’exécutiond’une session
      2. b. Créer un ticket en dehors de l’exécutiond’une session
      3. c. Qualifier les tickets
6. Piloter votre projet
   1. 1. Gérer l’avancement et la charge
      1. a. Saisie, soumission et validation des imputations
      2. b. Les indicateurs de suivi
      3. c. Les plannings
   2. 2. Pour la gestion de la qualité des produits
      1. a. Le suivi des charges et le planning
      2. b. Le plan de gestion des risques
      3. c. Couverture des exigences
      4. d. Couverture des produits
      5. e. Résumé des sessions de test
      6. f. Les rapports des tickets
7. Conclusion

Kits pratiques et exemple commenté

1. Kits pratiques
   1. 1. Pour les tests unitaires
   2. 2. Pour la recette pompier
   3. 3. Pour la recette technico-fonctionnelle d’une release
      1. a. ORGANISER
      2. b. PRÉPARER
      3. c. EXÉCUTER
      4. d. CLÔTURER
      5. e. PILOTER
   4. 4. Pour une recette fonctionnelle "pure" ou VABF
2. Exemple commenté