Le chef de projet reçoit un rapport indiquant que 38 défauts ont été corrigés dans la version V1.2. L'équipe doit décider quels tests exécuter. Expliquez la distinction entre tests de confirmation et tests de régression, et précisez lesquels doivent être lancés en priorité dans ce contexte.

Selon FL-2.2.3, un test de confirmation (ou retest) vérifie qu'un défaut spécifiquement corrigé ne se reproduit plus. Il cible exactement les cas de test qui avaient échoué à cause du défaut initial. Un test de régression, quant à lui, vérifie que les corrections ou évolutions n'ont pas introduit de nouveaux défauts dans des parties du système qui fonctionnaient correctement auparavant. Dans ce contexte, il faut d'abord exécuter les tests de confirmation sur les 38 défauts corrigés pour s'assurer que chaque correction est effective. Ensuite, les tests de régression doivent couvrir les modules connexes au module de transfert inter-comptes (qui avait posé problème lors de la migration précédente) ainsi que l'ensemble des fonctionnalités critiques du périmètre. La priorisation doit tenir compte des risques produit identifiés : les zones à fort impact métier (transferts, soldes) passent en premier.

Le responsable qualité souhaite justifier le budget test de 1 800 k€ auprès de la direction. Le ratio historique constaté sur les trois derniers projets similaires indique que le coût du test représente en moyenne 25 % du budget de développement. Quel est le budget de développement estimé pour ce projet, et quelle technique d'estimation a été appliquée ?

Selon FL-5.1.4, la technique d'estimation basée sur les ratios consiste à utiliser un rapport historique entre deux métriques connues pour en déduire une valeur inconnue. Ici, le coût du test représente 25 % du budget de développement. Si le budget test est de 1 800 k€, on obtient : budget développement = 1 800 k€ / 0,25 = 7 200 k€. Cette technique est applicable lorsque l'organisation dispose de données historiques fiables issues de projets comparables. Elle est simple à mettre en œuvre mais suppose une stabilité du contexte entre les projets de référence et le projet cible. Dans un projet bancaire structuré en V, cette approche est cohérente car les périmètres sont bien délimités et les ratios tendent à être stables.

Pour garantir que chaque cas de test peut être relié à une exigence fonctionnelle et qu'aucune exigence n'est laissée sans couverture, l'équipe met en place une matrice de traçabilité. Quelle est la valeur principale de cette démarche dans ce projet, et quel lien existe-t-il avec la gestion de configuration ?

Selon FL-1.4.4, la traçabilité permet d'assurer qu'il existe un lien entre chaque exigence et les cas de test qui la couvrent, garantissant ainsi une couverture complète du périmètre. Dans le contexte de cette migration, elle permet également d'identifier rapidement les exigences non encore testées, de prioriser les efforts en fonction des risques et de démontrer aux parties prenantes que toutes les fonctionnalités critiques ont été validées. En complément, la gestion de configuration (FL-5.4.1) est essentielle car plusieurs versions du système (V1.1, V1.2, etc.) sont testées en parallèle. Elle garantit que chaque cas de test est exécuté contre la bonne version du logiciel, que les résultats sont associés à la bonne baseline et que la traçabilité reste cohérente tout au long du projet. Sans gestion de configuration rigoureuse, une matrice de traçabilité perd sa fiabilité car on ne sait plus quelle version du composant a réellement été testée.

Durant le sprint 4, la rétrospective révèle que les testeurs reçoivent les user stories seulement la veille de la démo, ce qui les empêche de préparer correctement leurs cas de test d'acceptation. Quelle action concrète devrait être décidée en rétrospective, et quel principe de bonne pratique de test cela illustre-t-il ?

Selon FL-2.1.6, l'objectif d'une rétrospective n'est pas seulement d'identifier les problèmes mais de définir des actions d'amélioration concrètes et mesurables. La bonne action consiste ici à impliquer les testeurs dès le début du sprint dans l'affinement des user stories (sprint planning et backlog refinement), afin qu'ils puissent analyser les critères d'acceptation et préparer les cas de test en parallèle du développement. Cela illustre la bonne pratique FL-2.1.2 : les activités de test doivent commencer le plus tôt possible dans le cycle de vie, quel que soit le modèle utilisé. En Agile, cela se traduit par le principe de 'shift-left' : les testeurs participent à la définition des critères d'acceptation avant que le développement ne commence, réduisant ainsi le risque de livrer des fonctionnalités non conformes aux attentes métier.

Le module de calcul de dosage utilise une fonction avec 3 conditions indépendantes. Un développeur affirme que 3 cas de test suffisent pour atteindre 100 % de couverture des instructions, mais le responsable test conteste ce chiffre pour la couverture des branches. Qui a raison et pourquoi ? Quel est le nombre minimum de cas de test pour chaque type de couverture ?

Selon FL-4.3.1, la couverture des instructions (statement coverage) exige qu'au moins un cas de test exécute chaque instruction du code. Pour une fonction avec 3 conditions, il est théoriquement possible d'atteindre 100 % de couverture des instructions avec un seul cas de test bien choisi qui traverse le chemin principal. Le développeur a donc partiellement raison pour la couverture des instructions. En revanche, selon FL-4.3 (couverture des branches), chaque condition génère 2 branches (vrai/faux), soit 2 × 3 = 6 branches distinctes à couvrir. Pour atteindre 100 % de couverture des branches, il faut au minimum autant de cas de test que nécessaire pour parcourir toutes les branches, soit en pratique au moins 2 cas de test (un couvrant les branches 'vrai' et un couvrant les branches 'faux' pour chaque condition). Dans un contexte médical à haut risque, la couverture des branches est obligatoire car elle détecte des défauts que la couverture des instructions ne révèle pas, notamment les comportements incorrects sur les chemins alternatifs.

La direction médicale demande à positionner les différents types de test de l'application dans les quadrants de test Agile. Où doit-on positionner les tests de performance du serveur de synchronisation des données patients, les tests unitaires TDD des calculs de dosage, et les tests d'utilisabilité de l'interface mobile ? Justifiez.

Selon FL-5.1.7, les quadrants de test Agile organisent les tests selon deux axes : orienté technologie vs. orienté métier, et support de l'équipe vs. critique du produit. Les tests unitaires TDD des calculs de dosage se positionnent en Q1 (orienté technologie, support de l'équipe) : ils sont automatisés, liés au code, et aident les développeurs à construire le produit correctement dès le départ. Les tests de performance du serveur de synchronisation se positionnent en Q4 (orienté technologie, critique du produit) : ils évaluent des caractéristiques non fonctionnelles comme la charge, la latence et la robustesse du système en conditions réelles. Ces tests requièrent souvent des outils spécialisés et ne sont pas directement liés au comportement métier. Les tests d'utilisabilité de l'interface mobile se positionnent en Q3 (orienté métier, critique du produit) : ils évaluent l'expérience utilisateur réelle des médecins et nécessitent une intervention humaine ; ils ne peuvent pas être entièrement automatisés et requièrent du feedback des utilisateurs finaux.

Le chef de projet hésite entre une revue informelle et une inspection formelle pour valider les 340 pages de spécifications. Comparez ces deux types de revues et justifiez le choix le plus approprié pour ce contexte industriel critique.

Selon FL-3.2.4, une revue informelle ne suit pas de processus défini : elle peut se faire sous forme de relecture entre pairs, sans rôles attribués ni critères d'entrée/sortie formels. Elle est rapide et peu coûteuse mais moins rigoureuse. Une inspection formelle, en revanche, est le type de revue le plus structuré : elle comprend une planification formelle, des rôles définis (modérateur, auteur, inspecteurs, scribe), des critères d'entrée et de sortie stricts, une réunion d'inspection avec enregistrement des défauts, et un suivi des corrections. Dans un contexte SIL 2, où un défaut non détecté peut provoquer un arrêt de chaîne ou un accident industriel, l'inspection formelle est le choix approprié. Les données chiffrées confirment cette orientation : détecter un défaut lors d'une revue coûte 1 200 € contre 85 000 € en production, soit un ratio de 1 à 70. Selon FL-3.1.2, le test statique permet d'identifier des défauts tôt dans le cycle, avant même l'exécution du code, ce qui justifie pleinement l'investissement dans une approche formelle sur un document aussi critique que les spécifications fonctionnelles.

L'analyste en charge des tests statiques a identifié quatre risques produit : (R1) plantage du système sous charge maximale, (R2) comportement erroné du module de détection de collision non couvert par les tests actuels, (R3) non-conformité de l'interface IHM aux normes ergonomiques, (R4) perte de données de traçabilité lors d'une coupure réseau. Associez chaque risque à la mesure de mitigation la plus adaptée parmi : test de performance, augmentation de la couverture de test, test d'acceptation utilisateur, test de reprise après sinistre.

Selon FL-5.2.4, les mesures prises en réponse à l'analyse des risques produit doivent être directement proportionnelles à la probabilité d'occurrence et à l'impact du risque. R1 (plantage sous charge maximale) → test de performance : cette mesure valide le comportement du système sous conditions extrêmes et permet de définir les seuils de charge acceptables. R2 (comportement erroné du module de détection de collision non couvert) → augmentation de la couverture de test : si des zones du code ne sont pas exercées par les cas de test existants, il faut concevoir de nouveaux cas ciblant spécifiquement ce module, notamment via des techniques boîte blanche (couverture des branches). R3 (non-conformité IHM aux normes ergonomiques) → test d'acceptation utilisateur : ce risque concerne l'expérience et la conformité perçue par les opérateurs humains ; seule une validation avec des utilisateurs réels (opérateurs de chaîne) permet de le mitiger. R4 (perte de données lors d'une coupure réseau) → test de reprise après sinistre : il s'agit de vérifier que le système bascule correctement, que les données sont sauvegardées et que la reprise s'effectue sans perte de traçabilité.

Un testeur junior propose d'utiliser uniquement des techniques de test basées sur l'expérience (tests exploratoires, estimation d'erreurs) pour ce projet, arguant que la documentation est trop dense pour être analysée en détail. Évaluez cette proposition en distinguant les trois familles de techniques de test disponibles.

Selon FL-4.1.1, les techniques de test se répartissent en trois familles : boîte noire (basées sur les spécifications), boîte blanche (basées sur la structure interne du code) et basées sur l'expérience. Les techniques basées sur l'expérience comme les tests exploratoires (FL-4.4.2) ou l'estimation d'erreurs (FL-4.4.1) reposent sur les connaissances et l'intuition du testeur. Elles sont précieuses pour compléter une suite de tests ou explorer des zones inconnues, mais elles ne constituent pas une base suffisante pour un projet SIL 2 : leur couverture n'est pas systématique et ne peut pas être mesurée objectivement. Dans ce contexte industriel critique, les techniques boîte noire comme le partitionnement en classes d'équivalence (FL-4.2.1), l'analyse des valeurs limites (FL-4.2.2) ou les tables de décision (FL-4.2.3) sont indispensables pour dériver des cas de test structurés à partir des spécifications fonctionnelles. Les techniques boîte blanche (couverture des instructions et des branches, FL-4.3) complètent la démarche en garantissant que le code lui-même est entièrement exercé. La proposition du testeur junior est donc à rejeter : les techniques basées sur l'expérience doivent compléter et non remplacer les approches systématiques dans un contexte à haute criticité.

Le directeur technique affirme que le rythme de 8 déploiements par semaine rend les tests manuels inutiles et que l'automatisation complète suffit. Évaluez cette affirmation en vous appuyant sur les avantages et limites de l'automatisation des tests.

Selon FL-6.2.1, l'automatisation des tests présente des avantages majeurs dans un contexte DevOps : elle permet d'exécuter rapidement une grande quantité de tests de régression à chaque déploiement, d'assurer une répétabilité parfaite et de réduire les délais de feedback. Dans un pipeline CI/CD à 8 déploiements par semaine, l'automatisation des tests de régression est effectivement indispensable pour maintenir le rythme sans dégrader la qualité. Cependant, l'automatisation ne peut pas remplacer entièrement les tests manuels. Selon FL-6.2.1, les tests manuels restent nécessaires pour les activités qui requièrent un jugement humain : tests exploratoires, tests d'utilisabilité, validation de nouvelles fonctionnalités non encore couvertes par des tests automatisés, et détection de défauts inattendus sortant des scénarios préprogrammés. De plus, FL-2.1.4 précise que DevOps exige un équilibre entre tests automatisés (pour la vitesse) et tests manuels (pour la profondeur et la créativité). L'affirmation du directeur est donc incorrecte : l'automatisation est un levier essentiel mais doit être combinée avec des tests manuels ciblés, notamment sur les nouvelles fonctionnalités et les zones à risque non encore automatisées.

Un testeur signale le défaut suivant : 'Le bouton Valider ne fonctionne pas sur la page de paiement.' Ce rapport est jugé inexploitable par l'équipe de développement. Identifiez les deux éléments essentiels manquants et expliquez pourquoi ils sont indispensables dans ce contexte e-commerce.

Selon FL-5.5.1, un rapport de défaut exploitable doit contenir plusieurs informations essentielles. Dans ce rapport, deux éléments critiques manquent. Premièrement, le résultat attendu : sans cette information, le développeur ne sait pas quel comportement le système devrait adopter lorsque le bouton est cliqué (ex. : confirmation de la commande et redirection vers la page de récapitulatif). C'est l'élément clé pour comprendre l'écart entre le comportement observé et le comportement spécifié. Deuxièmement, la sévérité du défaut : dans un contexte e-commerce traitant 15 000 commandes par jour, un bouton Valider non fonctionnel sur la page de paiement est un défaut bloquant (critique) qui empêche la finalisation de toute commande et génère un impact financier direct. Sans indication de sévérité, ce défaut risque d'être traité avec la même priorité qu'un défaut cosmétique mineur, ce qui explique le délai moyen de 4,5 jours constaté sur les défauts mal documentés. Des éléments complémentaires utiles incluent également la version du logiciel concernée, les étapes de reproduction, l'environnement de test et le résultat observé précis, pour permettre une reproduction et une correction rapides.

L'équipe souhaite communiquer l'état d'avancement des tests aux parties prenantes métier (responsable commercial, directeur marketing) à la fin de chaque sprint. Quel format et quel contenu sont les plus adaptés, et quelle métrique de test clé devrait figurer dans ce rapport ?

Selon FL-5.3.2, l'objectif d'un rapport de progression des tests est d'informer les parties prenantes de manière objective sur l'état de la qualité du produit, les risques résiduels et les décisions à prendre. Les parties prenantes métier (responsable commercial, directeur marketing) ne sont pas des profils techniques : le rapport doit donc éviter les métriques purement techniques (logs, couverture de branches) et privilégier une communication visuelle et orientée métier. Le format le plus adapté est un tableau de bord visuel (dashboard) avec des indicateurs clés présentés sous forme de graphiques : taux d'avancement des tests, nombre de défauts ouverts/résolus par sévérité, et tendance de la qualité sprint après sprint. Selon FL-5.3.1, la métrique clé à inclure est la densité de défauts (nombre de défauts détectés par fonctionnalité ou par module), qui permet aux parties prenantes d'identifier les zones à risque et de prendre des décisions éclairées sur la mise en production. Dans un contexte DevOps à 8 déploiements par semaine, il est aussi pertinent d'indiquer le taux de régressions détectées avant et après déploiement, pour montrer l'efficacité du pipeline de test automatisé par rapport au taux historique de 8 % de régressions en production.

Le module de saisie du montant d'un billet adulte 2e classe accepte des valeurs entre 15 € et 180 €. En appliquant l'analyse des valeurs limites à deux valeurs, quelles valeurs de test faut-il inclure, et quel niveau de couverture cette approche garantit-elle par rapport à une simple partition d'équivalence ?

Selon FL-4.2.2, l'analyse des valeurs limites (BVA) à deux valeurs consiste à tester la dernière valeur avant la limite et la première valeur à la limite (ou inversement selon le sens de la frontière). Pour la plage [15 €, 180 €], les valeurs à tester sont : 14 € (juste en dessous du minimum, valeur invalide), 15 € (minimum, valeur valide), 180 € (maximum, valide) et 181 € (juste au-dessus du maximum, invalide). Cela donne 4 valeurs de test couvrant les deux limites de la plage. Par comparaison, le simple partitionnement en classes d'équivalence (FL-4.2.1) produirait trois partitions : une valide (ex. 100 €) et deux invalides (ex. 5 € et 200 €), soit 3 valeurs. L'analyse des valeurs limites est plus efficace car les défauts se concentrent statistiquement aux frontières des partitions : une implémentation incorrecte du signe de comparaison (< au lieu de <=) serait détectée par BVA mais pas par EP seule. Dans ce contexte ferroviaire, où des erreurs de tarification aux limites pourraient générer des remboursements ou des litiges clients, la BVA apporte une couverture qualitativement supérieure pour un faible surcoût en nombre de cas de test.

L'équipe dispose de 5 testeurs et de 4 semaines pour réaliser la campagne. Le responsable test doit prioriser l'exécution des cas de test. Quels critères de priorisation doit-il appliquer, et quel est le rôle des critères d'entrée et de sortie dans la gestion de cette campagne ?

Selon FL-5.1.5, la priorisation des cas de test repose sur plusieurs critères : la priorité métier (fonctionnalités les plus utilisées ou les plus critiques pour le chiffre d'affaires), les dépendances logiques entre cas de test (un cas de test testant la réservation doit être exécuté avant celui testant le paiement), et le niveau de risque associé à chaque fonctionnalité. Dans ce contexte, le module de calcul tarifaire et le module de paiement doivent être testés en premier car ils représentent le cœur du service et les zones à plus fort impact en cas de défaut. Selon FL-5.1.3, les critères d'entrée définissent les conditions préalables au démarrage de la campagne : environnement de test disponible, données de test préparées, cas de test rédigés et revus, versions logicielles identifiées et stables. Les critères de sortie définissent les conditions permettant de déclarer la campagne terminée : taux d'exécution des cas de test planifiés atteint (ex. 100 % des cas haute priorité exécutés), taux de défauts bloquants résiduels inférieur à un seuil défini (ex. 0 défaut bloquant ouvert), et couverture des exigences validée via la matrice de traçabilité. Ces critères permettent de prendre une décision objective de livraison à la fin des 4 semaines, indépendamment des pressions calendaires.

Un testeur expérimenté propose d'utiliser une checklist pour tester l'interface utilisateur du processus de réservation, tandis qu'un autre préfère des tests exploratoires. Comparez ces deux approches basées sur l'expérience et précisez dans quels cas chacune est la plus adaptée pour ce projet.

Selon FL-4.4.3, les tests basés sur des checklists utilisent une liste prédéfinie d'éléments à vérifier, dérivée de l'expérience passée, des normes ou des risques connus. Leur objectif principal est de structurer le travail de test et d'éviter d'oublier des éléments importants, sans garantir une couverture exhaustive. Ils sont particulièrement adaptés lorsque les fonctionnalités à tester sont bien connues et que l'on souhaite s'assurer de la vérification systématique de critères récurrents (ex. : accessibilité des formulaires, messages d'erreur, comportement sur mobile). Selon FL-4.4.2, les tests exploratoires sont une approche simultanée de conception, d'exécution et d'apprentissage, guidée par l'intuition et l'expérience du testeur. Ils sont particulièrement efficaces lorsque la documentation est limitée, que le temps est contraint, ou que l'on cherche à découvrir des défauts inattendus dans des zones peu explorées. Dans ce projet de billetterie, les checklists sont plus adaptées pour la vérification systématique de l'interface utilisateur (formulaires, messages de confirmation, gestion des erreurs de saisie) car ces éléments sont bien spécifiés. Les tests exploratoires sont plus appropriés pour explorer les combinaisons de tarifs et de profils utilisateurs peu couvertes par les cas de test formels, notamment sur les règles métier complexes des 12 règles tarifaires, où l'intuition d'un testeur expérimenté peut révéler des incohérences non anticipées.