1. Livres et vidéos
  2. Gestion des tests logiciels - Bonnes pratiques à mettre en oeuvre pour l'industrialisation des tests (2e édition)

Gestion des tests logiciels Bonnes pratiques à mettre en oeuvre pour l'industrialisation des tests (2e édition)

  • Accès illimité 24h/24, 7J/7
  • Tous les livres en ligne, les vidéos et les cours enregistrés ENI
  • Plus de 10 nouveautés livres et vidéos chaque mois
  • Les nouveautés disponibles le jour de leur sortie
  • Accès 100% en ligne
  • En stock
  • Expédié en 24h00
  • Livraison à partir de 0,01 €
  • Version en ligne offerte
  • 1 h d'accès gratuit à tous nos livres et vidéos pour chaque commande
  • Accessible immédiatement
  • Version HTML
  • Accès illimité 24h/24, 7J/7

Présentation

Ce livre sur la gestion des tests logiciels s'adresse principalement aux Chefs de projets fonctionnelsAssistants 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é

Table des matières

  • 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.1.1 Premières considérations : parlons la même langue !
        • 1.1.2 Schéma général du cycle projet
      • 1.2. L'avant-projet
        • 1.2.1 Étude d'opportunité
        • 1.2.2 Étude d'impact
        • 1.2.3 Le choix
      • 1.3. Le projet
        • 1.3.1 Lancement
        • 1.3.2 Conception
        • 1.3.3 Réalisation
        • 1.3.4 Recette technique
        • 1.3.5 Recette fonctionnelle ou métier
        • 1.3.6 Recette usine
        • 1.3.7 Recette d'homologation ou VABF
        • 1.3.8 Déploiement et montée en charge
      • 1.4. L'après-projet
        • 1.4.1 Clôture du projet
        • 1.4.2 Bilan
    • 2. Types de test
      • 2.1. Pendant le projet
        • 2.1.1 Relecture des spécifications
        • 2.1.2 Types de tests unitaires
        • 2.1.3 Types de tests techniques
        • 2.1.4 Tests d'intégration ou d'interface
        • 2.1.5 Tests de validation fonctionnelle
      • 2.2. Et après le projet ?
        • 2.2.1 Tester la performance
        • 2.2.2 La maintenance : les tests de non-régression
        • 2.2.3 Capitaliser le référentiel de tests
    • 3. Contextes de mise en œuvre des tests
      • 3.1. Côté maîtrise d'œuvre
        • 3.1.1 Maîtrise d'œuvre externe
        • 3.1.2 Maîtrise d'œuvre interne
      • 3.2. Côté maîtrise d'ouvrage
        • 3.2.1 Maîtrise d'ouvrage externe ou interne non mature en tests
        • 3.2.2 Maîtrise d'ouvrage interne mature en tests
      • 3.3. Cas d'une cellule de tests indépendante
        • 3.3.1 Cellule externe à l'entreprise
        • 3.3.2 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.1.1 Hiérarchiser son travail
        • 1.1.2 Mesurer le temps passé
      • 1.2. Le travail en équipe
        • 1.2.1 Sensibiliser l'équipe : le rôle du chef de projet
        • 1.2.2 S'assurer que les besoins en test sont couverts
        • 1.2.3 Anticiper les dépendances de tâches
        • 1.2.4 Les tests croisés
    • 2. Tests unitaires élémentaires
      • 2.1. Tester un écran ou un formulaire
        • 2.1.1 Libellés statiques
        • 2.1.2 Libellés dynamiques
        • 2.1.3 Champs cachés
        • 2.1.4 Liens et images cliquables
        • 2.1.5 Champs alphanumériques
        • 2.1.6 Champs multilignes
        • 2.1.7 Champs numériques
        • 2.1.8 Champs de type date
        • 2.1.9 Champs de type heure
        • 2.1.10 Champs de type numéro de semaine
        • 2.1.11 Listes déroulantes et non déroulantes
        • 2.1.12 Boutons radio, cases à cocher et autres composants graphiques
      • 2.2. Tester un flux ou un traitement de masse
        • 2.2.1 Pouvoir exécuter le traitement "à blanc"
        • 2.2.2 Vérifier la volumétrie
        • 2.2.3 Tests par échantillonnage
        • 2.2.4 Tests étendus, tests fragmentés
    • 3. Formaliser les tests unitaires
      • 3.1. Dans un projet géré en V
        • 3.1.1 Pourquoi formaliser les tests unitaires ?
        • 3.1.2 Le rapport de tests unitaires
      • 3.2. Validation en méthodes Agiles
        • 3.2.1 Rappel des principes des méthodes Agiles
        • 3.2.2 Le flux des stories
        • 3.2.3 La formalisation des tests dans le backlog
        • 3.2.4 Validation des stories et périmètre des tests après livraison
    • 4. Risques projet liés à la gestion des tests unitaires
      • 4.1. Impact sur la charge
        • 4.1.1 Vers une augmentation de la charge de réalisation ?
        • 4.1.2 Prendre le risque de la sur-qualité
      • 4.2. Impact sur l'équipe
        • 4.2.1 Une meilleure cohésion, de meilleures performances
        • 4.2.2 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.1.1 Lister les parties prenantes
        • 1.1.2 Lister les risques
        • 1.1.3 Lister les exigences
      • 1.2. Hiérarchiser le périmètre fonctionnel
        • 1.2.1 Qu'est-ce qu'une criticité ? Qu'est-ce qu’une priorité ?
        • 1.2.2 Rapprocher les risques des exigences
        • 1.2.3 Matrice de criticité et périmètre d'une recette fonctionnelle
        • 1.2.4 Matrice de criticité et périmètre théorique d'une recette technique
        • 1.2.5 Exigence fonctionnelle, technique et niveau de test
    • 2. Périmètre disponible : gérer les dégradations
      • 2.1. Environnement dégradé
        • 2.1.1 Des traitements en moins
        • 2.1.2 Des données en moins
      • 2.2. Application dégradée
        • 2.2.1 Mode de fonctionnement d'une application
        • 2.2.2 Suppression de composants externes, dégradation de version
        • 2.2.3 Dégradation des applications web
      • 2.3. Périmètre de tests et dégradations
        • 2.3.1 Améliorer la matrice du périmètre des tests
        • 2.3.2 Représentation du périmètre des tests et des dégradations
    • 3. Périmètre des configurations matérielles
      • 3.1. La gestion des configurations matérielles
        • 3.1.1 En recette fonctionnelle
        • 3.1.2 En recette technique
        • 3.1.3 Pour quel résultat ?
        • 3.1.4 Quelle stratégie adopter ?
      • 3.2. Quelques retours d'expérience
        • 3.2.1 Les clients lourds sur PC et les applications Java
        • 3.2.2 Les applications web
        • 3.2.3 Pocket PC et Palm
        • 3.2.4 Des architectures très variées : iPhone, smartphone...
    • 4. Périmètres thématiques
      • 4.1. Tester l'ergonomie et le ressenti graphique global
        • 4.1.1 Tester la navigation : les applications web
        • 4.1.2 Tester la cinématique : les clients lourds
      • 4.2. Tester le multilinguisme, la langue d'une application
        • 4.2.1 Les fautes d'orthographe
        • 4.2.2 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.1.1 Démarche de construction des jeux de donnéesd'une recette fonctionnelle
        • 1.1.2 Démarche de construction des jeux de donnéesd'une recette technique
        • 1.1.3 Impact de l'organisation sur la constitution du jeu d'essai
        • 1.1.4 Impact du planning projet sur la constitution du jeu d'essai
        • 1.1.5 Anticiper la consommation des données
        • 1.1.6 Dépendances fonctionnelles et jeux d'essai
        • 1.1.7 Impact du support technique du jeu de données
        • 1.1.8 Un jeu d'essai qui a du sens
      • 1.2. Sauvegardes et restaurations
        • 1.2.1 Intérêts
        • 1.2.2 Les limites et inconvénients
        • 1.2.3 Un service à offrir ?
    • 2. Les données en environnement dégradé
      • 2.1. Modifier le jeu de données en cours d'exécution
        • 2.1.1 Qu'est-ce qu'une simulation ?
        • 2.1.2 Comment gérer les simulations ?
        • 2.1.3 Les limites des simulations
      • 2.2. Les bouchons : des données artificielles
        • 2.2.1 Qu'est-ce qu'un bouchon ?
        • 2.2.2 Un exemple concret : un système de banque en ligne
        • 2.2.3 Comment gérer des bouchons lors d'une recette ?
        • 2.2.4 Les limites des tests des applications bouchonnées
      • 2.3. Impact sur le bilan des tests
        • 2.3.1 Décrire ce qui n'a pas pu être testé
        • 2.3.2 Émettre des réserves
        • 2.3.3 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
      • 1.2. Les diagrammes de PERT et de GANTT
      • 1.3. Les types de recette
    • 2. La recette "pompier"
      • 2.1. Le contexte
        • 2.1.1 Quand ?
        • 2.1.2 Pourquoi ?
      • 2.2. Gérer une recette d'urgence
        • 2.2.1 ORGANISER - Définir un périmètre de manière pragmatique
        • 2.2.2 PRÉPARER - Est-il utile de formaliser les tests ?
        • 2.2.3 EXÉCUTER - Collecter les anomalies de manière centralisée
        • 2.2.4 EXÉCUTER - L'équipe de développement est un partenaire
        • 2.2.5 CLÔTURER - Mettre en place un protocole d'acceptation pour les prochaines livraisons
    • 3. La recette d'un patch
      • 3.1. Le contexte
        • 3.1.1 Quand ?
        • 3.1.2 Quelles contraintes ?
      • 3.2. Gérer la recette d'un patch
        • 3.2.1 ORGANISER - Définir un périmètre
        • 3.2.2 PRÉPARER - Est-il utile de formaliser les tests ?
        • 3.2.3 EXÉCUTER - Doit-on formaliser les anomalies d'un patch ?
        • 3.2.4 CLÔTURER - Comment gérer les anomalies d'un patch ?
        • 3.2.5 CLÔTURER - Gérer une cartographie et les livraisons
    • 4. La recette technique
      • 4.1. Le contexte
        • 4.1.1 Quand ?
        • 4.1.2 Pourquoi ?
        • 4.1.3 Vers une professionnalisation
      • 4.2. Gérer la recette technique d'une release
        • 4.2.1 ORGANISER - L'étape la plus critique
        • 4.2.2 PRÉPARER - Anticiper la capitalisation
        • 4.2.3 EXÉCUTER - S'appuyer sur un plan de test réutilisable
        • 4.2.4 CLÔTURER
      • 4.3. Gérer la recette technique d'une maintenance évolutive
        • 4.3.1 ORGANISER
        • 4.3.2 PRÉPARER
        • 4.3.3 EXÉCUTER
        • 4.3.4 CLÔTURER
    • 5. La recette fonctionnelle "pure" ou VABF
      • 5.1. Le contexte
        • 5.1.1 Quand ?
        • 5.1.2 Pourquoi ?
      • 5.2. Gérer la recette fonctionnelle
        • 5.2.1 ORGANISER - Formaliser une homologation
        • 5.2.2 PRÉPARER - Mettre l'accent sur le jeu d'essai
        • 5.2.3 EXÉCUTER - Prendre un recul fonctionnel
        • 5.2.4 CLÔTURER - Homologuer ou ne pas homologuer ?
  • Gérer les observations
    • 1. Rappels importants
      • 1.1. Définitions
        • 1.1.1 L'observation
        • 1.1.2 Anomalie, bug, dysfonctionnement et non-conformité
        • 1.1.3 La demande d'évolution
      • 1.2. Processus documentaires
        • 1.2.1 Les états d'un document
        • 1.2.2 Processus et formalisation : de l'usage des graphes d'états finis
        • 1.2.3 Les triggers (déclencheurs)
        • 1.2.4 Les notifications
      • 1.3. Les processus de gestion des observations : un survol
        • 1.3.1 Les incidents de production
        • 1.3.2 Les demandes d'évolution
        • 1.3.3 Les observations faites pendant une recette fonctionnelle
        • 1.3.4 Les observations faites pendant une recette technique
    • 2. Processus de gestion des incidents de production
      • 2.1. Principes organisationnels
        • 2.1.1 Formaliser le ou les workflows documentaires
        • 2.1.2 Définir un support de collecte : outil ou simple fichier ?
        • 2.1.3 Interactions avec la collecte des demandes d'évolution
        • 2.1.4 La gestion des dépendances transverses
      • 2.2. Les risques
        • 2.2.1 Confondre incident et demande d'évolution
        • 2.2.2 Ne pas valoriser la criticité de signalement
        • 2.2.3 Ne pas détecter une dépendance
        • 2.2.4 Mal implémenter le processus dans un outil
        • 2.2.5 Abandonner l'usager, ne pas le former
    • 3. Les anomalies remontées par la maîtrise d'ouvrage
      • 3.1. Principes organisationnels
        • 3.1.1 Avec ou sans équipe de recette technique ?
        • 3.1.2 Définir un support de collecte
        • 3.1.3 Formalisation du processus
        • 3.1.4 Le lotissement des corrections : préparer les vérifications
      • 3.2. Les risques
        • 3.2.1 Ne pas indiquer clairement que l'anomalie a une origine métier
        • 3.2.2 Mal implémenter l'outil
        • 3.2.3 Mal gérer les retours
    • 4. Les anomalies détectées lors d'une recette technique
      • 4.1. Principes organisationnels
        • 4.1.1 Formaliser le workflow documentaire
        • 4.1.2 Définir un support de collecte : outil ou simple fichier ?
        • 4.1.3 Interactions avec la collecte des demandes d'évolution
        • 4.1.4 Gérer les points de blocage
        • 4.1.5 Gérer les retours
      • 4.2. Les risques
        • 4.2.1 Mal paramétrer un outil (encore et toujours)
        • 4.2.2 Doubler le processus de livraison dans l'outil
        • 4.2.3 Ne pas être pertinent
        • 4.2.4 Émettre un flux inconstant, mal communiquer avec la MOE
  • Piloter une recette
    • 1. Le pilotage budgétaire
      • 1.1. La recette technique d'un projet de release
        • 1.1.1 Évaluer la charge de l'organisation
        • 1.1.2 Évaluer la charge de la préparation
        • 1.1.3 Évaluer la charge de l'exécution
        • 1.1.4 Évaluer la charge de la clôture
        • 1.1.5 Cas particulier des tests automatiques
        • 1.1.6 Ajouter la charge de pilotage
        • 1.1.7 Suivre la charge
      • 1.2. La recette technique d'un projet de maintenance
        • 1.2.1 Évaluer la charge
        • 1.2.2 Suivre la charge
      • 1.3. La recette fonctionnelle ou VABF
        • 1.3.1 Évaluer la charge
        • 1.3.2 Suivre la charge
    • 2. Risques et reporting
      • 2.1. Les risques d'un projet de recette
        • 2.1.1 En recette fonctionnelle ou VABF
        • 2.1.2 En recette technique
        • 2.1.3 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.1.1 Installer Wamp : votre plateforme technique
        • 1.1.2 Installer ProjeQtOr
      • 1.2 Modifier les types de ProjeQtOr
        • 1.2.1 Type de projets
        • 1.2.2 Type de tickets
        • 1.2.3 Type d'activités
        • 1.2.4 Type de jalons
        • 1.2.5 Type de risques
        • 1.2.6 Type de documents
        • 1.2.7 Type de contextes
        • 1.2.8 Type d'exigences
        • 1.2.9 Type de cas de test
        • 1.2.10 Type de sessions de test
      • 1.3 Modifier les listes de valeurs de ProjeQtOr
        • 1.3.1 Les sévérités, probabilités et criticités d'un risque
        • 1.3.2 Les priorités
        • 1.3.3 L'urgence
        • 1.3.4 Les fonctions
        • 1.3.5 Les niveaux de qualité et situations d'un projet
        • 1.3.6 Les niveaux de risque
        • 1.3.7 Autres listes à connaître
      • 1.4 Fonctions clés à connaître
        • 1.4.1 Paramètres globaux
        • 1.4.2 Paramétrage des calendriers : les jours fériés
        • 1.4.3 Habilitations, profils et accès
        • 1.4.4 Lancer les CRON
    • 2. Organiser des projets de test dans ProjeQtOr
      • 2.1 Importer des données
      • 2.2 Gérer les produits et composants
        • 2.2.1 Gérer les composants
        • 2.2.2 Gérer les versions des composants
        • 2.2.3 Gérer les produits et sous-produits
        • 2.2.4 Gérer les versions des produits
      • 2.3 Définir les équipes de test
        • 2.3.1 Les équipes
        • 2.3.2 Les utilisateurs
        • 2.3.3 Les ressources
        • 2.3.4 Les contacts
      • 2.4 Définir la plateforme de test
        • 2.4.1 Gérer les terminaux de test : les contextes
        • 2.4.2 Le référentiel documentaire
      • 2.5 Définir des projets de tests
        • 2.5.1 Introduction et prérequis
        • 2.5.2 Utiliser la gestion de projet correctement
        • 2.5.3 Les affectations
        • 2.5.4 Les phases et jalons
        • 2.5.5 Les tâches de la phase PILOTER
        • 2.5.6 Les tâches de la phase ORGANISER
        • 2.5.7 Les tâches de la phase PRÉPARER
        • 2.5.8 Les tâches de la phase EXÉCUTER
        • 2.5.9 Les tâches de la phase CLÔTURER
    • 3. Organiser les tests dans ProjeQtOr
      • 3.1 Cartographier les exigences fonctionnelles
        • 3.1.1 Créer des groupes d'exigences fonctionnelles
        • 3.1.2 Définir une exigence fonctionnelle
      • 3.2 Cartographier les exigences techniques
        • 3.2.1 Créer une exigence technique pour tester un écran
        • 3.2.2 Gérer une exigence technique transverse
      • 3.3 Gérer les risques sur le produit
        • 3.3.1 Définir les risques sur le produit
        • 3.3.2 Définir la criticité à reporter sur les exigences à partir de celle de leurs risques
        • 3.3.3 Rédiger le dossier de stratégie
    • 4. Préparer les tests dans ProjeQtOr
      • 4.1 Préparer les jeux de données
        • 4.1.1 Le cahier des jeux d'essai
        • 4.1.2 Saisir les données : quelques astuces utiles
      • 4.2 Préparer les cas de tests
        • 4.2.1 Définir les cas de test
        • 4.2.2 Rédiger et faire rédiger les cas de test
        • 4.2.3 Regrouper des cas de test d'un point de vue fonctionnel
      • 4.3 Préparer les sessions des cas de test
        • 4.3.1 Créer une session : regrouper des cas de test
        • 4.3.2 Définir l'enchaînement des sessions, les regrouper
    • 5. Exécuter des tests avec ProjeQtOr
      • 5.1 Dérouler des tests
        • 5.1.1 Quelques contrôles préliminaires pour le référentiel
        • 5.1.2 Quelques contrôles préliminaires pour la plateforme
        • 5.1.3 Dérouler les sessions de test : GO !
      • 5.2 Gérer des tickets
        • 5.2.1 Créer un ticket pendant l'exécution d'une session
        • 5.2.2 Créer un ticket en dehors de l'exécution d'une session
        • 5.2.3 Qualifier les tickets
    • 6. Piloter votre projet
      • 6.1 Gérer l'avancement et la charge
        • 6.1.1 Saisie, soumission et validation des imputations
        • 6.1.2 Les indicateurs de suivi
        • 6.1.3 Les plannings
      • 6.2 Pour la gestion de la qualité des produits
        • 6.2.1 Le suivi des charges et le planning
        • 6.2.2 Le plan de gestion des risques
        • 6.2.3 Couverture des exigences
        • 6.2.4 Couverture des produits
        • 6.2.5 Résumé des sessions de test
        • 6.2.6 Les rapports des tickets
    • 7. Conclusion
  • Kits pratiques et exemple commenté
    • 1. Kits pratiques
      • 1.1. Pour les tests unitaires
      • 1.2. Pour la recette pompier
      • 1.3. Pour la recette technico-fonctionnelle d'une release
        • 1.3.1 ORGANISER
        • 1.3.2 PRÉPARER
        • 1.3.3 EXÉCUTER
        • 1.3.4 CLÔTURER
        • 1.3.5 PILOTER
      • 1.4. Pour une recette fonctionnelle "pure" ou VABF
    • 2. Exemple commenté
    • Index

Auteur

Emmanuel ITIÉEn savoir plus

Emmanuel Itié, est titulaire d'un Master d'informatique de l'Université de Montpellier avec une spécialisation en algorithmique renforcée et théorie des langages. Il s'est intéressé très tôt à l'expertise en homologation, pressentant l'avenir de ce marché. Aujourd'hui fort de 20 ans d'expérience dans les ESN dont 16 ans dans le test, il est directeur de projets et "change manager" au sein du groupe INTM. Il accompagne ses clients dans la mise en oeuvre des tests selon une approche industrielle.

Caractéristiques

  • Niveau Initié à Confirmé
  • Nombre de pages 466 pages
  • Parution mai 2016
    • Livre (broché) - 17 x 21 cm
    • ISBN : 978-2-409-00030-0
    • EAN : 9782409000300
    • Ref. ENI : DP2GTL
  • Niveau Initié à Confirmé
  • Parution mai 2016
    • HTML
    • ISBN : 978-2-409-00216-8
    • EAN : 9782409002168
    • Ref. ENI : LNDP2GTL

Téléchargements

En complétant ce formulaire, vous acceptez d'être contacté afin de recevoir des informations sur nos produits et services ainsi que nos communications marketing. Vous aurez la possibilité de vous désabonner de nos communications à tout moment. Pour plus d'informations sur notre politique de protection des données, cliquez ici.
  • Des fichiers complémentaires (962 Ko)