Hoja de repaso: Introduction aux activités de test logiciel

📋 Plan du Cours

1. Objectifs habituels du test
2. Test et débogage : activités distinctes
3. Analyse et conception des tests
4. Implémentation, exécution et clôture des tests
5. Tester selon le cycle de vie logiciel
6. Approches pilotées par les tests et shift-left
7. Niveaux de test et types de tests
8. Tests de confirmation et de régression
9. Techniques de test boîte noire et boîte blanche
10. Tables de décision pour dériver des tests
11. Plan de test : contenu et critères
12. Gestion des risques et priorisation des tests

📖 1. Objectifs habituels du test

🔑 Notions clés & Définitions

• Détection de défauts : Objectif de test visant à repérer des défauts dans le logiciel avant la mise en production.
• Réduction des risques : Objectif de test consistant à diminuer la probabilité et l’impact des problèmes liés au produit.
• Gain de confiance : Objectif de test visant à fournir une base rationnelle pour estimer que le produit est suffisamment fiable pour son usage.
• Vérification des exigences : Objectif de test consistant à contrôler que le produit respecte les exigences et critères attendus.

📝 Points essentiels

• Le test vise principalement à trouver des défauts, pas à prouver qu’un logiciel est totalement exempt de défauts.
• Le test sert à évaluer le niveau de risque résiduel en fonction des défauts observés et de leur gravité.
• Le test apporte une confiance fondée sur des résultats mesurables plutôt que sur des impressions.
• Le test vérifie la conformité aux exigences en couvrant les comportements attendus.
• Le test peut aussi soutenir la prise de décision (ex. poursuivre, corriger, ou libérer) à partir d’indicateurs de test.
• Les objectifs du test s’expriment différemment selon le contexte (produit, utilisateurs, contraintes), tout en gardant ces finalités générales.

💡 Astuce mémo

Défaut → Risque → Confiance → Exigences (DRCE).

📖 2. Test et débogage : activités distinctes

🔑 Notions clés & Définitions

• Test : Activité de vérification qui évalue un produit logiciel par rapport à des critères définis afin de révéler des écarts.
• Débogage : Activité de diagnostic et de correction qui cherche la cause d’un défaut observé et vise à le supprimer.
• Défaut : Problème dans le logiciel qui peut provoquer un comportement incorrect et qui doit être identifié, documenté et traité.
• Erreur : Action ou décision incorrecte à l’origine d’un comportement fautif, pouvant conduire à un défaut.
• Panne : Manifestation observable d’un comportement incorrect du système, souvent liée à un défaut.

📝 Points essentiels

• Le test vise à détecter des écarts par rapport aux attentes, tandis que le débogage vise à trouver la cause et corriger le problème.
• Un même incident peut être traité comme un défaut (cause dans le logiciel) et comme une panne (symptôme observable) selon le point de vue.
• Le test fournit des informations (résultats, traces, conditions) qui servent d’entrée au débogage, sans se confondre avec la correction.
• La documentation du défaut doit permettre de reproduire le problème et de faciliter l’analyse, pas seulement de constater un échec.
• Le débogage est une activité orientée cause, alors que le test est orienté observation et évaluation par rapport à des critères.
• Après correction, un nouveau test est nécessaire pour vérifier que le défaut est résolu et que le comportement attendu est rétabli.

💡 Astuce mémo

Test = Trouver (écart) ; Débogage = Comprendre + Corriger (cause).

📖 3. Analyse et conception des tests

🔑 Notions clés & Définitions

• Conception des tests : La conception des tests consiste à transformer la base de test en conditions de test et en cas de test priorisés pour vérifier les objectifs visés.
• Analyse de test : L’analyse de test consiste à examiner la base de test pour repérer ce qui est testable et définir des conditions de test liées aux risques.
• Base de test : La base de test regroupe les artefacts servant de référence pour dériver les conditions et cas de test.
• Condition de test : Une condition de test est un élément testable identifié à partir de la base de test, associé à des objectifs et souvent à un niveau de risque.
• Cas de test : Un cas de test décrit un ensemble d’actions et de vérifications permettant de tester une condition de test et d’obtenir un résultat observable.

📝 Points essentiels

• La conception des tests dérive des cas de test à partir de la base de test en utilisant des techniques de test adaptées (boîte noire, boîte blanche et basées sur l’expérience).
• L’analyse de test identifie les caractéristiques testables de la base de test et définit des conditions de test à prioriser.
• Les conditions de test sont associées à des risques et à des niveaux de risque pour guider la priorisation des efforts.
• Le processus de test est itératif ou parallèle : analyse et conception peuvent évoluer à mesure que le contexte et les risques sont précisés.
• Le test doit être aligné sur le cycle de vie de développement logiciel, donc la conception dépend du contexte (produit, niveau de test, SDLC, contraintes métier).
• La traçabilité entre la base de test et le testware (dont les cas de test) soutient la compréhension et le pilotage des activités de test.

💡 Astuce mémo

Base de test → Analyse → Conditions (risque) → Cas de test (preuve).

📖 4. Implémentation, exécution et clôture des tests

🔑 Notions clés & Définitions

• Pilotage des tests : Le pilotage des tests consiste à suivre en continu les activités de test et à comparer l’avancement réel au plan.
• Contrôle des tests : Le contrôle des tests regroupe les actions prises pour ramener le test vers l’atteinte des objectifs.
• Testware : Le testware désigne l’ensemble des produits créés pour préparer, exécuter et analyser les tests.
• Environnement de test : L’environnement de test est le cadre technique utilisé pour exécuter les tests dans des conditions maîtrisées.
• Clôture des tests : La clôture des tests regroupe les activités réalisées aux jalons pour finaliser les défauts, archiver le testware et produire le rapport d’achèvement.

📝 Points essentiels

• Le pilotage compare les progrès réels aux éléments prévus et vérifie que les activités de test se déroulent comme attendu.
• Le contrôle vise à déclencher les mesures nécessaires pour atteindre les objectifs de test lorsque des écarts apparaissent.
• L’implémentation produit ou acquiert le testware requis, comme les données de test, et organise les cas en procédures et suites.
• L’exécution suit le calendrier d’exécution, peut être manuelle ou automatisée, et peut prendre des formes comme le test en continu ou en binôme.
• Les résultats réels sont comparés aux résultats attendus, puis enregistrés et utilisés pour analyser les anomalies et leurs causes probables.
• La clôture intervient aux jalons (livraison, fin d’itération, fin de niveau) pour traiter les défauts non résolus, changements et éléments du Product Backlog, puis archiver le testware utile et arrêter l’environnement d’

💡 Astuce mémo

Pilotage = Suivre vs Plan ; Contrôle = Corriger vers Objectifs ; Implémentation = Préparer le testware ; Exécution = Comparer Attendu/Réel ; Clôture = Archiver + Rapport.

📖 5. Tester selon le cycle de vie logiciel

🔑 Notions clés & Définitions

• Modèle de cycle de vie logiciel : Un modèle de cycle de vie logiciel est une représentation abstraite qui relie phases de développement et activités, à la fois dans l’ordre et dans la logique.
• Développement séquentiel : Un développement séquentiel est un modèle où les activités avancent par étapes, ce qui limite souvent l’exécution de tests dynamiques au début.
• Développement itératif : Un développement itératif est un modèle où chaque itération produit un prototype ou un incrément, permettant des tests statiques et dynamiques à plusieurs niveaux.
• Développement incrémental : Un développement incrémental est un modèle où le produit progresse par ajouts successifs, rendant le feedback et la régression plus fréquents.
• Shift left : Le shift left est une approche qui avance l’exécution des tests plus tôt dans le cycle de vie, sans supprimer les tests des phases ultérieures.

📝 Points essentiels

• Le choix du cycle de vie influence le périmètre et le calendrier des tests, le niveau de documentation, les techniques, le degré d’automatisation et le rôle des testeurs.
• En développement séquentiel, les testeurs participent souvent tôt à la revue des exigences, à l’analyse de test et à la conception, car le code exécutable arrive plus tard.
• En itératif/incrémental, chaque itération fournissant un incrément permet d’effectuer des tests statiques et dynamiques à tous les niveaux de test.
• Des livraisons fréquentes exigent un feedback rapide et des tests de régression plus poussés.
• Les projets agiles acceptent des changements tardifs, privilégient une documentation légère et une automatisation forte pour faciliter la régression.
• Bonnes pratiques indépendantes du modèle : chaque activité de développement a une activité de test associée pour assurer un contrôle qualité continu du produit.

💡 Astuce mémo

Cycle de vie = calendrier + doc + techniques + automatisation + rôle : change le modèle, change le test.

📖 6. Approches pilotées par les tests et shift-left

🔑 Notions clés & Définitions

• Test boîte noire : Le test boîte noire est une technique fondée sur les spécifications, où les cas de test sont dérivés de la documentation externe pour vérifier le comportement attendu.
• Test boîte blanche : Le test boîte blanche est une technique fondée sur la structure interne, où les cas de test sont dérivés de l’implémentation ou des éléments internes pour couvrir la structure jusqu’à un niveau acceptable.
• Test de confirmation : Le test de confirmation est un test qui vérifie qu’un défaut corrigé a bien été éliminé et que la défaillance ne se reproduit plus.
• Test de régression : Le test de régression est un test qui vérifie qu’une modification n’a introduit aucune conséquence négative, y compris dans des parties non modifiées ou l’environnement.
• Test statique : Le test statique est une démarche qui évalue des produits d’activités sans exécuter le logiciel, via des revues manuelles ou des outils d’analyse statique.

📝 Points essentiels

• Le test non fonctionnel peut nécessiter un environnement de test très spécifique, comme un laboratoire d’utilisabilité pour les tests d’utilisabilité.
• Le test boîte noire vise la conformité du comportement du système aux spécifications, tandis que le test boîte blanche vise la couverture de la structure interne jusqu’au niveau acceptable.
• Les techniques de test (boîte noire/boîte blanche et autres types mentionnés) peuvent être appliquées à tous les niveaux de test, avec un accent différent selon le niveau.
• Le test de confirmation peut être limité, faute de temps ou d’argent, à rejouer les étapes qui reproduisent la défaillance et vérifier qu’elle ne réapparaît pas.
• Le test de régression doit rechercher des effets négatifs potentiels sur le composant modifié, d’autres composants du même système et parfois d’autres systèmes connectés.
• Avant d’exécuter une régression, une analyse d’impact aide à déterminer quelles parties peuvent être affectées et donc à optimiser le périmètre des tests.

💡 Astuce mémo

Boîte noire = Spécifications (comportement attendu) ; Boîte blanche = Structure (couverture interne) ; Confirmation = Défaut corrigé ; Régression = Pas d’effets collatéraux.

📖 7. Niveaux de test et types de tests

🔑 Notions clés & Définitions

• Revue informelle : Une revue informelle est une revue sans processus défini et sans livrable formel documenté, centrée sur la détection d’anomalies.
• Relecture technique : Une relecture technique est une revue menée par l’auteur, visant notamment la qualité, la confiance, la formation, le consensus et la détection d’anomalies.
• Revue technique : Une revue technique est une revue animée par un modérateur, réalisée par des réviseurs qualifiés pour décider sur des sujets techniques et détecter des anomalies.
• Inspection : Une inspection est une revue très formelle qui suit le processus générique complet et vise principalement à trouver un maximum d’anomalies.
• Couverture Each Choice : La couverture Each Choice est un critère de couverture simple pour des ensembles multiples de partitions, sans tenir compte des combinaisons entre partitions.

📝 Points essentiels

• Le niveau de formalité d’une revue dépend notamment du cycle de vie, de la maturité du processus, de la criticité/complexité, des contraintes légales et des besoins d’audit.
• Un même produit d’activités peut être revu plusieurs fois avec des niveaux de formalité différents, par exemple informel puis plus formel.
• Revue informelle : l’objectif principal est de détecter des anomalies, sans exigence de résultat formel documenté.
• Relecture technique : les réviseurs peuvent faire une revue individuelle avant, mais ce n’est pas obligatoire.
• Revue technique : elle vise le consensus et des décisions sur le problème technique, tout en détectant des anomalies et en renforçant la confiance.
• Inspection : elle collecte des métriques pour améliorer le cycle de vie et le processus d’inspection, et l’auteur ne peut pas être réviseur ni scribe.

💡 Astuce mémo

Informel→anomalies; Relecture→auteur; Revue technique→modérateur+consensus; Inspection→process complet+max anomalies.

📖 8. Tests de confirmation et de régression

🔑 Notions clés & Définitions

• Couverture par tables de décisions : La couverture par tables de décisions mesure, en pourcentage, combien de colonnes de combinaisons réalisables sont exercées par les cas de test.
• Table d’états : Une table d’états est un modèle équivalent à un diagramme de transition d’états qui liste états et événements, et indique les transitions valides et non valides.
• Couverture 0-switch : La couverture 0-switch est une mesure de couverture des transitions valides uniques, exprimée comme la proportion de transitions valides exercées.
• Couverture des instructions : La couverture des instructions mesure, en pourcentage, la part des instructions exécutables du code effectivement exécutées par les cas de test.
• Couverture des branches : La couverture des branches mesure, en pourcentage, la part des branches du graphe de flux de contrôle exercées par les cas de test.

📝 Points essentiels

• Les tables de décisions visent une couverture de 100 % en exerçant toutes les colonnes correspondant aux combinaisons de conditions réalisables.
• La couverture par tables de décisions se calcule comme (colonnes exercées / colonnes réalisables) × 100, et aide à repérer lacunes ou contradictions d’exigences.
• Le nombre de règles dans une table de décision peut croître de façon exponentielle avec le nombre de conditions, d’où l’usage possible d’une table réduite ou d’une approche par risques.
• Dans un diagramme de transition d’états, une transition est déclenchée par un événement, éventuellement qualifié par une condition de garde, et peut produire une action.
• La syntaxe courante d’une transition est événement [condition de garde] / action, et les garde ou action peuvent être omises si non pertinentes pour le testeur.
• Dans une table d’états, les cellules vides représentent explicitement les transitions non valides, contrairement au diagramme qui ne les montre pas de façon aussi directe.

📖 9. Techniques de test boîte noire et boîte blanche

🔑 Notions clés & Définitions

• Critères d’acceptation : Les critères d’acceptation sont des conditions décrivant quand une User Story est considérée comme satisfaisante et servent de base aux tests d’acceptation.
• Given When Then : Given/When/Then est un format de spécification en BDD qui structure les tests d’acceptation en préconditions, action et résultat attendu.
• ATDD : L’ATDD est une approche où les cas de test d’acceptation sont conçus avant l’implémentation de la User Story.
• Test positif : Un test positif vérifie le comportement attendu dans des conditions normales, sans déclencher de scénarios d’erreur.
• Test négatif : Un test négatif vérifie le comportement du logiciel face à des erreurs, exceptions ou conditions non conformes.

📝 Points essentiels

• Les critères d’acceptation définissent le périmètre de la User Story, créent un consensus et décrivent des scénarios positifs et négatifs.
• Les critères d’acceptation servent de base aux tests d’acceptation utilisateurs et aident à planifier et estimer plus précisément.
• Deux formats courants existent : orienté-scénario (Given/When/Then) et orienté-règles (liste de vérification ou tableau entrée-sortie).
• Un format personnalisé est acceptable si les critères restent bien définis et sans ambiguïté.
• En ATDD, les cas de test sont créés avant d’implémenter la User Story et par des profils variés (clients, développeurs, testeurs).
• Les cas de test peuvent être exécutés manuellement ou automatisés, et sont basés sur les critères d’acceptation comme exemples du comportement attendu.

💡 Astuce mémo

ATDD = Tests d’abord, puis code : critères d’acceptation → cas de test → implémentation.

📖 10. Tables de décision pour dériver des tests

🔑 Notions clés & Définitions

• Pyramide des tests : Modèle de test qui organise les tests en couches, du plus bas niveau (unitaires) au plus haut niveau (bout en bout).
• Quadrants de tests : Modèle qui classe les tests selon deux axes : orientation (métier/technologie) et rôle (soutien/critique du produit).
• Test basé sur les risques : Approche où les activités de test sont choisies, priorisées et pilotées à partir de l’analyse et du contrôle des risques.
• Risque : Événement ou situation potentielle dont la survenance produit un effet négatif sur le projet ou le produit.
• Risque projet : Risque lié à la gestion et au contrôle du projet, pouvant affecter calendrier, budget ou périmètre.

📝 Points essentiels

• Plus une couche de tests est élevée, moins les tests sont détaillés et moins ils sont isolés, mais plus ils sont longs à exécuter.
• Les tests de couche inférieure sont petits, isolés et rapides, et nécessitent généralement davantage de tests pour atteindre une couverture raisonnable.
• Les tests de couche supérieure sont complexes, de haut niveau et souvent bout en bout, et un petit nombre suffit généralement pour une couverture raisonnable.
• Le modèle original de pyramide des tests (Cohn 2009) distingue trois couches : tests unitaires, tests de service, tests d’interface utilisateur.
• Un autre modèle populaire regroupe tests unitaires (composants), tests d’intégration et tests bout en bout, et d’autres niveaux peuvent être utilisés.
• Les quadrants de tests (Marick, Crispin) aident le management à vérifier que tous les types et niveaux pertinents sont inclus dans le cycle de vie Agile et à clarifier leur rôle pour les parties prenantes.

💡 Astuce mémo

Pyramide = bas = petit/rapide/isolé, haut = gros/lent/peu nombreux ; Quadrants = (métier vs techno) × (soutien vs critique).

📖 11. Plan de test : contenu et critères

🔑 Notions clés & Définitions

• Base de référence de test : Une base de référence de test est un ensemble approuvé servant de point d’ancrage pour exécuter et comparer les résultats des tests.
• Contrôle des modifications : Le contrôle des modifications est le processus formel qui encadre toute modification d’éléments de configuration après leur approbation pour les tests.
• Traçabilité des éléments de configuration : La traçabilité des éléments de configuration est la capacité à relier exigences, tests, défauts et autres artefacts pour suivre l’évolution du test jusqu’à la résolution.
• Rapport d’incident : Un rapport d’incident est un rapport de défaut structuré, utilisé pour documenter et traiter une anomalie détectée pendant les tests.
• Workflow de gestion des défauts : Un workflow de gestion des défauts est l’enchaînement d’étapes allant de la découverte d’une anomalie à sa clôture, avec classification et décision de traitement.

📝 Points essentiels

• Une fois qu’un élément de configuration est approuvé pour les tests, il devient une base de référence et ne peut être modifié que via un processus formel de contrôle des modifications.
• La gestion de configuration conserve l’historique des modifications quand une nouvelle base de référence est créée, ce qui permet de revenir à une base antérieure pour reproduire des résultats de tests précédents.
• Pour soutenir correctement les tests, tous les éléments de configuration (y compris les éléments de test) doivent être identifiés de façon unique, versionnés, suivis pour les changements et reliés pour assurer la traçabl
• Les éléments de documentation et de logiciel identifiés doivent être référencés sans ambiguïté dans la documentation de test afin d’éviter toute confusion sur ce qui a été testé.
• Le pipeline DevOps automatisé (intégration/livraison/déploiement continus) inclut généralement une gestion de configuration automatisée pour maintenir cohérence et reproductibilité.
• La gestion des défauts vise à traiter les anomalies signalées, qui peuvent être de vrais défauts ou autre chose (ex. faux positif ou demande de modification).

💡 Astuce mémo

Base figée = base de référence; changer = contrôle formel; revenir = reproductibilité des tests.

📖 12. Gestion des risques et priorisation des tests

🔑 Notions clés & Définitions

• Niveau de risque : Le niveau de risque est une mesure qui combine la probabilité d’occurrence et l’impact potentiel d’un risque sur le projet ou le produit.
• Risque projet : Le risque projet concerne des facteurs liés à l’organisation, au planning, aux ressources et à la conduite du développement qui peuvent menacer la livraison.
• Risque produit : Le risque produit regroupe les risques liés aux caractéristiques du logiciel (fonctionnelles ou non) qui peuvent provoquer des défauts ayant un impact utilisateur.
• Atténuation des risques : L’atténuation des risques regroupe les actions choisies pour réduire la probabilité et/ou l’impact des risques produit identifiés.
• Surveillance des risques : La surveillance des risques consiste à suivre l’évolution des risques et des signaux associés afin d’ajuster la stratégie de test.

📝 Points essentiels

• Le niveau de risque se calcule en évaluant séparément la probabilité et l’impact, puis en les combinant pour obtenir une priorité de traitement.
• Les risques projet et les risques produit doivent être distingués car ils n’orientent pas la même partie de la stratégie de test.
• L’analyse des risques produit influence la rigueur et l’étendue des tests, donc la quantité et la profondeur des vérifications.
• Les réponses aux risques produit incluent des mesures d’atténuation et de surveillance, pour garder le contrôle au fil du temps.
• La gestion des risques est structurée en quatre activités : identification, évaluation, atténuation, puis surveillance des risques.
• La priorisation des cas de test sert à concentrer l’effort sur ce qui a le plus de valeur compte tenu du contexte et des risques.

💡 Astuce mémo

Risque = Probabilité × Impact : Projet = organisation, Produit = logiciel ; Identifier → Évaluer → Atténuer → Surveiller.

📅 Repères chronologiques

Date	Événement
12 avril 2023	Date de version majeure générale CTFL v4.0 (historique des modifications)
31 octobre 2018	Version française mise à jour avec la correction d’erreurs de typographie (historique des modifications)
25 février 1999	ISEB Software Testing Foundation Syllabus V2.0 (historique des modifications)

📊 Tableaux de synthèse

Test vs débogage

Activité	But principal	Résultat attendu
Test	Évaluer un produit logiciel par rapport à des critères afin de révéler des écarts	Détection d’anomalies/défauts via résultats de test (attendu vs réel)
Débogage	Trouver la cause d’un défaut observé et la supprimer	Correction de la cause + test de confirmation

Boîte noire vs boîte blanche

Technique	Base	Objectif de couverture
Boîte noire	Spécifications/documentation externe	Vérifier le comportement attendu (conformité aux spécifications)
Boîte blanche	Structure interne/implémentation	Couvrir la structure jusqu’à un niveau acceptable (instructions/branches)

⚠️ Pièges & confusions fréquents

1. Confondre vérification et validation : vérifier = conformité aux exigences spécifiées, valider = conformité aux besoins des utilisateurs et parties prenantes.
2. Croire que trouver des défauts prouve l’absence de défauts : le test montre la présence, pas l’absence, et ne garantit pas la correction de tous les risques.
3. Mélanger défaut/erreur/défaillance : une erreur humaine produit un défaut, qui peut entraîner une défaillance lors de l’exécution.
4. Oublier que test et débogage sont distincts : le test observe et fournit des informations, le débogage diagnostique et corrige.
5. Penser que la régression se limite au composant modifié : elle doit rechercher des conséquences négatives aussi ailleurs et parfois dans l’environnement.
6. Croire que 100% de couverture des instructions implique 100% de couverture des décisions/branches : ce n’est pas garanti.
7. Confondre confirmation et régression : confirmation vérifie que le défaut corrigé ne se reproduit pas, régression vérifie l’absence d’effets négatifs après modification.

✅ Checklist Examen

1. Identifier les objectifs habituels du test et expliquer comment ils varient selon le contexte (produit, niveau de test, risques, SDLC, contraintes).
2. Faire la différence entre tester et déboguer, et décrire le cycle typique de reproduction/diagnostic/correction + test de confirmation.
3. Distinguer cause racine, erreur, défaut et défaillance, et relier les défauts aux artefacts (documentation, code, support).
4. Résumer les activités du processus de test (planification, analyse, conception, implémentation, exécution, clôture) et le rôle de la traçabilité base de test ↔ testware.
5. Expliquer l’impact du cycle de vie sur le test (séquentiel vs itératif/incrémental), et appliquer les bonnes pratiques indépendantes du modèle (activité de test associée, shift left).
6. Distinguer niveaux de test et types de test (fonctionnel/non fonctionnel, boîte noire/boîte blanche, confirmation/régression) et rappeler les déclencheurs des tests de maintenance.
7. Décrire le test statique : ce qu’il examine, sa valeur, et comparer test statique vs dynamique (défauts détectables, chemins rarement exécutés, produits non exécutables).
8. Comparer les types de revues (revue informelle, relecture technique, revue technique, inspection) et rappeler les rôles/responsabilités clés (manager, auteur, modérateur, scribe, réviseur, responsable de revue).
9. Utiliser les techniques boîte noire (partitions d’équivalence, valeurs limites, tables de décisions, transitions d’état) et boîte blanche (instructions, branches) pour dériver des cas de test et comprendre la couverture.
10. Expliquer ATDD et les critères d’acceptation (formats orienté-scenario vs orienté-règles), et distinguer tests positifs vs négatifs dans ce cadre.
11. Décrire la planification des tests (plan de test, critères d’entrée/sortie, estimation, priorisation) et relier pyramide/quadrants aux niveaux et types de tests.
12. Expliquer la gestion des risques (risque, probabilité/impact, risques projet vs produit, identification/évaluation/atténuation/surveillance) et comment elle influence le périmètre, la rigueur et la priorisation.
13. Rappeler pilotage/contrôle/clôture des tests, les métriques et le contenu typique des rapports d’avancement et de clôture.
14. Décrire la gestion de configuration (base de référence, contrôle des modifications, traçabilité) et la gestion des défauts (workflow, contenu d’un rapport d’incident).