ALD - ISTQB Fondation - Chapitre 5 - V1.2

Aldemia Campus Touch
Formation
ISTQB Niveau Fondation
Chapitre 5
Gestion des tests
225 mn
1 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite
Notes de lecture
• Des pictos caractéristiques illustrent certains aspects du contenu :
➢ Point d’attention en vue de la préparation aux QCM
➢ Point d’attention, niveau de complexité élevé
➢ Expression issue du syllabus
➢ Définition extraite du glossaire ISTQB

Glossaire
➢ Information complémentaire, digression

Sommaire du chapitre 5
« Gestion des tests »
5.1 Organisation des tests 5.3 Pilotage et contrôle des tests

5.1.1 Indépendance des tests 5.3.1 Métriques utilisées pour les tests
5.1.2 Tâches d’un Test Manager et d’un testeur 5.3.2 Buts, contenu et destinataires des rapports de test
5.2 Planification et estimation des tests 5.4 Gestion de configuration
5.2.1 Objet et contenu d'un plan de test 5.5 Gestion des risques
5.2.2 Stratégie de test et approche de test 5.3.1 Métriques utilisées pour les tests
5.2.3 Critères d'entrée et de sortie – définition du 5.3.2 Buts, contenu et destinataires des rapports de test
prêt et définition du terminé
5.5.3 Test basé sur les risques et qualité du produit
5.2.4 Calendrier d'exécution des tests
5.2.5 Facteurs influençant l'effort de test 5.6 Gestion des défauts
5.2.6 Techniques d'estimation des tests

Chapitre 5 – Les objectifs pédagogiques
Niveau
§ Réf. objectifs Objectifs
apprentissage
5.1 FL-5.1.1 Expliquer les bénéfices et inconvénients du test indépendant K2
5.1 FL-5.1.1 Identifier les tâches d'un Test Manager et d'un testeur K1
5.2 FL-5.2.1 Résumer l'objectif et le contenu d'un plan de test K2
5.2 FL-5.2.2 Expliquer les différences entre plusieurs stratégies de test K2
5.2 FL-5.2.3 Donner des exemples de critères d'entrée et de critères de sortie possibles K2
Appliquer les informations de priorité et de dépendances techniques et logiques pour

5.2 FL-5.2.4 K3
ordonnancer l'exécution d'un ensemble donné de cas de test
5.2 FL-5.2.5 Identifier des facteurs qui influencent l'effort relatif au test K1
Expliquer les différences entre deux techniques d'estimation : la technique basée sur des
5.2 FL-5.2.6 K2
métriques et la technique basée sur l'expertise
5.3 FL-5.3.1 Se souvenir des métriques utilisées pour les tests K1
5.3 FL-5.3.2 Résumer les objectifs, contenus et destinataires des rapports de test K2
5.4 FL-5.4.1 Résumer comment la gestion de configuration vient en appui des tests K2
5.5 FL-5.5.1 Définir le niveau de risque à partir de la probabilité d'occurrence et de l'impact K1
5.5 FL-5.5.2 Décrire la différence entre les risque projet et les risques produit K2
Décrire, en utilisant des exemples, comment l'analyse des risques produit peut influencer
5.5 FL-5.5.3 K2
la complétude et le périmètre des tests
5.6 FL-5.6.1 Écrire un rapport de défaut couvrant les défauts trouvés pendant les tests K3
Chapitre 5 – Les termes du glossaire
Glossaire

5.1
Organisation des tests

5.1 Organisation des tests
❑ Une organisation des tests est indispensable pour un déroulement optimisé du processus de test

5.1.1 Indépendance des tests
❑ La séparation des responsabilités dans le test :
➢ Par les niveaux de test :
▪ Des natures d’acteurs différentes interviennent selon les objectifs de test, par exemples :
Métier-Utilisateurs
Exploitation
Testeur indépendant
Développeur

Légende :
❑ La séparation des responsabilités dans le test par niveau
d’indépendance des tests :
1 2 3
Développeur/Testeur Développeurs Testeurs Développeurs Testeurs

Équipe développement Équipe projet Équipe de test
Équipe projet
Organisation Organisation Organisation
➢ Pas de testeur indépendant ➢ Développeurs et testeurs appartiennent à la ➢ Équipe de test indépendante au sein d’une
➢ Le développeur teste son propre code même équipe même organisation
4 5
Développeurs Testeurs Développeurs Testeurs externes
Équipe projet Organisation métier Équipe projet
Organisation Organisation Équipe de test

➢ Des testeurs indépendants appartenant à l’organisation ➢ Des testeurs indépendants externes à
métier ou à la communauté d’utilisateurs, ou spécialisés l'organisation, sur site ou hors site
dans le test non fonctionnel
❑ L’organisation du test dans un modèle agile :
➢ Cas 1 :
• Le testeur fait partie de Testeurs
l’équipe :
Testeur
➢ Cas 2 :
• Une équipe de test indépendante en support à l’équipe
• Le product owner peut effectuer des tests d'acceptation pour
valider les User Stories à la fin de chaque itération.
Testeurs

❑ Avantages et inconvénients de l’indépendance des tests
➢ Les testeurs indépendants sont susceptibles de détecter des ➢ Les testeurs peuvent être isolés de l'équipe de développement,
types de défaillances différents par rapport aux développeurs en ce qui entraîne un manque de collaboration, des retards dans
raison de leurs connaissances propres, de leurs approches la communication des retours d'information à l'équipe de
techniques et de biais différents développement ou une relation conflictuelle avec l'équipe de
développement
➢ Un testeur indépendant peut vérifier, contester ou réfuter les
hypothèses formulées par les parties prenantes au cours de la ➢ Les développeurs peuvent perdre le sens des responsabilités
spécification et de l'implémentation du système vis-à-vis de la qualité
➢ Les testeurs indépendants peuvent être considérés comme un

goulot d'étranglement ou être rendus responsables des retards
dans la sortie de la version
➢ Les testeurs indépendants peuvent ne pas disposer de

certaines informations importantes sur l'objet de test

5.5.2 Tâches d’un Test Manager et d’un testeur
❑ Le test manager ❑ Le testeur
➢ Responsabilité globale du processus de test ➢ Des responsabilités sur l’analyse, la conception,
➢ Conduite des activités de test l’automatisation, le test non fonctionnel
➢ Le rôle peut aussi être tenu par un chef de projet, ➢ Le rôle peut être tenu par différents acteurs selon les
un responsable du développement ou un niveaux de test :
responsable de l'assurance qualité.
▪ Composant ➢ Développeurs
▪ Intégration ➢ Développeurs
❑ Dans un contexte agile
▪ Système ➢ Équipe de test indépendante
➢ Des tâches du test manager sont prises en charge ▪ Acceptation ➢ Analyste métier, expert domaine,
par l’équipe agile, par ex. les tâches liées aux tests utilisateurs, exploitation
quotidiens réalisés par un testeur travaillant au sein
de l'équipe

❑ Le test manager :
➢ Développer ou revoir une politique de test et une ➢ Adapter la planification en fonction des résultats et de
stratégie de test pour l’organisation l’avancement des tests
➢ Planifier les activités de test en tenant compte du ➢ Prendre toutes les mesures nécessaires au contrôle des
contexte y compris les objectifs et les risques du test. tests
➢ Rédiger et mettre à jour le(s) plan(s) de test ➢ Aider la mise en place du système de gestion des
➢ Coordonner le(s) plan(s) de test avec les chefs de défauts et à la gestion adéquate de la configuration des
projet, les product owners et d'autres parties testware
prenantes ➢ Introduire les métriques appropriées pour mesurer
➢ Partager différents aspects des tests avec d'autres l’avancement des tests et évaluer la qualité des tests et
activités du projet, comme la planification de du produit
l'intégration
➢ Accompagner la sélection et la mise en œuvre des outils
➢ Lancer l'analyse, la conception, l'implémentation et pour soutenir le processus de test
l'exécution des tests
➢ Décider de l'implémentation du ou des environnements
➢ Suivre l'avancement et les résultats des tests et de test
vérifier le statut des critères de sortie ou de la
définition du terminé – cf. agile ➢ Promouvoir et soutenir les testeurs, l'équipe de test et le
métier du test au sein de l'organisation
➢ Préparer et fournir des rapports d'avancement des
tests et des rapports de synthèse des tests basés sur ➢ Développer les compétences et les carrières des
les informations recueillies testeurs

❑ Le testeur :
➢ Revoir et contribuer aux plans de test ➢ Créer le planning détaillé d'exécution des tests
➢ Analyser, revoir et évaluer les exigences, les user ➢ Exécuter des tests, évaluer les résultats et documenter
stories et leurs critères d'acceptation, les spécifications les écarts par rapport aux résultats attendus
et les modèles vis à vis de leur testabilité
➢ Utiliser les outils appropriés pour faciliter le processus
➢ Identifier et documenter les conditions de test, et saisir de test
la traçabilité entre les cas de test, les conditions de
test et les bases de test ➢ Automatiser les tests selon les besoins (peut être porté
par un développeur ou un expert en automatisation des
➢ Concevoir, configurer et vérifier le ou les tests)
environnement(s) de test, souvent se coordonnant
avec l'administration système et réseau ➢ Évaluer les caractéristiques non fonctionnelles telles que
la performance, la fiabilité, l’utilisabilité, la sécurité, la
➢ Concevoir et implémenter les cas de test et les
procédures de test compatibilité et la portabilité
➢ Préparer et acquérir des données de test ➢ Revoir des tests développés par d'autres

Révisions
❑ Rappeler les 5 niveaux d’indépendance du test.
❑ Énumérer des tâches typiques du test manager.
❑ Énumérer des tâches typiques du test testeur.
❑ Quel rôle réalise plutôt les tests d’intégration ?

5.2
Planification et estimation des tests

5.2 Planification et estimation des tests
❑ La planification est la 1ère activité du processus de test
➢ Plan de test
➢ Plans de test
par niveau
❑ Le plan de test est le produit d’activité de l’activité de planification

❑ La planification est de la responsabilité du test manager

5.2.1 Objet et contenu d'un plan de test
❑ Le plan de test est le produit d’activité de la planification pour :
➢ Décrire les activités de test pour des projets de développement et de maintenance.
Stratégie
de test Cycle de
Disponibilité développement
des ressources du projet
Étendue
Testabilité Facteurs des tests
impactants le
plan de test
Criticité Objectifs
Contraintes Risques

❑ Les éléments constituant un plan de test :
➢ Déterminer le périmètre, les objectifs et les risques des tests
➢ Définir l'approche générale des tests
➢ Intégrer et coordonner les activités de test dans les activités du cycle de vie du logiciel
➢ Prendre des décisions sur ce qu'il faut tester, les personnes et les autres ressources nécessaires pour
effectuer les diverses activités de test et la façon dont les activités de test seront effectuées
➢ Planifier les activités d'analyse, de conception, d'implémentation, d'exécution et d'évaluation des tests,
soit à des dates particulières (p. ex., en développement séquentiel) ou dans le contexte de chaque
itération (p. ex., en développement itératif)
➢ Sélectionner les métriques pour le pilotage et le contrôle des tests
➢ Budgéter les activités de test
➢ Déterminer le niveau de détail et la structure de la documentation des tests (par ex. en fournissant des
modèles ou des exemples de documents)

❑ Le sommaire du plan de test d’après la norme IEEE 29119-3 « Software and systems
engineering - Software testing - Part 3: Test documentation »
1. Identification du 3. Périmètres 4. Caractéristiques

2. Introduction
document des tests à tester
5. Caractéristiques 7. Critères d’entrée 8.Critères de suspension

6. Approches
à ne pas tester et de sortie et de reprise
11. Environnement
9. Livrables 10. Détail des tâches 12. Responsabilités
de test
13. Ressources 15. Risques et

14. Planning 16. Approbations
humaines contingences

5.2.2 Stratégie de test et approche de test
❑ Une stratégie de test fournit une description générale du processus de test
➢ Généralement conçue au niveau du produit ou de l'organisation
➢ Des stratégies de test peuvent être complémentaires selon le contexte du projet
Exemple :
• Pour un projet de développement d’un site marchand en mode agile qui
se base sur une analyse des risques métier, le test manager s’inspire de
2 stratégies de test établies par l’organisation :
➢ La stratégie de test analytique basée sur les risques
➢ La stratégie de test réactive pour mettre en place le test exploratoire
❑ L’approche de test ajuste la stratégie de test selon le contexte du projet

➢ Ces ajustements sont décidés en tenant compte des facteurs tels que :
• Les risques • La nature du système
• La sécurité • Les objectifs des tests
• Les ressources et les compétences disponibles • Les réglementations.
• La technologie

Glossaire
❑ Les définitions du glossaire :
Stratégie de test Approche de test
Documentation qui exprime les L’implémentation de la stratégie de

exigences génériques pour tester test pour un projet spécifique.
dans le cadre d'un ou de plusieurs
projets exécutés au sein d'une
organisation, fournissant des détails
sur la façon dont les tests doivent être
effectués, et qui est alignée sur la
politique de test.

Analytique
• Le test basé sur les risques est un exemple d'approche analytique, où les tests sont conçus et priorisés en fonction du niveau de risque
Basée sur les modèles
• Les tests sont conçus à partir d'un modèle d'un aspect requis du produit, comme une fonction, un processus métier, une structure
interne ou une caractéristique non fonctionnelle
Méthodique
• Ce type de stratégie de test repose sur l'utilisation systématique d'un ensemble prédéfini de tests ou de conditions de test
Conforme à un processus
• La stratégie de test de test se base sur des règles et normes externes (industrielles, avioniques…)
Dirigée ou consultative
• Ce type de stratégie de test est principalement dicté par les recommandations, les conseils ou les instructions des parties prenantes
Anti régressions
• L’objectif est d'éviter la régression au niveau des fonctionnalités existantes avec la réutilisation des testwares existants et la promotion
de l’automatisation
Réactive
• Le test est adapté en réaction aux événements se produisant pendant l'exécution des tests, plutôt que préplanifié

5.2.3 Critères d'entrée et de sortie, définition du prêt et définition du terminé
Glossaire
❑ Définitions : Critères d’entrée Critères de sortie
L'ensemble des conditions L'ensemble des conditions

pour le démarrage formel d'une pour la complétion formelle
tâche définie. d'une tâche définie.
Synonyme : définition du prêt Synonyme : définition du terminé
❑ Objectifs :
➢ Exercer un contrôle efficace sur la qualité du logiciel et des tests
➢ Disposer d’indicateurs pour décider :
➔ quand une activité de test donnée doit commencer ➔ quand une activité de test est terminée
❑ Principes de mises en œuvre :

➢ Les critères d’entrée et les critères de sortie sont définis en phase de planification
➢ Ils peuvent être définis par :
➔ niveau de test ➔ type de test ➔ objectifs de test
➢ Ils sont analysés régulièrement en phase de pilotage et contrôle en comparant :
➔ Les critères prévus en phase de planification VS l‘état d’avancement de la phase en cours

❑ Illustration et exemples :
Critères d’entrée
1. Les critères d’entrée suivants sont définis en phase de
planification pour sécuriser le démarrage de l’exécution des
tests système :
• L’environnement est prêt au regard des exigences ❑ Critère d’entrée 1
exprimées ❑ Critère d’entrée 2
❑ Critère d’entrée 3
• Les jeux de données sont livrés ❑ Critère d’entrée 4
• Les suites de test pour couvrir les exigences de priorité
importante et haute sont créées
• L’objet à tester est déployé
Exécution tests
• Le résultat du test d’admission est satisfaisant système
2. Les critères d’entrée sont analysés à chaque comité de suivi
3. Au dernier comité de suivi les critères d’entrée sont tous
complétés
4. Le GO est donné pour démarrer la phase d’exécution des test
système

❑ Illustration et exemples :
Critères de sortie
1. Les critères de sortie suivants sont définis en phase de
planification pour évaluer le niveau de qualité du produit en
test système :
❑ Critère de sortie 1
• 100 % des exigences de priorité importante et haute sont ❑ Critère de sortie 2
couvertes par des résultats de tests satisfaisants ❑ Critère de sortie 3
• 80 % des exigences de priorité moyenne et basse sont ❑ Critère de sortie 4
couvertes par des résultats de tests satisfaisants
• Tous les défauts concernant des exigences de priorité
importante et haute sont clôturés
• Tous les correctifs de défauts résiduels non clôturés sont Exécution tests
planifiés pour une livraison dans un lot ultérieur système
2. Les critères de sortie sont analysés à chaque comité de suivi
3. Au dernier comité de suivi les critères de sortie sont tous
complétés
4. La fin des tests système sont confirmés, le rapport de
synthèse est établi.
❑ Focus sur le contexte agile :
« Définition du prêt »
➢ La definition du prêt – Definition Of Ready (DOR) – est la
liste, définie par l’équipe, des éléments attendus qu’une
user story doit rassembler pour être candidate au
développement.
« Définition du terminé »
➢ La definition du terminé – Definition of Done (DOD) – permet
de définir si une tâche ou une user story est traitée
➢ Objectifs :
• Donner un critère objectif qui permet de décider qu’une
user story a été traitée ou non
• Éviter que l’équipe ne commence trop de choses sans Exemple de tableau de suivi de l’avancement des US, dans un
réellement les finir modèle scrum
• Contribuer à la qualité de ce qui a été produit

❑ Objectifs : ➢ Préparer le planning d’exécution des tests
➢ Définir l’ordre d’exécution des suites de test
❑ Principes de mise en œuvre :
Tenir compte des niveaux de priorité des tests
• Les tests couvrant les exigences des priorités les plus hautes sont exécutés en premier
Tenir compte du périmètre de tests de régression identifié
• Réserver une période d’exécution pour le périmètre de tests de régression identifié
Évaluer une période pour les tests de confirmation
• Réserver une période d’exécution pour la confirmation des correctifs des défauts
Tenir compte des dépendances entre les tests ou entre les

caractéristiques testées
• Les dépendances entre les tests ou leurs caractéristiques à tester impactent la priorité d’exécution
donc la planification

❑ Exemple :
➢ Contexte : la période prévue pour le test système est de 6 semaines
Périmètre des
tests système Périmètre de tests
de régression
Les suites de test sont
(TNR) Périodes réservées pour les
créées et ordonnées selon
tests de confirmation
les priorités des tests :
➢ P1
➢ P2
➢ P3
P3
P1 P2 TC TNR TC TNR TC TNR TC
S1 S2 S3 S4 S5 S6

❑ Exercice : Contexte
• Projet de développement d’un site marchand disponible sur touts les types de
plateformes mobiles
• Les fournisseurs de matériels des infrastructures de test informent de retards de
livraison de certains matériels; d'autre part, la direction de projet confirme
l'impossibilité de décaler la mise en prod
• Ces évènements impactent le plan d'exécution des tests initial : tous les tests
prévus ne pourront pas être exécutés sur toutes les infrastructures matérielles
décidées dans la stratégie de test.
➢ Quelles modifications pourraient être apportées au planning initial d'exécution des tests ?
Propositions pour la modification du planning d’exécution :

• Mise en œuvre d’un parcours en profondeur associé à la dépendance de la
disponibilité des plateformes mobiles :
1.Tester les fonctionnalités les plus critiques sur la plate forme cible, soit par exemple
la dernière version d'OS et les 4 dernières révisions sur 4 marques de mobiles
sélectionnées et pendant la période de mise à disposition de la plate forme
2.Tester les fonctionnalités les moins critiques sur une plate forme se rapprochant de
la cible

5.2.5 Facteurs influençant l'effort de test
❑ Objectifs de l’effort de test :
➢ Estimer la quantité de travail lié aux tests qui sera nécessaire pour atteindre les objectifs de test d'un
projet, d'une version ou d'une itération particulière
Facteurs influençant l’effort de test :
Caractéristiques du produit Caractéristiques du processus de développement
➢ Les risques associés au produit ➢ La stabilité et la maturité de l'organisation
➢ La qualité des bases de test ➢ Le modèle de développement utilisé
➢ La taille du produit ➢ L'approche de test
➢ La complexité du domaine métier du produit ➢ Les outils utilisés
➢ Les exigences relatives aux caractéristiques de qualité ➢ Le processus de test
➢ Le niveau de détail requis pour la documentation des tests ➢ La pression des délais
➢ Les exigences en matière de conformité juridique et réglementaire
Caractéristiques liées aux personnes Résultats des tests
➢ Les compétences et l'expérience des personnes impliquées, en ➢ Le nombre et la sévérité des défauts trouvés
particulier avec des projets et des produits similaires ➢ La quantité nécessaire de travail à refaire
➢ La cohésion et le leadership de l'équipe

❑ Les techniques d’estimation sont regroupées en 2 catégories :
Technique basée sur les métriques
• L’effort de test est estimé sur la base de métriques d'anciens projets similaires ou sur la base de
valeurs représentatives
Technique basée sur l'expertise
• L’effort de test est estimé sur la base de l'expérience des responsables des tâches de test ou par
des experts

Techniques basées sur les métriques
Contexte agile ❑ Burndown charts :

➢ Les estimations sont recueillies et enregistrées
➢ Elles sont ensuite utilisées pour déterminer la charge de l'équipe pour la prochaine itération
➢ La charge est suivi sur un tableau d’avancement – le « burndown chart » - permettant de suivre la
progression du développement d’un sprint, avec en abscisse : la charge en jours et en ordonnée :
la durée du sprint
Cycle séquentiel ❑ Modèle de correction des défauts :

➢ Un volume de défauts et le temps nécessaire pour les éliminer sont recueillis et enregistrés
➢ Il est utilisé comme base pour estimer les projets futurs de nature similaire

Techniques basées sur l’expertise
Contexte agile ❑ Planning poker :

➢ Une technique d'estimation basée sur le consensus pour estimer l'effort ou la taille relative des
user stories
➢ Le principe :
▪ L’équipe vote ensemble pour estimer chaque élément en recherchant le consensus, sur 1, 2 ou 3 tours
➢ L’outil :
▪ Un jeu de cartes avec des valeurs représentant les estimations de charges de l'équipe.
Cycle séquentiel ❑ Wideband Delphi :

➢ Une méthode itérative qui fait appel aux capacités des acteurs à chiffrer leurs propres tâches :
▪ Étape 1 : Chaque expert donne anonymement une estimation en utilisant sa propre expérience. Ensuite tous
les jugements sont rendus publics, mais anonymes
▪ Étape 2 : Chaque expert revoit son estimation ou la confirme. Les nouvelles estimations sont rendues
publiques et chacun peut justifier de son jugement
▪ Étape 3 : Chacun peut proposer une révision de son estimation. Les estimations de la troisième phase sont
prises en compte pour constituer l’estimation du groupe, le plus souvent sous la forme d’une estimation
moyenne. Les experts s’accordent sur une estimation consensuelle

Glossaire
❑ Définitions :
Burndown chart
Un graphique partagé qui représente

l'effort réalisé par rapport au temps dans
une itération. Il montre l'état et la Planning poker
tendance de la complétion des tâches
de l'itération. L'axe des X représente Une technique d'estimation basée sur le
généralement les jours du sprint, tandis consensus, utilisée la plupart du temps
que l'axe des Y représente l'effort pour estimer l'effort ou la taille relative
restant (habituellement soit en heures des User Stories en développement
d'ingénierie optimales, soit en points). logiciel Agile. C'est une variation de la Wideband Delphi
méthode Wideband Delphi utilisant un
jeu de cartes avec des valeurs Technique d’estimation de test basée
représentant les estimations de charges sur des experts ayant pour objectif de
de l'équipe. fournir une estimation correcte en
utilisant la connaissance collective des
membres de l’équipe.

Révisions
❑ Donner des exemples pertinents de critères d’entrée
❑ Donner des exemples pertinents de critères de sortie
❑ Citer des éléments qui constituent le contenu d’un plan de test
❑ À quel moment du processus de test est préparé le calendrier d'exécution des tests ?
❑ Nommer des techniques d’estimation de l’effort de test dans utilisées dans un contexte agile
❑ Nommer des techniques d’estimation de l’effort de test dans utilisées en cycle en V

5.3
Pilotage et contrôle des tests

5.3 Pilotage et contrôle des tests
Test manager
L’activité de pilotage L’activité de contrôle
➢ Recueillir des informations ➢ Reprioriser les tests lorsqu'un risque identifié se produit,
➢ Fournir un retour et de la visibilité sur les activités de test par exemple : le périmètre de test augmente
➢ Évaluer l'avancement du test pour : ➢ Modifier le calendrier des tests en raison de la
• Mesurer si les critères de sortie du test, ou les tâches disponibilité ou de l'indisponibilité d'un environnement de
de test associées au définition of done – cf. agile – test ou d'autres ressources
sont satisfaits ➢ Réévaluer si une condition de test et/ou un cas de test
répond à un critère de sortie à cause d'une modification
rapport
d'avancement
de test

5.3 Métriques utilisées pour les tests
L’avancement par rapport au calendrier et au budget prévus
Les métriques reportées

La qualité actuelle de l'objet de test
rapport d'avancement dans le rapport
de test d'avancement de test
permettent d’évaluer :
La pertinence de l`approche de test
L’efficacité des activités de test par rapport aux objectifs

5.3.1 Métriques utilisées pour les tests
❑ Les métriques les plus courantes :
➢ Pourcentage du temps de travail prévu réalisé pour la préparation des cas de test ou le pourcentage des cas
de test prévus implémentés dans des suites de test
➢ Pourcentage du travail prévu réalisé pour la préparation de l'environnement de test
✓ Nombre de cas de test exécutés, non exécutés

➢ Exécution des cas de test, par exemples ➔ ✓ Cas de test réussis, échoués
✓ Conditions de test réussies, échouées
✓ Densité des défauts
➢ Informations sur les défauts, par exemples ➔ ✓ Défauts trouvés et corrigés
✓ Taux de défaillance
✓ Résultats des tests de confirmation
➢ Couverture des exigences, des user stories, des critères d'acceptation, des risques ou du code par les tests
➢ Degré d'achèvement des tâches, affectation et utilisation des ressources, et temp passé
➢ Coût des tests, y compris en comparaison avec le bénéfice apporté par la découverte des défauts
supplémentaires ou le coût par rapport au bénéfice de l'exécution de tests supplémentaires

5.3.2 Buts, contenu et destinataires des rapports de test
❑ Objectifs du rapport de test :
➢ Synthétiser les informations collectées pour produire les métriques
➢ Communiquer les métriques et justifications
❑ Focus sur le rapport de test :

➢ Au cours d’une activité ➔ Rapport d'avancement de test
➢ En fin d’une activité ➔ Rapport de synthèse de test
Planning test système

P3
P1 P2 TC TNR TC TNR TC TNR TC
S1 S2 S3 S4 S5 S6
Rapport de
S5 synthèse de test
S1 S2 S3 S4
Rapport AVT Rapport AVT Rapport AVT Rapport AVT Rapport AVT
de test de test de test de test de test

❑ Contenu du RAPPORT d’avancement de test :
➢ Le statut des activités de test et l’avancement par rapport au plan de test
Rapport
de test ➢ Les facteurs qui freinent l'avancement
➢ Les tests prévus pour la prochaine période de suivi
➢ La qualité de l'objet de test
❑ Contenu du rapport de SYNTHESE de test :

rapport de
➢ Récapitulatif des tests réalisés
synthèse de
test ➢ Informations sur le déroulement de la période de test
➢ Écarts par rapport au plan, y compris les écarts par rapport au calendrier, à la durée ou à l'effort consacré aux
activités de test
➢ Statut des tests et de la qualité du produit par rapport aux critères de sortie ou à la définition du terminé
➢ Facteurs ayant bloqué ou bloquant l’avancement
➢ Métriques sur les défauts, les cas de test, la couverture de test, l’avancement de l'activité et la consommation de
ressources – cf. 5.3.1
➢ Risques résiduels – à découvrir en 5.5
➢ Produits d'activités de test réutilisables
En cycle en V
❑ Nature du contenu d’un rapport de test : 45
40
➢ Dépendante du contexte du projet

35
30
25 Mineure
➢ Dépendante de la complexité du projet Contexte agile 20

Majeure
Bloquante
15
➔ Des métriques plus ou moins détaillées 10
➢ Dépendante des destinataires ciblés

0
Nouvelle
Contestée
Corrigée non
Prise en
En cours
compte
livrée
➔ Des métriques différentes selon la partie prenante
Tech lead Métier Direction de projet

Rapport de test Rapport de test Rapport de test
➢ Des informations ➢ Couverture des ➢ Écarts délais et

détaillées sur les exigences métier budget par rapport
défaillances ➢ Exigences métiers au plan de test
➢ Les résultats des VS défauts identifiés
tests de par priorité
confirmation

Révisions
❑ Quels sont les objectifs des activités de pilotage ?
❑ Quels sont les objectifs des activités de contrôle ?
❑ Quels sont les produits d’activités du pilotage et du contrôle des tests ?
❑ À qui sont destinés les produits d’activités du pilotage et du contrôle ?

5.4
Gestion de configuration

5.1 Gestion de configuration
❑ Objectifs :
➢ Établir et maintenir l'intégrité du composant ou du système et du testware
➢ Favoriser leurs relations mutuelles tout au long du cycle de vie du projet et du produit, via la traçabilité
❑ Exigences de mise en œuvre d’une gestion de configuration :

➢ Tous les éléments de test sont identifiés de façon unique, versionnés, suivis pour les changements et reliés les uns
aux autres
➢ Tous les éléments du testware sont identifiés de manière unique, versionnés, suivis pour les changements, liés les
uns aux autres et liés aux versions des éléments de test afin que la traçabilité puisse être maintenue tout au long
du processus de test
➢ Tous les documents et logiciels identifiés sont référencés sans ambiguïté dans la documentation de test
➢ Les procédures de gestion de la configuration et son infrastructure doivent être spécifiées lors de la planification et
reportées dans le plan de test

Glossaire
❑ Définitions :
Gestion de configuration
Une discipline appliquant une direction et

surveillance technique et administrative
pour identifier et documenter les
caractéristiques fonctionnelles et Testware
physiques d’un élément de configuration,
contrôler les modifications de ces Produits d’activités réalisés au Traçabilité
caractéristiques, enregistrer et informer cours du processus de test
des modifications et états pour la planification, la
La mesure dans laquelle
d’implémentation, et vérifier la conformité conception, l'exécution,
une relation peut être établie
avec des exigences spécifiées. l'évaluation et l'établissement
entre deux ou plusieurs
de rapports sur les tests.
produits d’activités.

❑ Exemple de mise en œuvre d’une gestion de configuration :
Contexte
• Dans une organisation, le test n'est pas industrialisé ni dirigé par un spécialiste du test. Un des
inconvénients majeurs pour les projets IT est l'absence de gestion de référentiels des éléments de
test (exigences et cas de test)
• Ces éléments de tests ne sont pas capitalisés de version en version : ils sont ré écrits à chaque fois
ou quand ils sont exécutés via des techniques basées sur l'expérience, les pratiques requises par
l'ISTQB de concevoir les tests au moment de leur exécution ne sont pas respectées
• La direction de projet commande un audit pour définir un plan d’actions pour l’industrialisation de
son processus de test.
Plan d’actions
• La mise en place d’une gestion de configuration des référentiels de test est préconisée, entre autres
actions
• La gestion de configuration doit définir :
✓ Le stockage des exigences et cas de test dans ✓ Une nomenclature de nommage des exigences
un outil de gestion des tests et des cas de test
✓ La traçabilité entre exigences et cas de test ✓ Des critères pour définir leur niveau de
✓ L’organisation arborescente des exigences et granularité selon les contextes des projets
cas de test par processus métier ✓ Les profils des utilisateurs en charge de leur
conception, maintenance, historisation…
5.5
Risques et tests

5.5.1 Définition du risque
❑ Le risque résulte de la possibilité qu’un événement futur provoque des conséquences négatives
Le risque est caractérisé par 2 caractéristiques pour être évalué dans le cadre du projet
1- La
probabilité
d’une chute
2-
L’impact
de la chute
Niveau de risque = niveau Probabilité * niveau Impact

❑ Évaluation du niveau de risque :
➢ Les niveaux de PROBABILITE et d’IMPACT sont chacun matérialisés par une liste de valeurs
Chute impossible 5 Blessures légères 1

occurrence
Probabilité
Impact
Chute peu probable 10 Blessures graves 2
/
Chute probable 15 Blessures très graves 3

Chute certaine 20 Blessures irrémédiables 4
➢ Les 2 listes de valeurs sont agréges pour constituer la matrice d’évaluation des niveaux de risques :
Probabilité / occurrence
Chute impossible Chute peu probable Chute probable Chute certaine
5 10 15 20
Blessures légères 1 5 10 15 20
Impact
Blessures graves 2 10 20 30 40
Blessures très graves 3 15 30 45 60
Blessures irrémédiables 4 20 40 60 80
Faible
➢ Le niveau de risque évalué produit le niveau de criticité : Moyenne
Haute

Glossaire
❑ Définitions :
Risque Niveau de risque
Un facteur qui pourrait Mesure qualitative ou

avoir des conséquences quantitative d'un risque
négatives à l'avenir. défini par l'impact et la
probabilité.
Synonyme : exposition au risque
Risque produit Risque projet
Un risque directement lié à Un risque qui a une

l’objet de test. incidence sur la réussite
du projet.

5.5.2 Risques projet et risques produit
Risque
PRODUIT
➢ C’est la possibilité qu'un produit d’activités – une spécification, un composant, un système ou un test – puisse ne pas
satisfaire les besoins de ses utilisateurs et/ou parties prenantes.
Le logiciel peut ne pas remplir les fonctions attendues selon la
spécification
Une structure de contrôle de boucle peut être mal codée
Le logiciel peut ne pas remplir les fonctions attendues selon les
besoins de l'utilisateur, du client et/ou des parties prenantes
Les délais de réponse peuvent être insatisfaisants pour un système
de traitement des transactions à haut niveau de performance
Une architecture système peut ne pas répondre de manière
adéquate à certaines exigences non fonctionnelles
L'expérience utilisateur pourrait ne pas satisfaire les attentes pour
le produit
Un traitement particulier peut être effectué de manière incorrecte
dans certaines circonstances
❑ Risque produit et risque qualité :

➢ Quand les risques produit sont associés à des caractéristiques de qualité spécifiques d'un produit, le risque est
qualifié de :
Risque Qualité

Risque PROJET 1/2
➢ Traite de situations qui, si elles se produisent, peuvent avoir un effet négatif sur la capacité d'un projet à atteindre
ses objectifs.
Problèmes liés au projet Problèmes organisationnels
➢ Délais de livraison difficiles à tenir ➢ Compétences et formations insuffisantes des ressources

➢ Estimations des coûts erronées et ressources manquantes
➢ Changements non maitrisés impactant les charges ➢ Conflits et problèmes relationnels
➢ Indisponibilité des parties prenantes
Problèmes politiques
➢ Difficultés de communication entre les testeurs et les

autres parties prenantes
➢ Le cycle de vie des défauts est inopérant
➢ Une attitude ou des attentes erronées vis-à-vis du test

Risque PROJET 2/2
Questions techniques Problèmes liés aux fournisseurs
➢ Des exigences mal définies ➢ Un tiers peut ne pas livrer un produit ou un service
➢ Des exigences non satisfaites, compte tenu des nécessaire, ou faire faillite
contraintes existantes ➢ Des problèmes contractuels peuvent causer des
➢ L'environnement de test peut ne pas être prêt à temps difficultés au projet
➢ La conversion des données, la planification de la
migration et leur outillage peuvent être en retard
➢ Niveau de maitrise insuffisant du processus de
développement
➢ Une mauvaise gestion des défauts

5.5.3 Test basé sur les risques et qualité produit
❑ Focus sur le test basé sur les risques :
➢ Les tests sont un moyen de :
• Réduction des risques • D’atténuation des risques
➢ Une approche de test basée sur les risques offre des possibilités de réduire
les niveaux de risques produit.
➢ Implications :
• Réaliser une analyse des risques produits : identification et évaluation de la
probabilité et de l’impact
• Les informations sur les risques guident les activités du processus de test

5.5.3 Test basé sur les risques et qualité produit
❑ Dans une approche basée sur les risques, les résultats de l’analyse des risques participent à :
Déterminer les techniques de test à utiliser
Déterminer les niveaux et les types spécifiques de tests à effectuer, par exemples :
des tests de sécurité, des tests d'accessibilité
Déterminer le volume des tests à réaliser
Prioriser les tests afin de trouver les défauts critiques le plus tôt possible
Déterminer si des activités en complément des tests pourraient être utilisées pour
réduire les risques, par exemple : formation de concepteurs inexpérimentés
❑ L’analyse de risque est une approche méthodique pour :
Analyser et réévaluer régulièrement ce qui peut mal se Mettre en œuvre des mesures pour atténuer ces risques ➔
passer ➔ des risques une stratégie de test basée sur les risques
Déterminer quels risques sont importants à gérer, cf. la Établir des plans de contingence pour faire face aux
priorisation risques ➔ réaliser le processus de test

Révisions
❑ Quels sont les caractéristiques d’un niveau de risque ?
❑ Nommer les 2 natures de risques que peut rencontrer le test ?
❑ Citer des risques produit ?
❑ Citer des risques projet ?
❑ À quoi pourraient servir l’identification et le suivi de risques produit ?

5.6
Gestion des défauts

5.6 Gestion des défauts
❑ La gestion des défauts est structurée autour de :
Un workflow
• Il formalise l’enchainement des activités de gestion d’un défaut; de son analyse à sa cloture
• Il est caractérisé par un état et un attribut d’affectation du défaut à un rôle
• Il doit être approuvé par les parties prenantes du test, principalement le développement
Des règles de classification

• Elles sont formalisées par des attributs pour permettre le regroupement des défauts
Des rapports
• Le rapport doit contenir les éléments descriptifs d’un défaut pour le comprendre en vue de sa correction
• Il contient les attributs de classification du défaut pour permettre leur regroupement – sévérité, priorité, état

❑ Détection des défauts :
➢ Tout au long du cycle de vie du projet :
• Le codage
• L'analyse statique
• Les revues
• Les tests dynamiques
❑ Les faux positifs :

➢ Signalés comme des défauts, mais ne sont en
réalité pas des défauts.
Faux POSITIF
Un résultat de test dans

lequel un défaut est
rapporté alors qu’en réalité
ce défaut n’existe pas
dans l’objet de test.
.

❑ Objectifs d’un rapport de défaut :
Fournir aux développeurs et aux autres intervenants de l'information
sur tout événement indésirable survenu
• Pour permettre de déterminer les effets spécifiques, d'isoler le problème avec un test de reproduction à
minima
• Informer sur tous les éléments qui facilite la correction des défauts potentiels ou la résolution du problème
d'une autre manière
Fournir au test manager un moyen de suivre la qualité du produit

d’activités testé et l'impact sur les tests
• Si un grand nombre de défauts est signalé, les testeurs auront passé beaucoup de temps à les signaler au
lieu d'effectuer des tests, et il y aura plus de tests de confirmation nécessaires
Fournir des idées pour le développement et l'amélioration du

processus de test
• Un des objectifs du test est de prévenir des défauts, le rapport de défaut permet de stocker de l’information
exploitable pour l’amélioration des processus
➢ Les défauts détectés au cours des tests statiques, en particulier les revues, seront normalement documentés d'une
manière différente, par exemple, dans les notes de réunion de revue.

❑ Contenu d’un rapport de défaut :
➢ Un identifiant ➢ La portée ou le degré d'impact – sévérité – du défaut pour les
parties prenantes concernées
➢ Un titre et un bref résumé du défaut signalé
➢ Urgence/priorité de la correction
➢ La date du rapport de défaut, l'organisation émettrice et
l'auteur ➢ L'état du rapport de défaut (p. ex. ouvert, différé, en double,
en attente de correction, en attente de test de confirmation,
➢ L'identification de l'élément de test (élément de configuration réouvert, fermé)
testé) et de l'environnement
➢ Les conclusions, recommandations et approbations
➢ La ou les phases du cycle de développement au cours
desquelles le défaut a été observé ➢ Les enjeux généraux, tels que les autres domaines qui
peuvent être affectés par un changement résultant du défaut
➢ Une description du défaut pour permettre la reproduction et la
résolution, y compris des logs, des captures de base de ➢ L'historique des modifications, notamment la séquence des
données, des captures d'écran ou des enregistrements (si mesures prises par les membres de l'équipe de projet quant
trouvés pendant l'exécution des tests) au défaut pour isoler, réparer et confirmer qu'il est corrigé
➢ Les résultats attendus et obtenus ➢ Les références, y compris le cas de test qui a révélé le
problème
❑ Le contenu d’un rapport de défauts est décrit dans la norme IEEE 29119-3 « Software and systems engineering -
Software testing - Part 3: Test documentation »
❑ Exemples de workflows : Responsable Développeur CP Fournisseur (MOED) Testeur
03 - EVOLUTION
02 - DEMANDE D’INFO.
01 - NOUVELLE
04 - OUVERTE
06 - DEMANDE DE
05 - TRANSMISE 14 - FERMEE ABANDONNEE
COMPL. ou AB.
07 - EN SUSPENS
08 - PRISE EN COMPTE 16 - RE-OUVERTE
09 - EN COURS Action réalisée par le Responsable
Action réalisée par le CP

Fournisseur (MOED)
10 - CORRIGEE
Action réalisée par le Développeur
Action réalisée par le Testeur
11 - LIVREE
12 - A RECETTER
13 - VALIDEE
15 - FERMEE

Révisions
❑ Que doit mettre en place le test manager pour la gestion des défauts ?
❑ Quel attribut caractérise un cycle de vie des défauts ?
❑ Quel est la dernière valeur de l’état d’un défaut ?
❑ Quel attribut d’un rapport de défaut caractérise l’impact du défaut identifié ?
❑ À quel moment du cycle de développement les défauts sont-ils identifiés ?
❑ Citer des éléments requis pour le contenu d’un rapport de défaut.

C
Q M

QCM de fin de chapitre
❑ Q1 : Lequel des énoncés suivants décrit le mieux la façon dont les tâches sont réparties entre
le test manager et le testeur ?
a. Le Test Manager planifie les activités de test et choisit les normes à suivre, pendant que le testeur
choisit les outils et les moyens de contrôle à utiliser.
b. Le Test Manager planifie, organise et contrôle les activités de test, pendant que le testeur spécifie et
exécute les tests.
c. Le Test Manager planifie, surveille et contrôle les activités de test, tandis que le testeur conçoit des
tests et décide de l’utilisation de frameworks d'automatisation.
d. Le Test Manager planifie et organise les tests, et spécifie les cas de test, tandis que le testeur priorise
et exécute les tests.
❑ Q2 : Lequel des éléments suivants n'est pas inclus dans un rapport de synthèse de test ?
a. Définition des critères de réussite ou d'échec et les objectifs des tests.
b. Écarts par rapport à l'approche de test.
c. Mesure des progrès réels par rapport aux critères de sortie.
d. Évaluation de la qualité de l'élément testé.

❑ Q3 : Le rapport d'avancement de test IEEE 29119 contient les éléments suivants exceptés ?
a. Les tests réalisés
b. Les risques résiduels
c. Les statuts des tests
d. Les spécifications de test
❑ Q4 : Quel est l'objectif des critères de sortie ?

a. Définir quand un test particulier a terminé son exécution
b. S'assurer que la conception des tests est terminée
c. Définir les critères utilisés dans la génération des données d'entrée
d. Déterminer quand arrêter les tests

❑ Q5 : Quelle(s) proposition(s) indique(nt) l’importance de corriger un défaut et quand il doit être
corrigé ?
a. La sévérité
b. La priorité
c. Les propositions a et b
d. Aucune des propositions
❑ Q6 : Quels sont les deux éléments principaux à prendre en compte lors de l’analyse de risques ?
a. La probabilité que l’événement se produise
b. La perte potentielle ou l’impact liés à l’événement
c. Les deux réponses a et b
d. Ni a, ni b

❑ Q7 : Quel outil enregistre les informations sur les versions du logiciel et du testware ?
a. Outil de gestion des tests
b. Outil de gestion des exigences
c. Outil de gestion de configuration
d. Outil d’analyse statique
❑ Q8 : Quel cycle de vie d'un défaut est correct ?

a. Ouvert, Assigné, Corrigé, Fermé
b. Ouvert, Corrigé, assigné, Fermé
c. Assigné, Ouvert, Fermé, Corrigé
d. Assigné, Ouvert, Corrigé, Fermé

Aldemia Campus Touch
Fin du chapitre 5

ALD - ISTQB Fondation - Chapitre 5 - V1.2

Transféré par

Droits d'auteur :

Formats disponibles

ALD - ISTQB Fondation - Chapitre 5 - V1.2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ALD - ISTQB Fondation - Chapitre 5 - V1.2

Transféré par

Droits d'auteur :

Formats disponibles

Aldemia Campus Touch

• Des pictos caractéristiques illustrent certains aspects du contenu :

➢ Point d’attention en vue de la préparation aux QCM

➢ Point d’attention, niveau de complexité élevé

➢ Expression issue du syllabus

➢ Définition extraite du glossaire ISTQB

➢ Information complémentaire, digression

3 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

5.1 Organisation des tests 5.3 Pilotage et contrôle des tests

4 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

5.1 FL-5.1.1 Expliquer les bénéfices et inconvénients du test indépendant K2

5.2 FL-5.2.1 Résumer l'objectif et le contenu d'un plan de test K2

5.2 FL-5.2.2 Expliquer les différences entre plusieurs stratégies de test K2

Appliquer les informations de priorité et de dépendances techniques et logiques pour

5.3 FL-5.3.1 Se souvenir des métriques utilisées pour les tests K1

5.5 FL-5.5.1 Définir le niveau de risque à partir de la probabilité d'occurrence et de l'impact K1

6 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

Organisation des tests

7 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

8 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

9 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

Développeur/Testeur Développeurs Testeurs Développeurs Testeurs

Développeurs Testeurs Développeurs Testeurs externes

Équipe projet Organisation métier Équipe projet

Organisation Organisation Équipe de test

11 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

➢ Les testeurs indépendants peuvent être considérés comme un

➢ Les testeurs indépendants peuvent ne pas disposer de

12 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

13 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

14 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

15 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

16 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

Planification et estimation des tests

17 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

❑ Le plan de test est le produit d’activité de l’activité de planification

18 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

19 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

20 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

1. Identification du 3. Périmètres 4. Caractéristiques

5. Caractéristiques 7. Critères d’entrée 8.Critères de suspension

13. Ressources 15. Risques et

21 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

❑ L’approche de test ajuste la stratégie de test selon le contexte du projet

22 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

Stratégie de test Approche de test

Documentation qui exprime les L’implémentation de la stratégie de

23 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

Basée sur les modèles

24 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

L'ensemble des conditions L'ensemble des conditions

Synonyme : définition du prêt Synonyme : définition du terminé

❑ Principes de mises en œuvre :

25 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

26 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

28 | 2018 | ISTQB Fondation – Chapitre 5 / Copyright Aldemia 2018 – reproduction interdite

❑ Principes de mise en œuvre :

Tenir compte des niveaux de priorité des tests

Tenir compte du périmètre de tests de régression identifié