ALM quality center : maîtrise de l'outil et bonnes pratiques

Auteur(s) :

Itié, Emmanuel Découvrir l'auteur

Résumé

ALM Quality Center est un outil de gestion de test. Ce manuel à destination des responsables de projet, concepteurs de test et testeurs fournit une compréhension fine de l'outil pour permettre l'adoption de bonnes pratiques. Sont notamment examinées la mise en oeuvre des permissions d'une organisation tripartite et la construction hiérarchisée des exigences. Avec des téléchargements en ligne. ©Electre 2020

Éditeur(s)
- Éditions ENI
Date
- C 2020
Notes
- La couv. porte en plus : "En téléchargement : scripts , modèles" ; "Version en ligne offerte ! pendant 1 an" ; "+ quiz"
- ALM = Application lifecycle management
Langues
- Français
Description matérielle
- 1 vol. (592 p.) : ill. ; 22 cm
Collections
- Epsilon
Sujet(s)
ISBN
- 978-2-409-02448-1
Indice
- 681.5 Réseaux informatiques
Quatrième de couverture
- ALM Quality Center
  Maîtrise de l'outil et bonnes pratiques
  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 .
Tables des matières
- - ALM Quality Center
  - Maîtrise de l'outil et bonnes pratiques
  - Éditions ENI
  - Introduction
  - 1. Introduction17
  - 2. Avertissements18
  - 3. Recommandations relatives à la customisation de QC19
  - Chapitre 1
  - L'organisation : gérer les permissions
  - 1. Organisation proposée21
  - 1.1 Organigramme de l'organisation des projets21
  - 1.2 Le processus de test23
  - 1.3 Les groupes ALM QC standards24
  - 1.4 Les groupes ALM QC que nous conseillons25
  - 2. Mauvaises pratiques observées28
  - 2.1 Ne pas avoir une vision claire des rôles28
  - 2.1.1 Un projet est une vision28
  - 2.1.2 Connaître ALM QC, connaître vraiment le test28
  - 2.2 Désactiver ou ignorer les modules clefs30
  - 2.3 Autoriser des modifications de données de référence31
  - 2.4 Détourner un module de son emploi31
  - 3. Les permissions de la MOA32
  - 3.1 Le module Administration32
  - 3.2 Le module Release33
  - 3.3 Le module Requirements34
  - 3.4 Le module Test Plan37
  - 3.5 Le module Test Lab38
  - 3.6 Le module Defects39
  - 3.7 Le module Dashboard42
  - 4. Les permissions du CP MOA42
  - 4.1 Le module Administration42
  - 4.2 Le module Release43
  - 4.3 Le module Requirements44
  - 4.4 Les modules Test Plan et Test Lab46
  - 4.5 Le module Defects46
  - 4.6 Le module Dashboard47
  - 5. Les permissions de la MOE48
  - 5.1 Le module Administration48
  - 5.2 Le module Release49
  - 5.3 Le module Requirements49
  - 5.4 Les modules Test Plan et Test Lab52
  - 5.5 Le module Defects53
  - 5.6 Le module Dashboard54
  - 6. Les permissions du CP MOE54
  - 6.1 Le module Administration54
  - 6.2 Le module Release55
  - 6.3 Le module Requirements55
  - 6.4 Les modules Test Plan et Test Lab55
  - 6.5 Le module Defects55
  - 6.6 Le module Dashboard57
  - 7. Les permissions de l'équipe de test58
  - 7.1 Le module Administration58
  - 7.2 Le module Release59
  - 7.3 Le module Requirements59
  - 7.4 Le module Test Plan63
  - 7.5 Le module Test Lab63
  - 7.6 Le module Defects66
  - 7.7 Le module Dashboard67
  - 8. Les permissions de chef de projet Test68
  - 8.1 Le module Administration68
  - 8.2 Le module Release69
  - 8.3 Le module Requirements70
  - 8.4 Le module Test Plan70
  - 8.5 Le module Test Lab70
  - 8.6 Le module Defects72
  - 8.7 Le module Dashboard73
  - 9. Autres profils73
  - Chapitre 2
  - Gérer les Releases : les fondamentaux
  - 1. Définitions :75
  - 1.1 Qu'est-ce qu'une Release ?75
  - 1.2 Qu'est-ce qu'un cycle ?77
  - 2. Mauvaises pratiques observées81
  - 2.1 Des Releases mal nommées81
  - 2.2 Des Releases sans cycle82
  - 2.3 Les dates de début et de fin de la Release sont identiques82
  - 2.4 Des cycles manquants83
  - 2.5 Des cycles mal nommés83
  - 2.6 Un cycle devient une livraison83
  - 2.7 Les dates de début et de fin de Cycle sont identiques84
  - 3. Customisation conseillée85
  - 3.1 Des champs supplémentaires85
  - 3.1.1 Une nouvelle liste Release Status85
  - 3.1.2 Un champ Release Status sur la Release86
  - 3.1.3 Deux champs sur le Cycle pour les estimations de charges ...87
  - 3.1.4 Adaptation des permissions pour nos nouveaux champs88
  - 3.2 Définir les transitions d'un workflow de Release89
  - 3.2.1 Le workflow que nous proposons89
  - 3.2.2 Implémenter les transitions dans QC90
  - 3.3 Proposition d'un script92
  - 3.3.1 Quelques principes généraux sur l'éditeur de scripts92
  - 3.3.2 Notre script pour le module Release94
  - 3.4 Organiser les Releases100
  - 3.4.1 Cartographier votre système : les folders des Releases100
  - 3.4.2 Qui contrôle la structure des folders ?102
  - 4. Mise en oeuvre : avec seulement des Cycles103
  - 4.1 Pour le chef de projet Test : piloter103
  - 4.1.1 Créer la Release, la planifier et démarrer les tests103
  - 4.1.2 Abandonner une Release104
  - 4.1.3 Gérer les décalages de planning104
  - 4.1.4 Scinder un lot en deux ou ajouter un lot107
  - 4.1.5 Fusionner deux lots ou supprimer un lot108
  - 4.1.6 Mettre en production108
  - 4.1.7 Reprendre un existant108
  - 4.2 Pour les chefs de projet : suivre les Releases et les Cycles109
  - 4.2.1 Vérifier le périmètre d'une Release109
  - 4.2.2 Suivre le planning109
  - 4.2.3 L'onglet Status d'une Release : le sous-onglet Progress110
  - 4.2.4 L'onglet Status d'une Release : le sous-onglet Quality111
  - 4.2.5 Le périmètre d'un Cycle114
  - 4.2.6 L'onglet Progress d'un Cycle115
  - 4.2.7 L'onglet Quality d'un Cycle118
  - 4.3 Notre conclusion sur le module Releases119
  - Chapitre 3
  - Généralités sur les exigences
  - 1. Les catégories d'exigence121
  - 1.1 Qu'est-ce qu'une exigence ?121
  - 1.1.1 Exigences Projet, exigences Produit et tests121
  - 1.1.2 Les catégories d'exigence par défaut dans QC122
  - 1.1.3 Choix des catégories que nous utiliserons124
  - 1.2 Les exigences Business125
  - 1.2.1 Les demandes d'évolution125
  - 1.2.2 Les demandes de correction128
  - 1.3 Les exigences Produit129
  - 1.3.1 Les exigences fonctionnelles129
  - 1.3.2 Les exigences non fonctionnelles130
  - 1.4 Les exigences d'environnement130
  - 1.5 Les exigences de performance131
  - 2. Les mauvaises pratiques observées132
  - 2.1 Une mauvaise gestion des catégories d'exigence132
  - 2.1.1 Ne pas comprendre la nature des exigences132
  - 2.1.2 Ne pas utiliser les exigences Business133
  - 2.1.3 Ne pas grouper les exigences Business133
  - 2.1.4 Ne pas ou mal hiérarchiser les exigences134
  - 2.2 Ne pas utiliser les fonctions d'enrichissement135
  - 2.2.1 Mal définir les sous-exigences135
  - 2.2.2 Ne pas couvrir les exigences par des tests136
  - 2.2.3 Ne pas gérer les études d'impact139
  - 3. Customisations conseillées : deux possibilités140
  - 3.1 Les champs supplémentaires de notre customisation140
  - 3.1.1 Une liste de valeurs pour gérer un statut des Business140
  - 3.1.2 Des champs supplémentaires pour les Business141
  - 3.1.3 Configuration de la catégorie Business142
  - 3.1.4 Un champ pour les Functional, Testing et Performance143
  - 3.1.5 Configuration des catégories Functional, Testing et Performance144
  - 3.1.6 Configuration des groupes145
  - 3.1.7 Configuration des Folders145
  - 3.1.8 Configuration des Undefined et Business Model145
  - 3.2 Un workflow des Business sans la MOE146
  - 3.2.1 Modélisation du workflow n° l146
  - 3.2.2 Modifier la liste des valeurs champs Status147
  - 3.2.3 Configuration des permissions et transitions147
  - 3.2.4 Le script associé149
  - 3.3 Un workflow de Business avec la MOE167
  - 3.3.1 Modélisation du workflow n° 2167
  - 3.3.2 Configuration des permissions et transitions169
  - 3.3.3 Le script associé171
  - 3.4 La customisation du Common Script190
  - 4. L'organisation de nos exigences193
  - 4.1 L'organisation des exigences Business194
  - 4.1.1 Pour le workflow n° l sans la MOE194
  - 4.1.2 Pour le workflow n° 2 avec la MOE195
  - 4.2 L'organisation des exigences Functional197
  - 4.2.1 Pour une application197
  - 4.2.2 Pour un flux199
  - 4.3 L'organisation des exigences Testing200
  - 4.3.1 Pour une base de données201
  - 4.3.2 Pour des installations d'applications ou de flux201
  - 4.3.3 Pour des fichiers de configuration202
  - 4.4 L'organisation des exigences Performance202
  - Chapitre 4
  - Définir la stratégie
  - 1. Le module Management203
  - 2. Les exigences avant l'étude d'impact205
  - 2.1 Les exigences Functional205
  - 2.1.1 L'application ALPHA205
  - 2.1.2 Les flux de nos échanges206
  - 2.2 Les exigences Testing207
  - 2.2.1 Les installations de l'application et des flux207
  - 2.2.2 Les bases de données ALPHA et OMEGA208
  - 2.3 Cycle de vie des Functional, Testing et Performance208
  - 2.3.1 Naissance d'une exigence208
  - 2.3.2 Modification ponctuelle d'une exigence209
  - 2.3.3 Modifications en masse d'exigences210
  - 2.3.4 Obsolescence d'une exigence212
  - 2.3.5 Les acteurs de ce cycle de vie212
  - 3. Les exigences Business213
  - 3.1 Les demandes de notre exemple213
  - 3.2 L'étude d'impact Produit214
  - 3.2.1 Balayer les Business et tracer les impacts dans QC214
  - 3.2.2 Modifier les Target Release et Target Cycle218
  - 3.2.3 Produire la Matrice de Traçabilité Produit avec QC221
  - 4. Initialisation de la stratégie de test224
  - 4.1 Valider l'étude d'impact225
  - 4.1.1 L'onglet Traceability Matrix225
  - 4.1.2 L'onglet Source Requirements : vérifier les impacts226
  - 4.1.3 L'onglet Trace : vérifier le périmètre227
  - 4.2 Produire un dossier de stratégie228
  - 4.3 Estimer la charge du projet de test en première analyse229
  - 5. Initialiser la couverture de test230
  - 5.1 Couvrir les exigences230
  - 5.1.1 Définir une couverture manuellement230
  - 5.1.2 Le Convert to Test : utilisation unitaire231
  - 5.1.3 Le Convert to Test : utilisation basique234
  - 5.1.4 Le Convert to Test et les sous-exigences239
  - 5.1.5 Renommer les cas de tests générés240
  - 5.2 Effectuer l'étude d'impact Test241
  - 5.2.1 Principes généraux pour construire une complétude241
  - 5.2.2 Copier un test dans QC241
  - 5.2.3 Ranger les cas d'une même exigence242
  - 5.2.4 Générer la matrice d'impact des tests243
  - 5.2.5 Produire la double matrice des impacts Produit et Test248
  - 5.3 Finaliser le dossier de stratégie250
  - 5.4 Réestimer la charge251
  - Chapitre 5
  - Organiser les tests
  - 1. Les catégories de tests selon QC253
  - 1.1 Les types prédéfinis253
  - 1.2 Les niveaux de test : le rôle des cycles254
  - 1.3 Typologies que nous traiterons256
  - 1.3.1 Les tests obsolètes256
  - 1.3.2 Les tests de non-régression priorisés257
  - 1.3.3 Nature d'un mode opératoire : testcase et usercase258
  - 1.3.4 Dégradation applicative et tests259
  - 2. Les mauvaises pratiques observées261
  - 2.1 Ne pas structurer les tests en niveaux261
  - 2.2 L'absence ou la dégradation de la couverture262
  - 2.3 Un mauvais nommage263
  - 3. Proposition d'une customisation des tests264
  - 3.1 Les listes de valeurs264
  - 3.1.1 Le statut d'un test264
  - 3.1.2 Le niveau de dégradation265
  - 3.1.3 Les priorités des tests : MoSCoW266
  - 3.2 Nos champs supplémentaires267
  - 3.2.1 Indicateur Test utilisateur267
  - 3.2.2 Indicateur de test de non-régression268
  - 3.2.3 Priorité269
  - 3.2.4 Niveau de dégradation270
  - 3.2.5 Priorité en dégradation271
  - 3.3 Le workflow des tests272
  - 3.3.1 Modélisation du workflow272
  - 3.3.2 Les permissions des groupes GRP_TEST_CP et GRP_TEST. .275
  - 3.3.3 Le script associé277
  - 4. Proposition d'organisation des tests291
  - 4.1 Structure principale291
  - 4.2 Structure d'une application292
  - 4.3 Structure des tests d'environnement295
  - 4.4 Le résultat exploité de manière optimale296
  - Chapitre 6
  - Rédiger les tests manuels
  - 1. Les champs clés d'un test : les bons réflexes299
  - 1.1 Comment référencer un test ?299
  - 1.2 Est-ce un test de non-régression ?301
  - 1.3 Quelle priorité accorder à un test ?301
  - 1.4 Est-ce un test exécutable par un utilisateur ?302
  - 1.5 Qui rédige le test ? Quel statut de conception ?304
  - 2. Décrire un test avec QC305
  - 2.1 Comment formaliser un test ?305
  - 2.1.1 Le sondage305
  - 2.1.2 Décrire un test306
  - 2.1.3 Qu'est-ce qu'un mode opératoire ?307
  - 2.1.4 Qu'est-ce que l'échantillonnage ?310
  - 2.1.5 Un assistant de test pour les tests en masse311
  - 2.2 Modes opératoires : comment les classons-nous ?312
  - 2.2.1 Test d'une fonction utilisateur312
  - 2.2.2 Test d'une IHM313
  - 2.2.3 Test d'une intégration de données entrantes317
  - 2.2.4 Test d'extraction de données sortantes318
  - 2.2.5 Test d'un flux319
  - 2.2.6 Test d'un fichier de logs319
  - 2.2.7 Test d'un traitement de génération d'e-mails320
  - 2.2.8 Test d'un traitement de génération d'alertes321
  - 2.2.9 Test d'un traitement batch321
  - 2.2.10 Test d'installation322
  - 2.2.11 Test de modification d'une base de données323
  - 2.2.12 Test de modification d'un fichier de configuration323
  - 2.2.13 Test de performance325
  - 3. Décrire encore mieux un test326
  - 3.1 Inclure des steps techniques, une simulation326
  - 3.2 Les paramètres328
  - 3.2.1 Créer des paramètres329
  - 3.2.2 Utiliser les paramètres dans le mode opératoire d'un test330
  - 3.2.3 Affecter des valeurs au moment de construire la campagne331
  - 3.2.4 Affecter les valeurs au moment de l'exécution du test332
  - 3.3 Les configurations334
  - 3.3.1 Qu'est-ce qu'une configuration dans QC ?334
  - 3.3.2 Valoriser des paramètres dans une configuration335
  - 3.3.3 Créer une nouvelle configuration337
  - 3.3.4 Ajouter une configuration pour construire une campagne338
  - 3.3.5 Exécuter une configuration340
  - 3.3.6 La combinatoire des configurations341
  - 3.4 Appeler un test : le « call »342
  - 3.4.1 Définir des modèles de test343
  - 3.4.2 Appeler un modèle de test344
  - 3.4.3 Appeler un test paramétré347
  - 3.4.4 Et les appels imbriqués ?348
  - Chapitre 7
  - Organiser les campagnes dans le Test Lab
  - 1. Définition d'une campagne349
  - 1.1 La théorie : les éléments de vocabulaire349
  - 1.2 La pratique dans QC350
  - 1.2.1 Les folders du module Test Lab351
  - 1.2.2 Les Test Sets du module Test Lab353
  - 1.2.3 Le module Test Run355
  - 2. Les mauvaises pratiques observées355
  - 2.1 Ne pas structurer les campagnes356
  - 2.2 Ne pas lier les folders aux cycles des releases357
  - 2.3 Ne pas gérer l'équipe358
  - 2.4 Ne pas exécuter les steps359
  - 2.5 Autoriser le testeur à ajouter des tests dans un Test Set359
  - 2.6 Ne pas clôturer l'activité360
  - 3. Organisation des campagnes dans le Test Lab361
  - 3.1 Principe d'organisation des projets361
  - 3.2 Initialiser un projet de test362
  - 3.2.1 Notre modèle d'un cycle de test d'une release362
  - 3.2.2 Les projets à plusieurs lots : copions le modèle !365
  - 3.2.3 Les projets multireleases366
  - 3.2.4 Nomenclature des Test Sets : affectations et configurations366
  - 3.3 Construire un Test Set368
  - 3.3.1 Depuis les Requirements : le périmètre impacté368
  - 3.3.2 Depuis le Test Plan : les tests de non-régression369
  - 3.3.3 Ordonnancement simple des tests372
  - 3.3.4 Ordonnancement complexe : le Flow Execution372
  - 3.4 Affiner les affectations376
  - 3.4.1 Affecter chaque test à un testeur376
  - 3.4.2 Vérifier la répartition entre les testeurs377
  - 3.5 Valider le périmètre379
  - 3.5.1 Depuis le module Requirements379
  - 3.5.2 Depuis le Test Plan380
  - 3.5.3 Depuis le Test Lab381
  - 3.6 Finaliser le dossier de stratégie381
  - 4. Piloter l'exécution des campagnes383
  - 4.1 Gérer les livraisons exceptionnelles383
  - 4.2 Gérer la disponibilité de la plate-forme384
  - 4.3 Suivre les campagnes385
  - 4.3.1 Le Live Analysis385
  - 4.3.2 Le Test Board386
  - 4.3.3 L'onglet Progress d'une release ou d'un cycle387
  - 4.3.4 Le Dash Board389
  - 4.4 Clôturer le travail389
  - 4.4.1 Clôturer les Test Sets389
  - 4.4.2 Clôturer un projet de test390
  - Chapitre 8
  - Gérer les anomalies
  - 1. Définition d'un Defect391
  - 1.1 Rappels de définitions normées391
  - 1.1.1 Défaut, vice caché et anomalie391
  - 1.1.2 Non-conformité et dysfonctionnement392
  - 1.1.3 L'incident, la panne : tout ce qui n'est pas un défaut392
  - 1.2 Le Defect dans QC393
  - 2. Les mauvaises pratiques observées395
  - 2.1 Confondre le défaut et le Defect395
  - 2.2 Confondre Defect et correctif396
  - 2.3 Détourner les champs d'un defect396
  - 2.4 Mal customiser les champs des releases et cycles397
  - 2.5 Définir un mauvais workflow397
  - 2.6 Gérer les évolutions dans le module Defects398
  - 3. Customisations conseillées : plusieurs possibilités400
  - 3.1 Les champs supplémentaires d'un Defect400
  - 3.1.1 Le champ standard Status400
  - 3.1.2 Les nouvelles listes401
  - 3.1.3 Les nouveaux champs404
  - 3.1.4 Les permissions des nouveaux champs410
  - 3.2 Avertissements préalables412
  - 3.2.1 Ne jamais utiliser les trois wizards proposés par QC !412
  - 3.2.2 Quels workflows possibles ?413
  - 3.2.3 Les notifications : l'Automail415
  - 3.3 La MOA d'abord416
  - 3.3.1 Modélisation du workflow n° 1416
  - 3.3.2 Configuration des permissions et transitions418
  - 3.3.3 Le script associé421
  - 3.4 La MOE d'abord450
  - 3.4.1 Modélisation du workflow n° 2450
  - 3.4.2 Configuration des permissions et transitions451
  - 3.4.3 Le script associé454
  - 3.5 Des Defects sans l'équipe MOE ?456
  - 3.5.1 Modélisation du workflow n° 3456
  - 3.5.2 Configuration des permissions et transitions457
  - 3.5.3 Le script associé457
  - 4. Mise en application des workflows457
  - 4.1 Déclarer une anomalie457
  - 4.1.1 Anomalie déclarée sur un cycle de test457
  - 4.1.2 Anomalie déclarée en cycle de VABF ou pendant les tests Métier461
  - 4.1.3 Anomalie sur un cycle de production462
  - 4.1.4 Les champs supplémentaires : le deuxième onglet463
  - 4.2 Qualifier et résoudre une anomalie464
  - 4.2.1 Rejeter le défaut464
  - 4.2.2 Ouvrir le défaut465
  - 4.2.3 Corriger le défaut465
  - 4.2.4 Résoudre le défaut465
  - 4.3 Clôturer une anomalie466
  - 4.3.1 Anomalie déclarée en phase de test466
  - 4.3.2 Anomalie déclarée en VABF ou pendant les tests Métier467
  - 4.3.3 Anomalie de production468
  - 5. Le reporting des Defects468
  - 5.1 Rappels du module Management468
  - 5.1.1 Le reporting sur une Release468
  - 5.1.2 Le reporting sur un cycle469
  - 5.2 Defects et Dashboard470
  - 5.2.1 Le reporting global prédéfini470
  - 5.2.2 Le reporting sur une release472
  - Chapitre 9
  - Organiser un projet Agile avec QC
  - 1. Rappels des principes de l'Agilité475
  - 1.1 Avertissements475
  - 1.2 Naissance de l'Agilité : le Manifeste Agile475
  - 1.3 Quelle place pour le test dans le Manifeste Agile ?477
  - 1.4 Les Processus Agiles les plus populaires478
  - 1.5 Les concepts SCRUM que nous aborderons478
  - 2. Quelle organisation ?480
  - 2.1 Sans équipe Test transverse480
  - 2.2 Avec équipe Test transverse481
  - 2.3 Quelles permissions dans QC en SCRUM ?481
  - 2.3.1 Qui est le Développeur Agile ?481
  - 2.3.2 Qui est le Scrum Master ?482
  - 2.3.3 Qui est le Product Owner ?482
  - 2.3.4 Qui est le représentant d'un utilisateur ?482
  - 2.4 Les rôles de l'équipe Test transverse dans le cycle Agile482
  - 2.4.1 Valider les Items482
  - 2.4.2 Construire et maintenir le référentiel de test484
  - 2.4.3 Le chef de projet Test484
  - 2.5 Les limites485
  - 2.5.1 La charge de la validation des Items dans un Sprint485
  - 2.5.2 Capitaliser les tests des Items ?486
  - 2.5.3 Vers l'automatisation des tests ?488
  - 3. L'implémentation dans Quality Center489
  - 3.1 Organisation sans participation aux Sprints489
  - 3.1.1 Les Releases dans le module Management489
  - 3.1.2 Le workflow des releases490
  - 3.1.3 Et la customisation ?491
  - 3.2 Organisation avec participation aux Sprints492
  - 3.2.1 Les releases d'un projet de test Agile492
  - 3.2.2 Le workflow des releases493
  - 3.2.3 Et la customisation ?493
  - 3.3 Organisation d'un projet de test en intégration continue495
  - 3.3.1 Une unique release pour un projet en intégration continue495
  - 3.3.2 Le workflow d'une release continue496
  - 3.3.3 Et la customisation ?496
  - Chapitre 10
  - Gérer des backlogs dans QC
  - 1. Représenter des backlogs dans QC499
  - 1.1 Mauvaises pratiques observées499
  - 1.1.1 Confondre les spécifications et le logiciel499
  - 1.1.2 Un workflow pour presque tout faire500
  - 1.1.3 Pas de niveau de test en Agilité502
  - 1.2 Les représentations que nous proposons dans QC503
  - 1.2.1 Un Item est une exigence Business504
  - 1.2.2 Le cas particulier du « boulet technique »504
  - 1.2.3 Une Epopée est un Group505
  - 1.2.4 Comment représenter une Feature ?506
  - 1.3 Représenter le Backlog et les Sprint Backlogs dans QC507
  - 1.3.1 Le ou les backlogs sont des objets Group507
  - 1.3.2 Les Sprint Backlogs sont des objets Group508
  - 1.3.3 Les Items « bonus »509
  - 1.4 Gérer les features509
  - 1.4.1 Relation entre Items et Features : liens Trace To/Trace From509
  - 1.4.2 Relation avec les cycles des releases510
  - 2. L'équipe Agile utilise QC comme outil Agile511
  - 2.1 Un champ Complexité en plus dans pour les Requirements512
  - 2.1.1 Créer le champ Complexité512
  - 2.1.2 Configurer le champ Complexité513
  - 2.2 Définir un champ Priorité pour les Business514
  - 2.2.1 Ne pas utiliser le champ standard Priorité de QC514
  - 2.2.2 Notre propre champ Priorité spécifique aux Business514
  - 2.3 L'équipe Test ne participe pas aux Sprints515
  - 2.3.1 Modélisation du workflow Agile n° 1515
  - 2.3.2 Configuration des permissions et transitions517
  - 2.3.3 Le script associé518
  - 2.4 L'équipe Test participe aux Sprints527
  - 2.4.1 Modélisation du workflow Agile n° 2527
  - 2.4.2 Configuration des permissions et transitions528
  - 2.4.3 Le script529
  - 3. L'équipe Agile n'utilise pas QC530
  - 3.1 Absence de workflow des Business dans QC530
  - 3.2 Redescendre les Items dans QC531
  - 3.2.1 Synchronisation manuelle531
  - 3.2.2 Synchronisation automatique533
  - Chapitre 11
  - Gérer les tests des Items
  - 1. Les organisations possibles535
  - 1.1 Si l'équipe Test ne valide pas les Items535
  - 1.2 Si l'équipe Test valide les Items536
  - 1.2.1 Sans QC536
  - 1.2.2 Avec QC ?536
  - 2. Modifier la customisation pour l'Agilité537
  - 2.1 Le paramétrage des exigences Business537
  - 2.2 Les permissions des groupes sur les tests Agile538
  - 2.2.1 Les permissions du Product Owner (Grp_MOA_CP)538
  - 2.2.2 Les permissions des représentants des utilisateurs (Grp_MOA)538
  - 2.2.3 Les permissions des développeurs (Grp_MOE)539
  - 2.2.4 Les permissions de l'équipe Test541
  - 3. Concevoir les tests : utiliser le Convert to Test541
  - 3.1 Où générer les tests ?542
  - 3.1.1 Dans les backlogs ?542
  - 3.1.2 Dans les Sprint Backlogs en préparation ?542
  - 3.1.3 Dans le Sprint en cours543
  - 3.1.4 Archiver les tests de validation543
  - 3.2 Et la maintenance des tests ?543
  - 3.2.1 L'Agilité : une logique de consommation543
  - 3.2.2 Et copier les tests des Items ?544
  - 4. Valider les Items dans le Test Lab544
  - 4.1 Construire le périmètre d'un Sprint Backlog545
  - 4.1.1 Qui construit le périmètre ?545
  - 4.1.2 Où dans la hiérarchie du Test Lab ?546
  - 4.1.3 Sprints et Test Sets548
  - 4.2 Les validations des Items dans le Test Lab549
  - 4.2.1 Exécuter les Tests Sets549
  - 4.2.2 Le statut d'exécution des Business550
  - 4.2.3 Le reporting550
  - 5. Gérer ou ne pas gérer les Defects ?551
  - 5.1 Pourquoi cette question ?551
  - 5.1.1 De l'influence des contrats551
  - 5.1.2 La lourdeur de la démarche552
  - 5.1.3 L'acceptation par les développeurs553
  - 5.2 Saisir un Defect pendant un Sprint553
  - 5.2.1 La déclaration553
  - 5.2.2 La résolution554
  - 5.2.3 La clôture554
  - 6. Les inconvénients554
  - 6.1 QC n'est pas fondamentalement orienté vers l'Agilité555
  - 6.1.1 Pas de kanban, pas d'indicateurs Agiles555
  - 6.1.2 Trop de concepts abstraits loin de l'Agilité555
  - 6.2 La méconnaissance de QC556
  - 6.2.1 Les Business ne sont pas comprises comme étant des Items556
  - 6.2.2 Les tests de validation des Items ne sont pas compris556
  - 6.2.3 Les Defects : l'outil de ticketing557
  - Conclusion559
  - Index561
Origine de la notice:
- Electre