Microsoft AZ-400: Estrategia de pruebas e ingeniería de calidad — Guía de estudio

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

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

La estrategia de pruebas y la ingeniería de calidad en Azure DevOps consisten en generar confianza en el software a través de una retroalimentación rápida y determinista a lo largo del ciclo de vida de la entrega, mientras se utilizan las capacidades nativas de la plataforma para aplicar puertas de calidad y trazabilidad. Las estrategias eficaces combinan una pirámide de pruebas equilibrada, validación temprana y continua (TDD/BDD), automatización robusta en las canalizaciones, gestión disciplinada de datos de prueba y técnicas avanzadas como pruebas de carga, ingeniería del caos, comprobaciones de accesibilidad y despliegues condicionados por la cobertura. Azure Test Plans, Azure Pipelines, Azure Load Testing y Azure Chaos Studio te proporcionan las herramientas para implementar estas prácticas a escala.

Fundamentos de la estrategia de pruebas

Una pirámide de pruebas pragmática reduce el riesgo con pruebas rápidas y de bajo costo en la base y un número menor de pruebas de alta fidelidad en la cima:

Las pruebas unitarias validan la lógica aislada y deben predominar en el conjunto de pruebas. Busca una ejecución rápida y un alto determinismo. Para la mayoría de los productos, establece objetivos de cobertura de pruebas unitarias en el rango del 70–90% para los servicios críticos, reconociendo que la cobertura es una métrica indirecta y no una garantía de calidad.
Las pruebas de integración verifican los contratos entre componentes (p. ej., base de datos, mensajería, servicios externos) utilizando límites realistas y dependencias efímeras. Ejecútalas en paralelo cuando sea posible, en entornos en contenedores o sandboxed, y apunta a un 30–60% de las rutas de código críticas ejercitadas a través de escenarios a nivel de integración.
Las pruebas de extremo a extremo (E2E) validan los recorridos del usuario a través de toda la pila (full stack). Mantenlas al mínimo y enfocadas en las rutas de mayor valor (típicamente 5–15% del conjunto de pruebas) para evitar una retroalimentación frágil y lenta.

Las prácticas de pruebas de desplazamiento a la izquierda (shift-left) reducen los defectos de forma más temprana:

El desarrollo guiado por pruebas (TDD) impone ciclos de rojo–verde–refactorizar, informa el diseño y aumenta la confianza a nivel unitario. Haz que el TDD sea práctico proporcionando a los ingenieros ejecutores de pruebas locales y rápidos, y manteniendo las pruebas herméticas y deterministas.
El desarrollo guiado por comportamiento (BDD) captura la intención en un vocabulario compartido utilizando Gherkin. Los equipos de .NET pueden usar SpecFlow; los equipos de Java y JavaScript suelen usar Cucumber. Vincula los escenarios de BDD a los criterios de aceptación de Azure Boards y publica sus resultados en Azure Test Plans para obtener trazabilidad.

La gestión de datos de prueba elimina el no determinismo:

Los datos sintéticos proporcionan conjuntos de datos deterministas y seguros para la privacidad para las pruebas unitarias y de integración. Genéralos con librerías faker específicas del lenguaje y valores semilla (seed) que permitan la reproducibilidad.
El enmascaramiento de datos (data masking) permite conjuntos de datos de prueba realistas sin exponer información personal o sensible. Utiliza herramientas de enmascaramiento de bases de datos o canalizaciones de datos que apliquen transformaciones irreversibles. Para Azure SQL Database, exporta instantáneas a una suscripción de preproducción (staging) y aplica el enmascaramiento antes de su uso en pruebas.
La paridad de entornos garantiza que los resultados de las pruebas sean significativos. Aprovisiona los entornos de prueba con infraestructura como código (ARM/Bicep/Terraform) para que los componentes del sistema, la configuración y la topología de red coincidan con producción de la forma más factible posible. Mantén las migraciones de esquema sincronizadas en todos los entornos.

La detección y gestión de pruebas inestables (flaky tests) protegen los bucles de retroalimentación:

Las causas incluyen condiciones de carrera (timing races), dependencias externas, acoplamiento por el orden de las pruebas y contención de recursos. Usa la tarea Visual Studio Test de Azure Pipelines con rerunFailedTests habilitado para reducir el ruido transitorio mientras investigas.
La cuarentena de pruebas que no son deterministas para mantener las canalizaciones en verde, etiquetándolas y aislándolas en un conjunto separado que se ejecuta e informa pero no hace fallar la compilación. Realiza un seguimiento de la deuda de cuarentena con elementos de trabajo de Azure Boards.
El análisis de causa raíz requiere instrumentación. Captura registros, métricas de tiempo y detalles del entorno durante las ejecuciones; reproduce localmente con la misma semilla y dependencias; elimina la dependencia de relojes del sistema, red y sistema de archivos no simulados (unmocked); y corrige el no determinismo en su origen.

Capacidades de prueba de Azure DevOps y Azure

Azure Test Plans proporciona pruebas manuales y exploratorias de primer nivel, además de trazabilidad:

Los casos de prueba definen pasos, resultados esperados y parámetros; los pasos compartidos y los casos de prueba parametrizados reducen la duplicación. Las suites basadas en requisitos alinean los casos con los Product Backlog Items o las historias de usuario, mientras que las suites estáticas y basadas en consultas agrupan las pruebas para su ejecución.
Las ejecuciones de prueba (test runs) asignan suites y configuraciones a los evaluadores (testers), registran los resultados y las duraciones, y capturan diagnósticos. El registro detallado de errores (bugs) incluye capturas de pantalla, video, datos del entorno y registros de acciones.
Las pruebas exploratorias utilizan la extensión de navegador Test & Feedback para capturar estatutos (charters), notas de sesión y artefactos durante la exploración ad-hoc. Vincule los hallazgos a los elementos de trabajo (work items) y analice la cobertura de los requisitos y las sesiones de prueba.

Las pruebas automatizadas se integran directamente en los pipelines:

Utilice la tarea Visual Studio Test (VsTest) para ejecutar pruebas de MSTest, NUnit y xUnit y publicar los resultados en formato TRX. Para .NET, es común usar

undefined

con el registrador (logger) apropiado (trx, junit).

Para Java, ejecute JUnit a través de Maven o Gradle y publique el XML de JUnit con la tarea Publish Test Results. Para JavaScript, configure los ejecutores (runners) (Jest, Mocha) para que emitan XML de JUnit.
La tarea Publish Test Results consolida los resultados y las tendencias a lo largo de las ejecuciones. Estandarice los formatos de resultados (TRX o JUnit XML) para unificar los informes y habilitar el análisis de pruebas inestables (flaky tests).
Vincule las ejecuciones de pruebas automatizadas a Azure Test Plans mapeando los casos de prueba a los métodos de prueba automatizados, asegurando una trazabilidad de extremo a extremo desde el requisito hasta la ejecución y el defecto.

La cobertura de código es una barrera de calidad medible:

Recopile la cobertura con Coverlet (para .NET), JaCoCo (Java) o Cobertura/lcov (JavaScript). Convierta a formatos que Azure DevOps entienda y publique a través de Publish Code Coverage Results para mostrar tendencias y deltas.
Aplique umbrales mínimos en el momento de la compilación. Para .NET, utilice los interruptores de umbral (threshold switches) de Coverlet para hacer que la compilación falle si la cobertura de línea o de rama cae por debajo de la política. Alternativamente, utilice la extensión Build Quality Checks para aplicar políticas de cobertura y basadas en tendencias.
Los despliegues condicionados por cobertura (coverage-gated) impiden la progresión cuando la calidad disminuye. En YAML, haga que la etapa de calidad falle si la cobertura está por debajo del objetivo; para las versiones clásicas (classic releases), utilice puertas (gates) que invoquen una Azure Function o una comprobación REST para validar la cobertura medida antes de la promoción.

Rendimiento, Caos y Resiliencia

Las pruebas de carga y rendimiento validan los requisitos no funcionales de forma temprana y continua:

Azure Load Testing orquesta la carga basada en JMeter a escala mientras correlaciona la telemetría del backend desde Application Insights. Importe planes de prueba JMX, establezca criterios de aprobación/fallo (p. ej., latencia p95, tasa de errores) y muestre los resultados en los pipelines. Utilice la puerta (gate) de Azure Monitor o las comprobaciones de entorno para bloquear la progresión cuando no se cumplan las líneas base (baselines).
Apache JMeter sigue siendo una opción versátil para las pruebas de carga a nivel de protocolo. Mantenga los grupos de hilos (thread groups) y las aserciones parametrizadas para la CI. Almacene los conjuntos de datos JMX y CSV con el código, versionados junto con los escenarios.
k6 permite realizar pruebas de carga como código de una manera amigable para el desarrollador. Ejecute k6 en Azure Pipelines a través de un contenedor o un tiempo de ejecución de Node, capture los resultados y expórtelos a JUnit o JSON para su publicación. Utilice expresiones de umbral (threshold expressions) dentro de los scripts de k6 para hacer que las ejecuciones fallen de forma determinista.
La gestión de las líneas base (baselines) es fundamental. Realice un seguimiento de las tendencias de latencia, rendimiento (throughput) y utilización de recursos por entorno. Establezca SLOs y asegúrese de que las pruebas se ejecuten con volúmenes de datos y configuraciones representativos.

La ingeniería del caos (chaos engineering) verifica la resiliencia bajo condiciones de fallo:

Azure Chaos Studio inyecta fallos en los recursos de Azure con un radio de impacto (blast radius) controlado y con salvaguardas. Los tipos de experimentos incluyen presión de CPU/memoria en VMs, latencia de red/agujero negro (blackhole), terminación de procesos y limitación de servicios (throttling).
Ejecute los experimentos primero en preproducción e instruméntelos con Application Insights y Azure Monitor para capturar los modos de fallo, los presupuestos de error (error budgets) y el comportamiento de recuperación automática.
La validación de la resiliencia combina el caos con sondeos de estado (health probes) y transacciones sintéticas para garantizar que las rutas críticas para el usuario permanezcan disponibles o se degraden con elegancia. Promocione solo cuando se confirmen las hipótesis de resiliencia y las alertas se comporten según lo diseñado.

Accesibilidad, cumplimiento y gobernanza

La accesibilidad y el cumplimiento son fundamentos de la calidad:

Cumplir como mínimo con WCAG 2.1 AA para las experiencias de cara al público. Traducir los requisitos en criterios de aceptación en Azure Boards y Azure Test Plans con casos de prueba de accesibilidad dedicados.
Automatizar las comprobaciones con axe-core integrado en frameworks de pruebas de UI como Playwright, Cypress o Selenium. Hacer que las compilaciones fallen cuando se detecten infracciones críticas y publicar los informes de accesibilidad como artefactos de la canalización.
Complementar la automatización con auditorías manuales (navegación por teclado, soporte para lectores de pantalla, contraste de color en contextos dinámicos) y capturar los hallazgos en sesiones exploratorias utilizando la extensión Test & Feedback.
La gobernanza de la calidad y el cumplimiento en Azure Pipelines utiliza comprobaciones de entorno y puertas (gates). Para el rendimiento y la disponibilidad, consultar Azure Monitor o Azure Load Testing para obtener bases de referencia antes del despliegue. Para el control de la cobertura o la accesibilidad, invocar una función o una comprobación REST que analice los informes publicados y devuelva un resultado de aprobado/fallido (pass/fail). Esto impone la calidad no funcional como un prerrequisito para el lanzamiento, no como una ocurrencia tardía.

La publicación y el análisis de los resultados de las pruebas cierran el ciclo:

Estandarizar los formatos de resultados y los informes de cobertura para poblar Test Analytics, analizar las tendencias de las tasas de aprobación y detectar automáticamente las pruebas inestables (flaky tests).
Utilizar políticas de compilación y protecciones de rama para exigir pruebas superadas (green tests) y una cobertura adecuada antes de fusionar (merging). Mantener un feedback rápido; paralelizar las fases de prueba, fragmentar (shard) las suites grandes y almacenar en caché las dependencias para reducir el tiempo de ciclo.

Escenario de problema práctico

Adobe está modernizando una plataforma de procesamiento de documentos a microservicios en Azure. La dirección de ingeniería exige una cadencia de lanzamientos más rápida sin regresiones, bases de referencia de rendimiento demostrables, resiliencia a fallos de red regionales y cumplimiento de WCAG 2.1 AA. Las canalizaciones actuales sufren de pruebas E2E inestables (flaky) y datos de prueba inconsistentes.

Establecer la pirámide de pruebas y las prácticas de shift-left

Adoptar TDD para las bibliotecas y servicios principales para crear una base grande y determinista de pruebas unitarias, utilizando NUnit y xUnit para componentes .NET y JUnit para Java. BDD con SpecFlow y Cucumber captura los criterios de aceptación entre equipos como especificaciones ejecutables. Esto garantiza un feedback rápido y un entendimiento compartido.

Automatizar pruebas y publicar resultados en Azure Pipelines

Usar VsTest para .NET y Maven/Gradle para Java para ejecutar pruebas unitarias y de integración. Publicar los resultados con Publish Test Results y la cobertura con Publish Code Coverage Results para centralizar los informes y habilitar el análisis de pruebas inestables (flaky tests). Las tareas integradas proporcionan una estrecha integración con Azure DevOps y reducen las herramientas personalizadas.

Imponer umbrales de cobertura de código y controlar los despliegues con puertas (gates)

Configurar los umbrales de Coverlet y JaCoCo para que las compilaciones fallen si la cobertura cae por debajo del 80 % por línea y el 60 % por rama para los servicios críticos. Añadir una comprobación de lanzamiento que llame a una Azure Function para leer el último artefacto de cobertura y devolver un resultado de aprobado/fallido (pass/fail), impidiendo el despliegue cuando la cobertura está por debajo de la política. Esto formaliza las puertas de calidad (quality gates) sin intervención humana.

Implementar la gestión de datos de prueba para el determinismo

Generar conjuntos de datos sintéticos para pruebas unitarias y de integración utilizando bibliotecas faker. Para las pruebas de sistema, clonar copias enmascaradas de bases de datos Azure SQL a través de una canalización automatizada utilizando Data Factory para aplicar un enmascaramiento irreversible. Aprovisionar entornos con Bicep para mantener la paridad. Esto elimina el riesgo de privacidad y la inestabilidad relacionada con los datos.

Contener y eliminar las pruebas inestables (flaky tests)

Habilitar rerunFailedTests en VsTest para mitigar fallos transitorios y etiquetar las especificaciones inestables con un marcador de cuarentena que las excluya de la suite de bloqueo, aunque se sigan ejecutando y reportando. Crear elementos de trabajo en Azure Boards para cada prueba en cuarentena. Analizar la causa raíz recopilando registros de tiempo y de red y eliminando esperas no deterministas. Esto mantiene la fiabilidad de las canalizaciones mientras se impulsan soluciones permanentes.

Validar el rendimiento con Azure Load Testing y k6

Modelar los recorridos clave (key journeys) como planes de JMeter y ejecutarlos en Azure Load Testing después del despliegue en el entorno de staging, con criterios de aprobado/fallido (pass/fail) sobre la latencia p95 y las tasas de error. Para las pruebas de desarrollador a nivel de API, ejecutar scripts de k6 en CI con umbrales integrados. Añadir una puerta (gate) de Azure Monitor para bloquear el paso a producción si no se cumplen las bases de referencia de staging. Estas herramientas proporcionan una imposición del rendimiento escalable y medible, alineada con el concepto de puerta (gate) del Q&A.

Demostrar la resiliencia con Azure Chaos Studio

Diseñar experimentos que inyecten latencia de red y presión de CPU en microservicios seleccionados en staging, mientras Application Insights monitoriza los presupuestos de error y la recuperación. Exigir que todos los experimentos de resiliencia cumplan los SLO antes de la promoción a producción. Los controles de gobernanza de Chaos Studio se alinean con la necesidad de Adobe de tener un radio de impacto controlado y experimentos auditables.

Garantizar la accesibilidad y el cumplimiento

Integrar axe-core en las pruebas de UI de Playwright para detectar automáticamente infracciones de WCAG 2.1 AA en las pantallas principales. Publicar los informes de infracciones como artefactos de compilación y hacer que la compilación falle ante problemas críticos. Programar sesiones exploratorias de accesibilidad con Azure Test Plans y la extensión Test & Feedback para la verificación manual. Esto combina la cobertura automatizada con comprobaciones centradas en el ser humano.

Proporcionar trazabilidad y análisis

Vincular las pruebas automatizadas a Azure Test Plans cuando sea apropiado, alinear las suites con los requisitos y usar Test Analytics para analizar tendencias en las tasas de aprobación, identificar pruebas inestables (flaky tests) y enfocar la remediación. Esto permite a la dirección ver las tendencias de calidad y la preparación para el lanzamiento de un vistazo.

Cada elección enfatiza los servicios nativos de Azure DevOps y Azure para una integración de primera clase, la gobernanza a través de comprobaciones de entorno y puertas (gates), y una estrategia de pruebas equilibrada que optimiza la velocidad del feedback, la fiabilidad y el cumplimiento.

← Seguridad · Todos los dominios · Monitorización →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →