ALM Quality Center est un outil de gestion de tests reconnu chez les professionnels. Ce livre s'adresse aussi bien aux responsables de projet de test, concepteurs de test et testeurs eux-mêmes qu'aux chefs de projet (MOA ou MOE) ou développeurs d'applications qui souhaitent disposer d'une compréhension fine de l'outil et en lever la complexité apparente. Il propose également au lecteur de bonnes pratiques pour mettre en oeuvre ALM Quality Center dans leurs...
ALM Quality Center est un outil de gestion de tests reconnu chez les professionnels. Ce livre s'adresse aussi bien aux responsables de projet de test, concepteurs de test et testeurs eux-mêmes qu'aux chefs de projet (MOA ou MOE) ou développeurs d'applications qui souhaitent disposer d'une compréhension fine de l'outil et en lever la complexité apparente. Il propose également au lecteur de bonnes pratiques pour mettre en oeuvre ALM Quality Center dans leurs projets et donne les clés pour une intégration réussie de l'outil dans un contexte Agile.
Au fil des chapitres, le lecteur étudie successivement la mise en oeuvre des permissions, les fondamentaux pour gérer efficacement les releases et cycles, la construction hiérarchisée des exigences, l'organisation des tests et leur rédaction ainsi que la mise en place de campagnes de test et la gestion des anomalies. Pour finir, les derniers chapitres permettent à l'auteur d'adapter le propos à un contexte Agile afin de l'implémenter dans ALM Quality Center sans extension spécifique. Pour chaque module de Quality Center (Releases, Requirements, Test Plan, Test Lab et Defects), des personnalisations spécifiques sont proposées. Des scripts sont également disponibles en téléchargement sur le site www.editions-eni.fr.
3. Recommandations relatives à la customisation de QC
L'organisation : gérer les permissions
1. Organisation proposée
1.1 Organigramme de l'organisation des projets
1.2 Le processus de test
1.3 Les groupes ALM QC standards
1.4 Les groupes ALM QC que nous conseillons
2. Mauvaises pratiques observées
2.1 Ne pas avoir une vision claire des rôles
2.1.1 Un projet est une vision
2.1.2 Connaître ALM QC, connaître vraiment le test
2.2 Désactiver ou ignorer les modules clefs
2.3 Autoriser des modifications de données de référence
2.4 Détourner un module de son emploi
3. Les permissions de la MOA
3.1 Le module Administration
3.2 Le module Release
3.3 Le module Requirements
3.4 Le module Test Plan
3.5 Le module Test Lab
3.6 Le module Defects
3.7 Le module Dashboard
4. Les permissions du CP MOA
4.1 Le module Administration
4.2 Le module Release
4.3 Le module Requirements
4.4 Les modules Test Plan et Test Lab
4.5 Le module Defects
4.6 Le module Dashboard
5. Les permissions de la MOE
5.1 Le module Administration
5.2 Le module Release
5.3 Le module Requirements
5.4 Les modules Test Plan et Test Lab
5.5 Le module Defects
5.6 Le module Dashboard
6. Les permissions du CP MOE
6.1 Le module Administration
6.2 Le module Release
6.3 Le module Requirements
6.4 Les modules Test Plan et Test Lab
6.5 Le module Defects
6.6 Le module Dashboard
7. Les permissions de l'équipe de test
7.1 Le module Administration
7.2 Le module Release
7.3 Le module Requirements
7.4 Le module Test Plan
7.5 Le module Test Lab
7.6 Le module Defects
7.7 Le module Dashboard
8. Les permissions de chef de projet Test
8.1 Le module Administration
8.2 Le module Release
8.3 Le module Requirements
8.4 Le module Test Plan
8.5 Le module Test Lab
8.6 Le module Defects
8.7 Le module Dashboard
9. Autres profils
Gérer les Releases : les fondamentaux
1. Définitions :
1.1 Qu'est-ce qu'une Release ?
1.2 Qu'est-ce qu'un cycle ?
2. Mauvaises pratiques observées
2.1 Des Releases mal nommées
2.2 Des Releases sans cycle
2.3 Les dates de début et de fin de la Release sont identiques
2.4 Des cycles manquants
2.5 Des cycles mal nommés
2.6 Un cycle devient une livraison
2.7 Les dates de début et de fin de Cycle sont identiques
3. Customisation conseillée
3.1 Des champs supplémentaires
3.1.1 Une nouvelle liste Release Status
3.1.2 Un champ Release Status sur la Release
3.1.3 Deux champs sur le Cycle pour les estimations de charges
3.1.4 Adaptation des permissions pour nos nouveaux champs
3.2 Définir les transitions d'un workflow de Release
3.2.1 Le workflow que nous proposons
3.2.2 Implémenter les transitions dans QC
3.3 Proposition d'un script
3.3.1 Quelques principes généraux sur l'éditeur de scripts
3.3.2 Notre script pour le module Release
3.4 Organiser les Releases
3.4.1 Cartographier votre système : les folders des Releases
3.4.2 Qui contrôle la structure des folders ?
4. Mise en œuvre : avec seulement des Cycles
4.1 Pour le chef de projet Test : piloter
4.1.1 Créer la Release, la planifier et démarrer les tests
4.1.2 Abandonner une Release
4.1.3 Gérer les décalages de planning
4.1.4 Scinder un lot en deux ou ajouter un lot
4.1.5 Fusionner deux lots ou supprimer un lot
4.1.6 Mettre en production
4.1.7 Reprendre un existant
4.2 Pour les chefs de projet : suivre les Releases et les Cycles
4.2.1 Vérifier le périmètre d'une Release
4.2.2 Suivre le planning
4.2.3 L'onglet Status d'une Release : le sous-onglet Progress
4.2.4 L'onglet Status d'une Release : le sous-onglet Quality
4.2.5 Le périmètre d'un Cycle
4.2.6 L'onglet Progress d'un Cycle
4.2.7 L'onglet Quality d'un Cycle
4.3 Notre conclusion sur le module Releases
Généralités sur les exigences
1. Les catégories d'exigence
1.1 Qu'est-ce qu'une exigence ?
1.1.1 Exigences Projet, exigences Produit et tests
1.1.2 Les catégories d'exigence par défaut dans QC
1.1.3 Choix des catégories que nous utiliserons
1.2 Les exigences Business
1.2.1 Les demandes d'évolution
1.2.2 Les demandes de correction
1.3 Les exigences Produit
1.3.1 Les exigences fonctionnelles
1.3.2 Les exigences non fonctionnelles
1.4 Les exigences d'environnement
1.5 Les exigences de performance
2. Les mauvaises pratiques observées
2.1 Une mauvaise gestion des catégories d'exigence
2.1.1 Ne pas comprendre la nature des exigences
2.1.2 Ne pas utiliser les exigences Business
2.1.3 Ne pas grouper les exigences Business
2.1.4 Ne pas ou mal hiérarchiser les exigences
2.2 Ne pas utiliser les fonctions d'enrichissement
2.2.1 Mal définir les sous-exigences
2.2.2 Ne pas couvrir les exigences par des tests
2.2.3 Ne pas gérer les études d'impact
3. Customisations conseillées : deux possibilités
3.1 Les champs supplémentaires de notre customisation
3.1.1 Une liste de valeurs pour gérer un statut des Business
3.1.2 Des champs supplémentaires pour les Business
3.1.3 Configuration de la catégorie Business
3.1.4 Un champ pour les Functional, Testing et Performance
3.1.5 Configuration des catégories Functional, Testing et Performance
3.1.6 Configuration des groupes
3.1.7 Configuration des Folders
3.1.8 Configuration des Undefined et Business Model
3.2 Un workflow des Business sans la MOE
3.2.1 Modélisation du workflow n°1
3.2.2 Modifier la liste des valeurs champs Status
3.2.3 Configuration des permissions et transitions
3.2.4 Le script associé
3.3 Un workflow de Business avec la MOE
3.3.1 Modélisation du workflow n°2
3.3.2 Configuration des permissions et transitions
3.3.3 Le script associé
3.4 La customisation du Common Script
4. L'organisation de nos exigences
4.1 L'organisation des exigences Business
4.1.1 Pour le workflow n°1 sans la MOE
4.1.2 Pour le workflow n°2 avec la MOE
4.2 L'organisation des exigences Functional
4.2.1 Pour une application
4.2.2 Pour un flux
4.3 L'organisation des exigences Testing
4.3.1 Pour une base de données
4.3.2 Pour des installations d'applications ou de flux
4.3.3 Pour des fichiers de configuration
4.4 L'organisation des exigences Performance
Définir la stratégie
1. Le module Management
2. Les exigences avant l'étude d'impact
2.1 Les exigences Functional
2.1.1 L'application ALPHA
2.1.2 Les flux de nos échanges
2.2 Les exigences Testing
2.2.1 Les installations de l'application et des flux
2.2.2 Les bases de données ALPHA et OMEGA
2.3 Cycle de vie des Functional, Testing et Performance
2.3.1 Naissance d'une exigence
2.3.2 Modification ponctuelle d'une exigence
2.3.3 Modifications en masse d'exigences
2.3.4 Obsolescence d'une exigence
2.3.5 Les acteurs de ce cycle de vie
3. Les exigences Business
3.1 Les demandes de notre exemple
3.2 L'étude d'impact Produit
3.2.1 Balayer les Business et tracer les impacts dans QC
3.2.2 Modifier les Target Release et Target Cycle
3.2.3 Produire la Matrice de Traçabilité Produit avec QC
4. Initialisation de la stratégie de test
4.1 Valider l'étude d'impact
4.1.1 L'onglet Traceability Matrix
4.1.2 L'onglet Source Requirements : vérifier les impacts
4.1.3 L'onglet Trace : vérifier le périmètre
4.2 Produire un dossier de stratégie
4.3 Estimer la charge du projet de test en première analyse
5. Initialiser la couverture de test
5.1 Couvrir les exigences
5.1.1 Définir une couverture manuellement
5.1.2 Le Convert to Test : utilisation unitaire
5.1.3 Le Convert to Test : utilisation basique
5.1.4 Le Convert to Test et les sous-exigences
5.1.5 Renommer les cas de tests générés
5.2 Effectuer l'étude d'impact Test
5.2.1 Principes généraux pour construire une complétude
5.2.2 Copier un test dans QC
5.2.3 Ranger les cas d'une même exigence
5.2.4 Générer la matrice d'impact des tests
5.2.5 Produire la double matrice des impacts Produit et Test
5.3 Finaliser le dossier de stratégie
5.4 Réestimer la charge
Organiser les tests
1. Les catégories de tests selon QC
1.1 Les types prédéfinis
1.2 Les niveaux de test : le rôle des cycles
1.3 Typologies que nous traiterons
1.3.1 Les tests obsolètes
1.3.2 Les tests de non-régression priorisés
1.3.3 Nature d'un mode opératoire : testcase et usercase
1.3.4 Dégradation applicative et tests
2. Les mauvaises pratiques observées
2.1 Ne pas structurer les tests en niveaux
2.2 L'absence ou la dégradation de la couverture
2.3 Un mauvais nommage
3. Proposition d'une customisation des tests
3.1 Les listes de valeurs
3.1.1 Le statut d'un test
3.1.2 Le niveau de dégradation
3.1.3 Les priorités des tests : MoSCoW
3.2 Nos champs supplémentaires
3.2.1 Indicateur Test utilisateur
3.2.2 Indicateur de test de non-régression
3.2.3 Priorité
3.2.4 Niveau de dégradation
3.2.5 Priorité en dégradation
3.3 Le workflow des tests
3.3.1 Modélisation du workflow
3.3.2 Les permissions des groupes GRP_TEST_CP et GRP_TEST
3.3.3 Le script associé
4. Proposition d'organisation des tests
4.1 Structure principale
4.2 Structure d'une application
4.3 Structure des tests d'environnement
4.4 Le résultat exploité de manière optimale
Rédiger les tests manuels
1. Les champs clés d'un test : les bons réflexes
1.1 Comment référencer un test ?
1.2 Est-ce un test de non-régression ?
1.3 Quelle priorité accorder à un test ?
1.4 Est-ce un test exécutable par un utilisateur ?
1.5 Qui rédige le test ? Quel statut de conception ?
2. Décrire un test avec QC
2.1 Comment formaliser un test ?
2.1.1 Le sondage
2.1.2 Décrire un test
2.1.3 Qu'est-ce qu'un mode opératoire ?
2.1.4 Qu'est-ce que l'échantillonnage ?
2.1.5 Un assistant de test pour les tests en masse
2.2 Modes opératoires : comment les classons-nous ?
2.2.1 Test d'une fonction utilisateur
2.2.2 Test d'une IHM
2.2.3 Test d'une intégration de données entrantes
2.2.4 Test d'extraction de données sortantes
2.2.5 Test d'un flux
2.2.6 Test d'un fichier de logs
2.2.7 Test d'un traitement de génération d'e-mails
2.2.8 Test d'un traitement de génération d'alertes
2.2.9 Test d'un traitement batch
2.2.10 Test d'installation
2.2.11 Test de modification d'une base de données
2.2.12 Test de modification d'un fichier de configuration
2.2.13 Test de performance
3. Décrire encore mieux un test
3.1 Inclure des steps techniques, une simulation
3.2 Les paramètres
3.2.1 Créer des paramètres
3.2.2 Utiliser les paramètres dans le mode opératoire d'un test
3.2.3 Affecter des valeurs au moment de construire la campagne
3.2.4 Affecter les valeurs au moment de l'exécution du test
3.3 Les configurations
3.3.1 Qu'est-ce qu'une configuration dans QC ?
3.3.2 Valoriser des paramètres dans une configuration
3.3.3 Créer une nouvelle configuration
3.3.4 Ajouter une configuration pour construire une campagne
3.3.5 Exécuter une configuration
3.3.6 La combinatoire des configurations
3.4 Appeler un test : le "call"
3.4.1 Définir des modèles de test
3.4.2 Appeler un modèle de test
3.4.3 Appeler un test paramétré
3.4.4 Et les appels imbriqués ?
Organiser les campagnes dans le Test Lab
1. Définition d'une campagne
1.1 La théorie : les éléments de vocabulaire
1.2 La pratique dans QC
1.2.1 Les folders du module Test Lab
1.2.2 Les Test Sets du module Test Lab
1.2.3 Le module Test Run
2. Les mauvaises pratiques observées
2.1 Ne pas structurer les campagnes
2.2 Ne pas lier les folders aux cycles des releases
2.3 Ne pas gérer l'équipe
2.4 Ne pas exécuter les steps
2.5 Autoriser le testeur à ajouter des tests dans un Test Set
2.6 Ne pas clôturer l'activité
3. Organisation des campagnes dans le Test Lab
3.1 Principe d'organisation des projets
3.2 Initialiser un projet de test
3.2.1 Notre modèle d'un cycle de test d'une release
3.2.2 Les projets à plusieurs lots : copions le modèle !
3.2.3 Les projets multireleases
3.2.4 Nomenclature des Test Sets : affectations et configurations
3.3 Construire un Test Set
3.3.1 Depuis les Requirements : le périmètre impacté
3.3.2 Depuis le Test Plan : les tests de non-régression
3.3.3 Ordonnancement simple des tests
3.3.4 Ordonnancement complexe : le Flow Execution
3.4 Affiner les affectations
3.4.1 Affecter chaque test à un testeur
3.4.2 Vérifier la répartition entre les testeurs
3.5 Valider le périmètre
3.5.1 Depuis le module Requirements
3.5.2 Depuis le Test Plan
3.5.3 Depuis le Test Lab
3.6 Finaliser le dossier de stratégie
4. Piloter l'exécution des campagnes
4.1 Gérer les livraisons exceptionnelles
4.2 Gérer la disponibilité de la plate-forme
4.3 Suivre les campagnes
4.3.1 Le Live Analysis
4.3.2 Le Test Board
4.3.3 L'onglet Progress d'une release ou d'un cycle
4.3.4 Le Dash Board
4.4 Clôturer le travail
4.4.1 Clôturer les Test Sets
4.4.2 Clôturer un projet de test
Gérer les anomalies
1. Définition d'un Defect
1.1 Rappels de définitions normées
1.1.1 Défaut, vice caché et anomalie
1.1.2 Non-conformité et dysfonctionnement
1.1.3 L'incident, la panne : tout ce qui n'est pas un défaut
1.2 Le Defect dans QC
2. Les mauvaises pratiques observées
2.1 Confondre le défaut et le Defect
2.2 Confondre Defect et correctif
2.3 Détourner les champs d'un defect
2.4 Mal customiser les champs des releases et cycles
2.5 Définir un mauvais workflow
2.6 Gérer les évolutions dans le module Defects
3. Customisations conseillées : plusieurs possibilités
3.1 Les champs supplémentaires d'un Defect
3.1.1 Le champ standard Status
3.1.2 Les nouvelles listes
3.1.3 Les nouveaux champs
3.1.4 Les permissions des nouveaux champs
3.2 Avertissements préalables
3.2.1 Ne jamais utiliser les trois wizards proposés par QC !
3.2.2 Quels workflows possibles ?
3.2.3 Les notifications : l'Automail
3.3 La MOA d'abord
3.3.1 Modélisation du workflow n°1
3.3.2 Configuration des permissions et transitions
3.3.3 Le script associé
3.4 La MOE d'abord
3.4.1 Modélisation du workflow n°2
3.4.2 Configuration des permissions et transitions
3.4.3 Le script associé
3.5 Des Defects sans l'équipe MOE ?
3.5.1 Modélisation du workflow n°3
3.5.2 Configuration des permissions et transitions
3.5.3 Le script associé
4. Mise en application des workflows
4.1 Déclarer une anomalie
4.1.1 Anomalie déclarée sur un cycle de test
4.1.2 Anomalie déclarée en cycle de VABF ou pendant les tests Métier
4.1.3 Anomalie sur un cycle de production
4.1.4 Les champs supplémentaires : le deuxième onglet
4.2 Qualifier et résoudre une anomalie
4.2.1 Rejeter le défaut
4.2.2 Ouvrir le défaut
4.2.3 Corriger le défaut
4.2.4 Résoudre le défaut
4.3 Clôturer une anomalie
4.3.1 Anomalie déclarée en phase de test
4.3.2 Anomalie déclarée en VABF ou pendant les tests Métier
4.3.3 Anomalie de production
5. Le reporting des Defects
5.1 Rappels du module Management
5.1.1 Le reporting sur une Release
5.1.2 Le reporting sur un cycle
5.2 Defects et Dashboard
5.2.1 Le reporting global prédéfini
5.2.2 Le reporting sur une release
Organiser un projet Agile avec QC
1. Rappels des principes de l'Agilité
1.1 Avertissements
1.2 Naissance de l'Agilité : le Manifeste Agile
1.3 Quelle place pour le test dans le Manifeste Agile ?
1.4 Les Processus Agiles les plus populaires
1.5 Les concepts SCRUM que nous aborderons
2. Quelle organisation ?
2.1 Sans équipe Test transverse
2.2 Avec équipe Test transverse
2.3 Quelles permissions dans QC en SCRUM ?
2.3.1 Qui est le Développeur Agile ?
2.3.2 Qui est le Scrum Master ?
2.3.3 Qui est le Product Owner ?
2.3.4 Qui est le représentant d'un utilisateur ?
2.4 Les rôles de l'équipe Test transverse dans le cycle Agile
2.4.1 Valider les Items
2.4.2 Construire et maintenir le référentiel de test
2.4.3 Le chef de projet Test
2.5 Les limites
2.5.1 La charge de la validation des Items dans un Sprint
2.5.2 Capitaliser les tests des Items ?
2.5.3 Vers l'automatisation des tests ?
3. L'implémentation dans Quality Center
3.1 Organisation sans participation aux Sprints
3.1.1 Les Releases dans le module Management
3.1.2 Le workflow des releases
3.1.3 Et la customisation ?
3.2 Organisation avec participation aux Sprints
3.2.1 Les releases d'un projet de test Agile
3.2.2 Le workflow des releases
3.2.3 Et la customisation ?
3.3 Organisation d'un projet de test en intégration continue
3.3.1 Une unique release pour un projet en intégration continue
3.3.2 Le workflow d'une release continue
3.3.3 Et la customisation ?
Gérer des backlogs dans QC
1. Représenter des backlogs dans QC
1.1 Mauvaises pratiques observées
1.1.1 Confondre les spécifications et le logiciel
1.1.2 Un workflow pour presque tout faire
1.1.3 Pas de niveau de test en Agilité
1.2 Les représentations que nous proposons dans QC
1.2.1 Un Item est une exigence Business
1.2.2 Le cas particulier du "boulet technique"
1.2.3 Une Épopée est un Group
1.2.4 Comment représenter une Feature ?
1.3 Représenter le Backlog et les Sprint Backlogs dans QC
1.3.1 Le ou les backlogs sont des objets Group
1.3.2 Les Sprint Backlogs sont des objets Group
1.3.3 Les Items "bonus"
1.4 Gérer les features
1.4.1 Relation entre Items et Features : liens Trace To/Trace From
1.4.2 Relation avec les cycles des releases
2. L'équipe Agile utilise QC comme outil Agile
2.1 Un champ Complexité en plus dans pour les Requirements
2.1.1 Créer le champ Complexité
2.1.2 Configurer le champ Complexité
2.2 Définir un champ Priorité pour les Business
2.2.1 Ne pas utiliser le champ standard Priorité de QC
2.2.2 Notre propre champ Priorité spécifique aux Business
2.3 L'équipe Test ne participe pas aux Sprints
2.3.1 Modélisation du workflow Agile n°1
2.3.2 Configuration des permissions et transitions
2.3.3 Le script associé
2.4 L'équipe Test participe aux Sprints
2.4.1 Modélisation du workflow Agile n°2
2.4.2 Configuration des permissions et transitions
2.4.3 Le script
3. L'équipe Agile n'utilise pas QC
3.1 Absence de workflow des Business dans QC
3.2 Redescendre les Items dans QC
3.2.1 Synchronisation manuelle
3.2.2 Synchronisation automatique
Gérer les tests des Items
1. Les organisations possibles
1.1 Si l'équipe Test ne valide pas les Items
1.2 Si l'équipe Test valide les Items
1.2.1 Sans QC
1.2.2 Avec QC ?
2. Modifier la customisation pour l'Agilité
2.1 Le paramétrage des exigences Business
2.2 Les permissions des groupes sur les tests Agile
2.2.1 Les permissions du Product Owner (Grp_MOA_CP)
2.2.2 Les permissions des représentants des utilisateurs (Grp_MOA)
2.2.3 Les permissions des développeurs (Grp_MOE)
2.2.4 Les permissions de l'équipe Test
3. Concevoir les tests : utiliser le Convert to Test
3.1 Où générer les tests ?
3.1.1 Dans les backlogs ?
3.1.2 Dans les Sprint Backlogs en préparation ?
3.1.3 Dans le Sprint en cours
3.1.4 Archiver les tests de validation
3.2 Et la maintenance des tests ?
3.2.1 L'Agilité : une logique de consommation
3.2.2 Et copier les tests des Items ?
4. Valider les Items dans le Test Lab
4.1 Construire le périmètre d'un Sprint Backlog
4.1.1 Qui construit le périmètre ?
4.1.2 Où dans la hiérarchie du Test Lab ?
4.1.3 Sprints et Test Sets
4.2 Les validations des Items dans le Test Lab
4.2.1 Exécuter les Tests Sets
4.2.2 Le statut d'exécution des Business
4.2.3 Le reporting
5. Gérer ou ne pas gérer les Defects ?
5.1 Pourquoi cette question ?
5.1.1 De l'influence des contrats
5.1.2 La lourdeur de la démarche
5.1.3 L'acceptation par les développeurs
5.2 Saisir un Defect pendant un Sprint
5.2.1 La déclaration
5.2.2 La résolution
5.2.3 La clôture
6. Les inconvénients
6.1 QC n'est pas fondamentalement orienté vers l'Agilité
6.1.1 Pas de kanban, pas d'indicateurs Agiles
6.1.2 Trop de concepts abstraits loin de l'Agilité
6.2 La méconnaissance de QC
6.2.1 Les Business ne sont pas comprises comme étant des Items
6.2.2 Les tests de validation des Items ne sont pas compris
6.2.3 Les Defects : l'outil de ticketing
Emmanuel ITIÉ
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.
Editions ENI Livres | Vidéos | e-Formations
