Microsoft AZ-400: Stratégie de test et ingénierie de la qualité — Guide d'étude

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La stratégie de test et l’ingénierie de la qualité dans Azure DevOps visent à renforcer la confiance dans le logiciel grâce à un retour d’information rapide et déterministe tout au long du cycle de vie de la livraison, tout en utilisant les capacités natives de la plateforme pour appliquer des portes de qualité et assurer la traçabilité. Les stratégies efficaces combinent une pyramide de tests équilibrée, une validation précoce et continue (TDD/BDD), une automatisation robuste dans les pipelines, une gestion disciplinée des données de test et des techniques avancées telles que les tests de charge, l’ingénierie du chaos, les vérifications d’accessibilité et les déploiements basés sur la couverture de code. Azure Test Plans, Azure Pipelines, Azure Load Testing et Azure Chaos Studio vous fournissent les outils pour mettre en œuvre ces pratiques à grande échelle.

Fondements de la stratégie de test

Une pyramide de tests pragmatique réduit les risques avec des tests rapides et peu coûteux à la base, et un plus petit nombre de tests à haute fidélité au sommet :

Les tests unitaires valident la logique isolée et devraient constituer la majorité de la suite. Visez une exécution rapide et un déterminisme élevé. Pour la plupart des produits, fixez des objectifs de couverture de tests unitaires de l’ordre de 70 à 90 % pour les services critiques, en reconnaissant que la couverture est une métrique indirecte et non une garantie de qualité.
Les tests d’intégration vérifient les contrats entre composants (par ex., base de données, messagerie, services externes) en utilisant des limites réalistes et des dépendances éphémères. Exécutez-les en parallèle lorsque c’est possible, dans des environnements conteneurisés ou en bac à sable, et ciblez 30 à 60 % des chemins de code critiques exercés par des scénarios de niveau intégration.
Les tests de bout en bout (E2E) valident les parcours utilisateur sur l’ensemble de la pile technique. Gardez-les minimaux et concentrés sur les parcours à plus forte valeur (généralement 5 à 15 % de la suite) pour éviter un retour d’information lent et fragile.

Les pratiques de test shift-left (décalage à gauche) réduisent les défauts plus tôt :

Le développement piloté par les tests (TDD) impose des cycles rouge-vert-refactoriser, éclaire la conception et augmente la confiance au niveau unitaire. Rendez le TDD pratique en fournissant aux ingénieurs des exécuteurs de tests locaux et rapides, et en gardant les tests hermétiques et déterministes.
Le développement piloté par le comportement (BDD) capture l’intention dans un vocabulaire partagé à l’aide de Gherkin. Les équipes .NET peuvent utiliser SpecFlow ; les équipes Java et JavaScript utilisent souvent Cucumber. Liez les scénarios BDD aux critères d’acceptation d’Azure Boards et publiez leurs résultats dans Azure Test Plans pour la traçabilité.

La gestion des données de test élimine le non-déterminisme :

Les données synthétiques fournissent des jeux de données déterministes et respectueux de la vie privée pour les tests unitaires et d’intégration. Générez-les avec des bibliothèques faker spécifiques au langage et des valeurs de départ (seed) permettant la reproductibilité.
Le masquage de données permet d’obtenir des jeux de données de test réalistes sans exposer d’informations personnelles ou sensibles. Utilisez des outils de masquage de base de données ou des pipelines de données qui appliquent des transformations irréversibles. Pour Azure SQL Database, exportez des instantanés (snapshots) vers un abonnement de préproduction (staging) et appliquez le masquage avant l’utilisation pour les tests.
La parité des environnements garantit la pertinence des résultats de test. Provisionnez les environnements de test avec l’Infrastructure as Code (ARM/Bicep/Terraform) afin que les composants système, la configuration et la topologie réseau correspondent à la production de manière aussi fidèle que possible. Maintenez les migrations de schéma synchronisées entre les environnements.

La détection et la gestion des tests instables (flaky tests) protègent les boucles de rétroaction :

Les causes incluent les concurrences de synchronisation (timing races), les dépendances externes, le couplage lié à l’ordre des tests et la contention des ressources. Utilisez la tâche Visual Studio Test d’Azure Pipelines avec l’option rerunFailedTests activée pour réduire le bruit transitoire pendant que vous enquêtez.
Mettez en quarantaine les tests non déterministes pour garder les pipelines au vert, en les marquant et en les isolant dans une suite distincte qui s’exécute et génère des rapports mais ne fait pas échouer la construction (build). Suivez la dette de quarantaine avec des éléments de travail Azure Boards.
L’analyse des causes profondes nécessite une instrumentation. Capturez les journaux, les métriques de synchronisation et les détails de l’environnement pendant les exécutions ; reproduisez localement avec la même valeur de départ (seed) et les mêmes dépendances ; supprimez la dépendance aux horloges système, au réseau et au système de fichiers non simulés (unmocked) ; et corrigez le non-déterminisme à la source.

Azure DevOps et les capacités de test d’Azure

Azure Test Plans fournit des fonctionnalités de premier ordre pour les tests manuels et exploratoires, ainsi que la traçabilité :

Les cas de test (test cases) définissent les étapes, les résultats attendus et les paramètres ; les étapes partagées et les cas de test paramétrés réduisent la duplication. Les suites basées sur les exigences (requirement-based suites) alignent les cas sur les Product Backlog Items ou les user stories, tandis que les suites statiques et basées sur des requêtes (query-based suites) regroupent les tests pour l’exécution.
Les exécutions de tests (test runs) assignent des suites et des configurations aux testeurs, enregistrent les résultats et les durées, et capturent les diagnostics. La création de bogues enrichis inclut des captures d’écran, des vidéos, des données d’environnement et des journaux d’actions.
Les tests exploratoires utilisent l’extension de navigateur Test & Feedback pour capturer les chartes, les notes de session et les artefacts lors de l’exploration ad-hoc. Liez les découvertes aux éléments de travail (work items) et analysez la couverture des exigences et des sessions de test.

Les tests automatisés s’intègrent directement dans les pipelines :

Utilisez la tâche Visual Studio Test (VsTest) pour exécuter les tests MSTest, NUnit et xUnit et publier les résultats au format TRX. Pour .NET, l’utilisation de dotnet test avec le logger approprié (trx, junit) est courante.
Pour Java, exécutez JUnit via Maven ou Gradle et publiez le XML JUnit avec la tâche Publish Test Results. Pour JavaScript, configurez les exécuteurs (runners) comme Jest ou Mocha pour émettre du XML JUnit.
La tâche Publish Test Results consolide les résultats et les tendances à travers les exécutions. Standardisez les formats de résultats (TRX ou XML JUnit) pour unifier le reporting et permettre l’analyse des tests instables (flaky tests).
Liez les exécutions de tests automatisés à Azure Test Plans en mappant les cas de test aux méthodes de test automatisées, assurant une traçabilité de bout en bout, de l’exigence au défaut en passant par l’exécution.

La couverture de code (code coverage) est un garde-fou de qualité mesurable :

Collectez la couverture avec Coverlet (pour .NET), JaCoCo (Java), ou Cobertura/lcov (JavaScript). Convertissez-la dans des formats compris par Azure DevOps et publiez-la via la tâche Publish Code Coverage Results pour faire apparaître les tendances et les deltas.
Appliquez des seuils minimaux au moment du build. Pour .NET, utilisez les options de seuil de Coverlet pour faire échouer le build si la couverture de ligne ou de branche tombe en dessous de la politique définie. Alternativement, utilisez l’extension Build Quality Checks pour appliquer des politiques de couverture et basées sur les tendances.
Les déploiements conditionnés par la couverture (coverage-gated deployments) empêchent la progression lorsque la qualité diminue. En YAML, faites échouer l’étape de qualité si la couverture est inférieure à la cible ; pour les releases classiques, utilisez des portes (gates) qui invoquent une Azure Function ou une vérification REST pour valider la couverture mesurée avant la promotion.

Performance, chaos et résilience

Les tests de charge et de performance valident les exigences non fonctionnelles de manière précoce et continue :

Azure Load Testing orchestre des charges basées sur JMeter à grande échelle tout en corrélant la télémétrie backend d’Application Insights. Importez des plans de test JMX, définissez des critères de réussite/échec (par ex., latence p95, taux d’erreur) et faites remonter les résultats dans les pipelines. Utilisez la porte (gate) Azure Monitor ou les vérifications d’environnement pour bloquer la progression lorsque les lignes de base (baselines) ne sont pas respectées.
Apache JMeter reste un choix polyvalent pour les tests de charge au niveau du protocole. Gardez les groupes de threads (thread groups) et les assertions paramétrés pour la CI. Stockez les jeux de données JMX et CSV avec le code, versionnés avec les scénarios.
k6 permet des tests de charge en tant que code (as code) conviviaux pour les développeurs. Exécutez k6 dans Azure Pipelines via un conteneur ou un runtime Node, capturez les résultats et exportez-les en JUnit ou JSON pour publication. Utilisez des expressions de seuil dans les scripts k6 pour faire échouer les exécutions de manière déterministe.
La gestion des lignes de base (baseline) est essentielle. Suivez les tendances de latence, de débit et d’utilisation des ressources par environnement. Établissez des SLO et assurez-vous que les tests s’exécutent avec des volumes de données et des configurations représentatifs.

L’ingénierie du chaos (chaos engineering) vérifie la résilience en conditions de panne :

Azure Chaos Studio injecte des pannes sur les ressources Azure avec un rayon d’impact (blast radius) contrôlé et des garde-fous. Les types d’expériences incluent la pression CPU/mémoire sur les VM, la latence/trou noir réseau (network latency/blackhole), l’arrêt de processus (process kill) et la limitation de service (service throttling).
Exécutez d’abord les expériences en pré-production et instrumentez-les avec Application Insights et Azure Monitor pour capturer les modes de défaillance, les budgets d’erreur (error budgets) et le comportement de récupération automatique.
La validation de la résilience associe le chaos à des sondes de santé (health probes) et des transactions synthétiques pour garantir que les chemins critiques pour l’utilisateur restent disponibles ou se dégradent gracieusement. Ne promouvez que lorsque les hypothèses de résilience sont confirmées et que les alertes se comportent comme prévu.

Accessibilité, conformité et gouvernance

L’accessibilité et la conformité sont des fondamentaux de la qualité :

Se conformer au minimum à la norme WCAG 2.1 AA pour les expériences destinées au public. Traduire les exigences en critères d’acceptation dans Azure Boards et Azure Test Plans avec des cas de test d’accessibilité dédiés.
Automatiser les vérifications avec axe-core intégré dans des frameworks de test d’interface utilisateur tels que Playwright, Cypress ou Selenium. Faire échouer les builds lorsque des violations critiques sont détectées et publier les rapports d’accessibilité en tant qu’artefacts de pipeline.
Compléter l’automatisation par des audits manuels (navigation au clavier, prise en charge des lecteurs d’écran, contraste des couleurs dans des contextes dynamiques) et consigner les résultats dans des sessions exploratoires à l’aide de l’extension Test & Feedback.
La gouvernance de la conformité et de la qualité dans Azure Pipelines utilise des vérifications d’environnement et des portes (gates). Pour la performance et la disponibilité, interroger Azure Monitor ou Azure Load Testing pour obtenir des bases de référence avant le déploiement. Pour le contrôle de la couverture ou de l’accessibilité, invoquer une fonction ou une vérification REST qui analyse les rapports publiés et renvoie un résultat de réussite/échec (pass/fail). Cela impose la qualité non fonctionnelle comme une condition préalable à la mise en production, et non comme une réflexion après coup.

La publication des résultats de test et les analyses bouclent la boucle :

Standardiser les formats de résultats et les rapports de couverture pour alimenter Test Analytics, suivre l’évolution des taux de réussite et faire remonter automatiquement les tests instables (flaky tests).
Utiliser des stratégies de build et des protections de branche pour exiger des tests réussis (verts) et une couverture adéquate avant la fusion. Maintenir un retour d’information rapide ; paralléliser les étapes de test, fragmenter (shard) les grandes suites de tests et mettre en cache les dépendances pour réduire le temps de cycle.

Scénario de problème pratique

Adobe modernise une plateforme de traitement de documents en microservices sur Azure. La direction de l’ingénierie exige une cadence de livraison plus rapide sans régressions, des bases de référence de performance démontrables, une résilience aux pannes de réseau régionales et la conformité WCAG 2.1 AA. Les pipelines actuels souffrent de tests E2E instables (flaky) et de données de test incohérentes.

Établir la pyramide de tests et les pratiques de shift-left

Adopter le TDD pour les bibliothèques et services principaux afin de créer une base large et déterministe de tests unitaires, en utilisant NUnit et xUnit pour les composants .NET et JUnit pour Java. Le BDD avec SpecFlow et Cucumber capture les critères d’acceptation inter-équipes sous forme de spécifications exécutables. Cela garantit un retour d’information rapide et une compréhension partagée.

Automatiser les tests et publier les résultats dans Azure Pipelines

Utiliser VsTest pour .NET et Maven/Gradle pour Java afin d’exécuter les tests unitaires et d’intégration. Publier les résultats avec Publish Test Results et la couverture avec Publish Code Coverage Results pour centraliser les rapports et permettre l’analyse des tests instables (flaky). Les tâches intégrées offrent une intégration étroite avec Azure DevOps et réduisent le besoin d’outillage personnalisé.

Appliquer les seuils de couverture de code et contrôler les déploiements (gate)

Configurer les seuils de Coverlet et JaCoCo pour faire échouer les builds si la couverture tombe en dessous de 80 % de lignes et 60 % de branches pour les services critiques. Ajouter une vérification de mise en production qui appelle une Azure Function pour lire le dernier artefact de couverture et renvoyer un résultat de réussite/échec, empêchant le déploiement lorsque la couverture est inférieure à la stratégie. Cela formalise les portes de qualité (quality gates) sans intervention humaine.

Mettre en œuvre la gestion des données de test pour le déterminisme

Générer des jeux de données synthétiques pour les tests unitaires et d’intégration à l’aide de bibliothèques de type « faker ». Pour les tests système, cloner des copies masquées de bases de données Azure SQL via un pipeline automatisé utilisant Data Factory pour appliquer un masquage irréversible. Provisionner les environnements avec Bicep pour assurer la parité. Cela élimine le risque lié à la confidentialité et l’instabilité (flakiness) liée aux données.

Contenir et éliminer les tests instables (flaky)

Activer rerunFailedTests dans VsTest pour atténuer les échecs transitoires et marquer les spécifications instables avec un marqueur de quarantaine qui les exclut de la suite bloquante tout en continuant à les exécuter et à les rapporter. Créer des éléments de travail Azure Boards pour chaque test mis en quarantaine. Identifier la cause racine en collectant les journaux de synchronisation et de réseau et en supprimant les attentes non déterministes. Cela maintient la fiabilité des pipelines tout en favorisant des corrections permanentes.

Valider la performance avec Azure Load Testing et k6

Modéliser les parcours clés sous forme de plans JMeter et les exécuter dans Azure Load Testing après le déploiement en pré-production (staging), avec des critères de réussite/échec sur la latence p95 et les taux d’erreur. Pour les tests de développeur au niveau de l’API, exécuter des scripts k6 en intégration continue (CI) avec des seuils intégrés. Ajouter une porte (gate) Azure Monitor pour bloquer la production si les bases de référence de la pré-production (staging) ne sont pas respectées. Ces outils fournissent une application de la performance évolutive et mesurable, alignée sur le concept de porte (gate) de la Q&A.

Démontrer la résilience avec Azure Chaos Studio

Concevoir des expériences qui injectent de la latence réseau et une pression CPU sur des microservices sélectionnés en pré-production (staging) pendant que Application Insights suit les budgets d’erreur et la récupération. Exiger que toutes les expériences de résilience respectent les SLO avant la promotion. Les contrôles de gouvernance de Chaos Studio correspondent au besoin d’Adobe d’avoir un rayon d’impact (blast radius) contrôlé et des expériences auditables.

Assurer l’accessibilité et la conformité

Intégrer axe-core dans les tests d’interface utilisateur Playwright pour détecter automatiquement les violations de la norme WCAG 2.1 AA sur les écrans principaux. Publier les rapports de violation en tant qu’artefacts de build et provoquer un échec en cas de problèmes critiques. Planifier des sessions d’accessibilité exploratoires avec Azure Test Plans et l’extension Test & Feedback pour une vérification manuelle. Cela combine une couverture automatisée avec des vérifications centrées sur l’humain.

Fournir la traçabilité et les analyses

Lier les tests automatisés à Azure Test Plans le cas échéant, aligner les suites sur les exigences et utiliser Test Analytics pour suivre l’évolution des taux de réussite, identifier les tests instables (flaky) et cibler les corrections. Cela permet à la direction de visualiser d’un coup d’œil les tendances de la qualité et l’état de préparation à la mise en production.

Chaque choix met l’accent sur les services natifs Azure DevOps et Azure pour une intégration de premier ordre, une gouvernance via des vérifications d’environnement et des portes (gates), et une stratégie de test équilibrée qui optimise la vitesse du retour d’information, la fiabilité et la conformité.

← Sécurité · Tous les domaines · Surveillance →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →