Estrategias de arquitectura para pruebas

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

Al introducir un cambio en la carga de trabajo, debe asegurarse de que funciona según lo previsto y no presenta nuevos problemas. Las pruebas son la forma en que se evalúan esos cambios. Es una práctica esencial para mantener la calidad y crear confianza en la carga de trabajo.

Las pruebas eficaces ofrecen una carga de trabajo confiable y de alta calidad. Evita que los defectos lleguen a producción, reduce los costosos reprocesos y retrasos, y mantiene su trabajo alineado con los objetivos empresariales a lo largo del ciclo de vida de desarrollo.

En este artículo se proporcionan estrategias que le ayudarán a ofrecer una carga de trabajo de alta calidad a través de prácticas de prueba eficaces. Sirve como guía fundamental para las instrucciones de pruebas especializadas en otros pilares, como el rendimiento, la confiabilidad y la seguridad.

Para obtener instrucciones de implementación sobre las prácticas de prueba, consulte el artículo complementario: Crear confianza en Azure cargas de trabajo con prácticas de prueba eficaces.

Formalizar la estrategia y el plan de pruebas

La estrategia de prueba y los planes de prueba son artefactos esenciales. Proporcionan una hoja de ruta clara para sus esfuerzos de prueba y garantizan que todos trabajen hacia los mismos objetivos de calidad.

Definición de la estrategia de prueba

La estrategia de prueba es un plano técnico de alto nivel que guía el enfoque general de pruebas. Define los objetivos de prueba, el ámbito, las metodologías, las herramientas, los roles y las responsabilidades. Le ayuda a tomar decisiones fundamentadas sobre las prioridades de prueba, la asignación de recursos y la administración de riesgos. También captura cómo se comunica con las partes interesadas e informa de los resultados.

Una estrategia de pruebas bien definida obtiene el respaldo de las partes interesadas y garantiza que todos los miembros del equipo sigan estándares de calidad consistentes. Proporciona dirección y estructura, alinea las pruebas con los objetivos empresariales y protege la calidad a largo plazo.

Por lo general, la estrategia de prueba permanece coherente entre las versiones de una carga de trabajo determinada. Pero personalícelo siempre para reflejar las necesidades específicas y los objetivos empresariales de esa carga de trabajo.

Crear el plan

Una vez que acepte la estrategia de prueba con su equipo, formalícela en un plan de prueba con casos de uso alineados con los objetivos empresariales.

El plan de prueba es un documento detallado que guía la ejecución de pruebas para una versión específica. Describe el ámbito de las pruebas, casos de prueba específicos, informes de defectos, escalas de tiempo, asignaciones de recursos y criterios de entrada y salida para las actividades de prueba.

Un plan de prueba bien estructurado hace que las pruebas sean eficaces y se alineen con los objetivos y escalas de tiempo de la versión. Es su punto de referencia para realizar un seguimiento del progreso y tomar decisiones informadas durante las pruebas.

Ejemplo: En el caso de un sistema de desprotección de comercio electrónico, la estrategia de prueba define que los flujos de pago siempre tienen prioridad, especifica herramientas de prueba para el sistema, como JMeter para pruebas de carga. Aclara las responsabilidades del equipo para los distintos tipos de prueba.

El plan de prueba de una versión se centra en agregar compatibilidad con Apple Pay. Define exactamente qué probar para Apple Pay en esta versión, asigna recursos (dos ingenieros y tres dispositivos iOS), establece una programación de cuatro semanas y establece criterios de entrada claros (código completo y entorno configurado) y criterios de salida (todas las pruebas superan y cero errores críticos).

Prueba temprana, prueba a menudo, prueba lo que importa

Inicie las pruebas en las primeras fases del ciclo de vida de desarrollo de software. Cuando se encuentran problemas críticos tarde, esto conlleva un incremento del trabajo de rehacer y lanzamientos más lentos. Con demasiada frecuencia, los arquitectos pasan por alto los requisitos de prueba en la fase de diseño, lo que afecta negativamente a la calidad general.

Los desarrolladores deben adoptar una mentalidad de control de calidad. Piense en las pruebas incluso durante el diseño. Úselo para aclarar los requisitos y detectar posibles limitaciones. Realice pruebas como parte integral del proceso de desarrollo. Asuma la responsabilidad de escribir y mantener pruebas al mismo tiempo que su código.

Al detectar problemas temprano, puede responder rápidamente. Por ejemplo, puede priorizar los cambios de diseño esenciales que afectan a la experiencia del usuario sobre las correcciones de errores rutinarias. La actuación temprana reduce las sorpresas y retrasos de última hora.

Las pruebas no son un evento único. Siga probando después del lanzamiento como parte de una mentalidad de prueba continua. Revise, actualice y expanda periódicamente el conjunto de pruebas para cubrir nuevas características y solucionar errores detectados en producción para mantener la calidad a largo plazo.

Compensación. Las pruebas tempranas y continuas pueden aumentar los costos operativos y pueden ralentizar inicialmente el desarrollo o crear fricción en equipo. Lograr un equilibrio, identificar qué pruebas y cambios son esenciales en una fase temprana y cuáles se pueden aplazar a fases posteriores. Esto garantiza la eficiencia sin comprometer la calidad.

Prueba en producción con medidas de seguridad

Incluso con prácticas de prueba y validación sólidas, algunos problemas solo aparecen en el tráfico de producción del mundo real. Para encontrar problemas que no se pueden simular, realice pruebas controladas en producción con medidas de seguridad que limiten la exposición del usuario y reduzcan el riesgo.

Planee, aísle y supervise todas las pruebas de producción. Cuando lo hace, obtendrá comentarios reales del usuario y datos de rendimiento sin interrumpir a todos los demás.

Considere las estrategias de exposición progresivas, como las versiones controladas, solo después de que la carga de trabajo cumpla los criterios de salida y demuestre una calidad sólida. Este enfoque publica primero las actualizaciones de un grupo pequeño y dirigido de usuarios, lo que le ayuda a descubrir rápidamente problemas que podrían no aparecer en entornos de versión preliminar. Con este enfoque, se acelera el proceso de prueba y se reducen los costos asociados.

Supervise las pruebas de producción continuamente para encontrar problemas al principio. Implemente medidas de seguridad automatizadas que detengan las pruebas si afectan negativamente a los usuarios, como mecanismos de reversión automatizados y alertas en tiempo real. Estas técnicas garantizan una respuesta rápida y minimizan las interrupciones.

Riesgo: Tenga cuidado al probar en producción, ya que afecta directamente a los clientes reales. Implemente siempre medidas de seguridad y limite la exposición para minimizar posibles impactos negativos en su negocio.

Aplicar un enfoque por capas en la cobertura de pruebas

Una estrategia de cobertura de pruebas estratificada proporciona comentarios rápidos, detección temprana de defectos y versiones más rápidas. Al estructurar pruebas en capas, puede aislar y depurar rápidamente defectos, lo que facilita la identificación y resolución de problemas.

Usar la pirámide de prueba como guía

El modelo piramidal de prueba ilustra este enfoque en capas para la automatización de pruebas. Distribuye las pruebas en diferentes capas para maximizar la cobertura y minimizar el tiempo de ejecución y los costos de mantenimiento.

• Capa base: las pruebas unitarias comprueban los componentes individuales de forma aislada. Se ejecutan rápidamente y proporcionan retroalimentación inmediata.
• Nivel intermedio: las pruebas de integración comprueban las interacciones entre los componentes y los servicios. Se ejecutan más lentamente que las pruebas unitarias, pero proporcionan una cobertura más amplia del comportamiento del sistema.
• Capa superior: las pruebas de un extremo a otro validan los recorridos del usuario a través de todo el sistema, simulando escenarios reales. Estas pruebas se ejecutan de manera más lenta, pero ofrecen la mayor confianza en la calidad general.

Puede integrar más fácilmente las pruebas de nivel base y intermedio en las canalizaciones porque tienen dependencias mínimas. Esta integración permite que los comentarios rápidos cuando se produzcan errores en las pruebas y permita que el proceso de compilación se detenga inmediatamente, lo que impide que el código defectuoso avance aún más.

A medida que crece la cobertura de pruebas, el tiempo de ejecución del flujo de trabajo puede aumentar significativamente. Mantenga un ciclo de retroalimentación rápido usando estrategias de ejecución de pruebas distribuidas y paralelas, manteniendo las pipelines eficientes a medida que aumenta la cobertura.

Compensación. Hay un equilibrio entre la cobertura de pruebas y la eficacia de la canalización. Aunque los conjuntos de pruebas más grandes aumentan la cobertura, también aumentan el tiempo de ejecución y el costo. No siempre ofrecen una rentabilidad significativa de la inversión.

Pruebas independientes de la aplicación y de la infraestructura

Cree una segmentación clara entre probar el código de la aplicación y el código de infraestructura.

Separe las pruebas por lo que validan y quién las posee y, a continuación, agregue pruebas de integración que confirmen que ambas capas funcionan juntas. Las pruebas de código de aplicación deben centrarse en validar el comportamiento de la carga de trabajo. Las pruebas de código de infraestructura deben centrarse en validar el aprovisionamiento y la configuración de la infraestructura.

Agregue pruebas entre capas que ejercen la aplicación y la infraestructura juntas. Las pruebas de infraestructura por sí mismas pueden dar confianza falsa. El módulo IaC puede aprovisionar todos los recursos correctamente, pero si la aplicación no puede usar realmente esos recursos, la carga de trabajo sigue produciendo un error. Valide la infraestructura mediante la observación del comportamiento de la aplicación mediante la implementación del software y la ejecución de pruebas en ella. Una prueba de humo simple en un punto de conexión de mantenimiento detecta esa brecha rápidamente.

Incorporar diferentes tipos de pruebas

Use varios métodos de prueba en toda la carga de trabajo. Completar pruebas unitarias no significa que haya terminado las pruebas. Cada aspecto de la carga de trabajo necesita un enfoque distinto. Varios tipos de prueba mejoran la calidad general y crean confianza en que el sistema funciona según lo previsto.

Use la herramienta adecuada para el trabajo. Identifique las herramientas necesarias para realizar varios tipos de pruebas. Si no tiene una herramienta, compre la herramienta. No lo compile, ya que podría introducir riesgos. Investigue las herramientas y sus características, como los costos de licencia y si las herramientas se integran directamente con los requisitos de carga de trabajo. Evalúe la experiencia del equipo con cada herramienta y considere la compatibilidad y la integración mediante una prueba de concepto. Aproveche el soporte técnico y el entrenamiento disponibles para las herramientas si el equipo de cargas de trabajo no tiene esa experiencia.

Elija el tipo de prueba adecuado en función de la madurez de la carga de trabajo y el perfil de riesgo. Comience con la validación funcional a través de las capas piramidales de prueba y agregue pruebas no funcionales, como rendimiento, seguridad y resistencia. Alinee la selección del tipo de prueba con los escenarios y riesgos críticos de la carga de trabajo.

En la tabla siguiente se muestra cuándo aplicar diferentes tipos de prueba a lo largo del ciclo de pruebas. Cada uno aborda riesgos específicos. Aunque esta tabla no es una lista exhaustiva de todos los tipos de prueba posibles, sirve como ejemplo ilustrativo.

• Combine diferentes tipos de prueba para evaluar la carga de trabajo desde varios ángulos. Ejecute una combinación para detectar problemas que se pierdan en cualquier prueba.

• Priorice los tipos de prueba en función del impacto empresarial y el riesgo. Evalúe cada característica o cambio en función de su posible impacto y riesgos asociados. En el caso de las cargas de trabajo orientadas al cliente, resalte las pruebas de un extremo a otro y de la interfaz de usuario. En el caso de las cargas de trabajo controladas por API, céntrese en la integración y las pruebas de contratos. Para los sistemas de alta disponibilidad, invierta en pruebas de resistencia y caos.

Compromiso. Priorice las pruebas de seguridad desde el inicio del ciclo de lanzamiento. Este enfoque ayuda a evitar vulnerabilidades y garantiza implementaciones más seguras. Sin embargo, esta prioridad puede ralentizar el ritmo en el que se entregan nuevas características a producción.

Tratar los recursos de prueba tan importantes como recursos de código

Los recursos de prueba capturan reglas empresariales esenciales, casos perimetrales, patrones históricos de defectos y conocimientos organizativos valiosos. Cuando se degrada la calidad de las pruebas, los equipos pierden tiempo depurando pruebas no confiables en lugar de encontrar defectos reales. Esta situación crea frustración y los desarrolladores pierden confianza en el marco de pruebas.

Trate los recursos de prueba con el mismo rigor que los recursos de código. Asumir la plena responsabilidad de los recursos de prueba mejora la confiabilidad y la calidad general del marco de pruebas.

Estructura y protección de las pruebas

Estructura el código de prueba con los mismos principios arquitectónicos que el código de la aplicación.

• Mantenga las pruebas junto con el código en el mismo repositorio para simplificar el mantenimiento y promover la coherencia.

• Implemente controles de gobernanza equivalentes , como revisiones de código obligatorias, directivas de solicitud de incorporación de cambios y canalizaciones de validación de compilación para mantener estándares de calidad.

• Versione los datos de prueba junto con el código. Al cambiar esquemas de datos o reglas de negocio, actualice los datos de prueba para que coincidan con el estado actual de la carga de trabajo.

• Realice la validación de línea base de sus propias pruebas para asegurarse de que funcionan según lo previsto. Los fallos deben apuntar a problemas reales de la aplicación, no defectos en las pruebas. Verifique que las pruebas fallen adecuadamente y pasen de manera consistente cuando su carga de trabajo esté en buen estado. Solucione las pruebas no confiables rápidamente y asegúrese de que las aserciones de prueba refuerzan la intención de cada prueba.

• Configure los procedimientos que garantizan la independencia y confiabilidad de las pruebas, como aislar los datos de prueba, evitar el estado compartido e implementar procesos automatizados de configuración y desmontaje.

• Diseñe pruebas para la ejecución en paralelo. Para beneficiarse de la ejecución de pruebas paralelas, diseñe las pruebas para que sean independientes para que se puedan ejecutar en cualquier orden sin afectar a los resultados. Las pruebas independientes siempre deben configurar y desmontar sus propios datos y dependencias para que los estados no se transfieran a la siguiente ejecución de pruebas.

Si la aplicación requiere secuenciación en pruebas, use marcos de pruebas que admitan la ejecución ordenada de pruebas.

• Implemente prácticas de codificación seguras en el código de prueba para evitar vulnerabilidades. Las pruebas suelen interactuar con los datos y sistemas de producción, que pueden introducir riesgos de bibliotecas importadas o código de prueba vulnerable. Trate las pruebas con los mismos estándares de seguridad que el código de producción.

Mantener los recursos de prueba alineados con los patrones de uso actuales

Los recursos de prueba de rendimiento contienen conocimientos críticos sobre el comportamiento esperado de la carga de trabajo, los umbrales de rendimiento aceptables y los patrones de tráfico realistas.

• Organice conjuntos de pruebas por tipo. Mantenga pruebas de carga, pruebas de esfuerzo y pruebas de resistencia en conjuntos independientes. No los mezcles. Cada tipo tiene diferentes requisitos de configuración, duraciones de ejecución y criterios de éxito. Los conjuntos organizados facilitan la ejecución de pruebas dirigidas, comparan los resultados entre ejecuciones y mantienen cada conjunto de forma independiente.

• Actualice los datos de prueba con regularidad. Los datos de prueba obsoletos provocan resultados poco realistas. Vuelva a generar datos de prueba para reflejar las características actuales de los datos de producción cada vez que cambie el modelo de datos, los volúmenes de datos crezcan o cambien los datos demográficos del usuario.

• Revise los escenarios de prueba a medida que evoluciona la carga de trabajo. Programe revisiones periódicas para asegurarse de que los escenarios siguen reflejando el uso real.

• Los datos de prueba deben ser similares a los datos de producción reales. Use datos sintéticos que tengan características de datos de producción. Reserve conjuntos de datos de producción (anonimizados correctamente) para determinados escenarios, como resaltar comportamientos de administración de datos como la coherencia de transacciones, la latencia y el control de volúmenes.

Mantenimiento y evolución de las pruebas

Mantener los recursos de prueba es fundamental para conservar la calidad de la carga de trabajo. Estos recursos suelen contener conocimientos de la organización valiosos. Si no los mantiene regularmente, se vuelven obsoletos, lo que reduce su eficacia y su capacidad de ofrecer versiones de alta calidad.

A medida que la carga de trabajo evoluciona, los recursos de prueba deben evolucionar en paralelo para mantenerse alineados con los objetivos empresariales.

• Comience en pequeño y aumente deliberadamente la suite de regresión. El conjunto de pruebas de regresión debe contener las pruebas más valiosas y estables. Agregue pruebas cuando se produzcan incidentes de producción, al corregir errores críticos y al introducir cambios de alto riesgo.

• Automatice el conjunto de regresión para que se ejecute de forma coherente sin intervención humana. Cree pruebas de humo rápidas que se ejecuten en cada confirmación y pruebas de regresión más amplias que se ejecuten todas las noches o antes del lanzamiento.

• Mantenga sincronizados los scripts de automatización de pruebas y los casos de prueba. Los casos de prueba capturan la intención, el ámbito y los resultados esperados. Si los scripts de automatización difieren de sus casos de prueba correspondientes, es difícil realizar un seguimiento de lo que se está validando, lo que conduce a brechas en la cobertura y la responsabilidad.

• Planee de forma proactiva las actualizaciones periódicas de los casos de prueba a medida que introduce nuevas características y mejoras en la carga de trabajo. Al automatizar un caso de prueba, vincule la automatización al caso de prueba original para que pueda realizar un seguimiento de la cobertura.

Administrar la deuda técnica.

Programe sprints regulares de mantenimiento de pruebas para abordar la acumulación de deuda antes de que se convierta en abrumadora. Las pruebas intermitentes, la cobertura duplicada, las pruebas obsoletas y el diseño deficiente de pruebas contribuyen a la deuda técnica de pruebas.

• Priorice la corrección o eliminación de pruebas no confiables para mantener la integridad del conjunto de pruebas. Un conjunto más pequeño de pruebas confiables es más valioso que un gran conjunto de pruebas desafinadas.

• Tome decisiones estratégicas sobre la omisión o aplazamiento de pruebas. Considere la posibilidad de omitir pruebas para código trivial o de bajo riesgo, como captadores y establecedores simples sin lógica de negocios, casos perimetrales extremadamente raros, bibliotecas de terceros y código heredado programado para su eliminación. Documente estas decisiones para que el equipo pueda volver a revisarlas como cambios de contexto.

• Evalúe el conjunto de pruebas y separe las pruebas confiables y coherentes de las propensas a cambios externos. Las pruebas que se interrumpen con frecuencia debido a factores externos a su control, como las pruebas de iu afectadas por las actualizaciones frecuentes de la interfaz de usuario, pueden no ser buenos candidatos para la automatización. Esta separación le ayuda a decidir qué pruebas automatizar y cuáles mantener manual.

Compromiso. Al eliminar pruebas frágiles, se reduce la cobertura de automatización. Equilibre esta reducción al centrar la automatización en interfaces estables y flujos de trabajo críticos, al tiempo que acepta pruebas manuales para cambiar con frecuencia los elementos de la interfaz de usuario.

No todas las pruebas merecen mantenimiento continuo. Retire las pruebas para las características que ha quitado, las pruebas que duplican la cobertura y las pruebas que ya no proporcionan valor. Documente por qué va a quitar las pruebas para que la decisión sea clara para su equipo.

Extiende la observabilidad a tu framework de pruebas

La observabilidad en las pruebas proporciona dos ventajas clave. En primer lugar, confirma que el marco de pruebas funciona. En segundo lugar, proporciona visibilidad continua sobre la calidad y el estado de la carga de trabajo.

Sin esta visibilidad, te enfrentas a dificultades considerables al diagnosticar problemas, a una capacidad limitada para supervisar sistemas en tiempo real, y no obtienes información clara y accionable sobre la eficacia de la cobertura de automatización.

Los conjuntos de pruebas se deterioran con el tiempo. Las pruebas no son confiables, pierden relevancia o no pueden mantenerse al día con los cambios de carga de trabajo. Al incorporar observabilidad, puede supervisar eficazmente el estado del conjunto de pruebas, identificar y solucionar errores rápidamente y tomar decisiones fundamentadas sobre las prioridades y mejoras de mantenimiento.

Genere informes de cobertura para identificar brechas en la automatización. Cuando la cobertura de pruebas se alinea con los datos de observabilidad de incidentes de producción, los equipos obtienen información sobre qué escenarios carecen de validación adecuada.

Utilice las herramientas de informes y cobertura de pruebas estándar del sector en su plataforma para:

• Proporcionar visibilidad clara de las trayectorias de código probadas
• Identificación de pruebas con errores coherentes
• Análisis de tendencias a largo plazo en la confiabilidad de pruebas
• Rastrear los orígenes de fallos para mejoras específicas

Riesgo: Si los registros son incoherentes y demasiado detallados, podrían crear más ruido que el valor, lo que dificulta la depuración. Implemente el registro estructurado con mensajes claros, accionables y distintos niveles de detalle para garantizar que los registros proporcionen información significativa sin sobrecargar al equipo.

Simular condiciones realistas

Evalúe los flujos de trabajo desde una perspectiva del usuario final para asegurarse de que se adapte realmente a las necesidades y expectativas del cliente. Defina criterios de aceptación claros para las cargas de trabajo y diseñe pruebas que reflejen con precisión los flujos y experiencias de usuario reales, no solo los comportamientos aislados del sistema.

Escalar la cobertura estratégicamente

Escale la cobertura de pruebas en función del riesgo y el valor. Priorice la cobertura de recorridos de usuario de alto valor y rutas de acceso críticas que afecten directamente a la experiencia del cliente. A medida que aumenta la complejidad de la carga de trabajo, expanda la cobertura de pruebas mediante la evaluación de escenarios que proporcionan la mayor confianza en la calidad y confiabilidad de la carga de trabajo.

Riesgo: No inverta demasiado en un único flujo de usuario más allá del punto de disminución de los retornos. Una vez que haya logrado una cobertura suficiente para las rutas críticas, cambie el foco a otras áreas importantes. Se esfuerza por una cobertura equilibrada en lugar de la perfección en un mismo proceso.

Alineación con objetivos empresariales y SLO

Alinee las pruebas con los objetivos empresariales y los objetivos de nivel de servicio (SLO).

Establezca umbrales de calidad medibles que reflejen los compromisos empresariales y las expectativas del usuario. Acepte estos umbrales, ya que proporcionan un punto de referencia para detectar desviaciones y solucionar errores. Este enfoque protege la experiencia del usuario garantizando que los umbrales clave de calidad del servicio no estén en peligro.

Revise y actualice periódicamente las métricas de línea base para asegurarse de que siguen cumpliendo las necesidades y expectativas actuales del cliente.

Uso de datos de prueba representativos

Los datos de prueba deben representar escenarios reales lo más cerca posible.

Los datos sintéticos pueden simular escenarios de usuario auténticos a la vez que evitan la complejidad del control de datos de producción. Por ejemplo, las pruebas sintéticas pueden replicar escenarios reales mediante la generación de conjuntos de datos representativos para evaluar el rendimiento de la carga de trabajo en condiciones de escalado planeado.

Use datos sintéticos como opción predeterminada. Reserve datos de producción para escenarios específicos en los que los datos sintéticos no puedan replicar la complejidad necesaria, como probar scripts de migración de datos.

Si necesita usar datos de producción para pruebas, asegúrese de anonimizar correctamente toda la información para proteger la información confidencial.

Simulación del entorno de producción

El entorno de producción es la fuente de verdad para comprender cómo se comporta la carga de trabajo en condiciones reales. Cree un entorno que refleje estrechamente las condiciones del mundo real para que pueda confiar en que el sistema funciona según lo previsto en producción.

• Adapte su enfoque a los entornos de producción de creación de reflejo a las necesidades específicas de la carga de trabajo.

Para cargas de trabajo críticas que requieren alta disponibilidad, pruebe en un entorno dedicado que se parezca mucho a la producción. Para estas cargas de trabajo, equilibre cuidadosamente la optimización de costos con la necesidad de una validación sólida.

Use un entorno dedicado similar a producción para pruebas de rendimiento y carga para asegurarse de que el comportamiento del servicio se evalúa con precisión en condiciones realistas.

En el caso de otras cargas de trabajo, haga que el entorno refleje estrechamente la infraestructura de producción para reducir los falsos positivos, como los casos en los que las pruebas se realizan correctamente en entornos inferiores, pero producen errores en producción.

• Apunte a la coherencia en todos los entornos a medida que avanza el código a través de la canalización. Simulación de condiciones de producción en varios aspectos de la carga de trabajo, incluida la infraestructura, los datos y la seguridad, para garantizar resultados de pruebas confiables.

• Evite el desfase de configuración. Al reflejar los entornos en producción, el desfase de configuración puede crear una confianza falsa en la calidad. Implemente comprobaciones de validación automatizadas para el desfase de configuración para asegurarse de que el entorno permanece alineado con la producción. Si procede, configure las puertas de implementación para comprobar que la versión correcta se implementa antes de que comiencen las pruebas.

Riesgo: Al reflejar entornos de producción, puede aumentar significativamente los costos operativos. Evalúe si los entornos efímeros o los entornos de prueba persistentes ofrecen el equilibrio óptimo entre la eficiencia de los costos y la calidad de la carga de trabajo.

Creación de entornos de prueba basados en propósitos

Diseñe entornos con un enfoque claro en su propósito previsto. Evalúe los distintos requisitos de cada fase del ciclo de vida de las pruebas y asegúrese de que el entorno se alinea estrechamente con los objetivos de esa fase.

Diseñe intencionadamente todos los entornos de prueba para que coincidan con la fase y los objetivos específicos de las pruebas, ya sea para la validación funcional, las pruebas de integración u otros fines. Si un entorno optimizado satisface eficazmente sus necesidades de prueba, priorice ese enfoque para maximizar la eficacia.

Uso de servicios ficticios

La replicación completa de los sistemas de producción para cada escenario de prueba suele ser poco práctico. Evalúe qué componentes de la carga de trabajo puede replicar de forma segura para las pruebas sin poner en peligro los flujos de trabajo empresariales críticos. Cuando la replicación completa no es factible, use servicios ficticios que simulan con precisión comportamientos de servicio de producción para validar escenarios de forma eficaz sin riesgo de operaciones activas.

Los entornos de prueba basados en propósito proporcionan una base ideal para implementar servicios ficticios en entornos efímeros. Los entornos efímeros ofrecen una manera rentable de simular condiciones de producción para las pruebas. Puede validar las interacciones y los comportamientos sin la sobrecarga de mantener entornos de producción completos para cada escenario de prueba. Estos entornos a petición se crean con fines de prueba específicos y se destruyen después del uso, lo que reduce los costos de infraestructura al tiempo que se mantiene la calidad de las pruebas.

La creación de entornos efímeros requiere que la carga de trabajo alcance un nivel de madurez más alto, donde la automatización con infraestructura como código (IaC) y las canalizaciones de implementación están bien establecidas.

Facilitación con Azure

Azure Test Plans es una solución de administración de pruebas basada en explorador que proporciona todas las funcionalidades necesarias para las pruebas manuales planeadas, las pruebas de aceptación de usuarios, las pruebas exploratorias y la recopilación de comentarios de las partes interesadas. Incluye Análisis de pruebas para realizar un seguimiento de la calidad de las pruebas a lo largo del tiempo e identificar áreas para mejorar.

Azure Pipelines le permite integrar las pruebas en su canalización de CI/CD. También puede usar Acciones de GitHub integradas con Azure.

Pruebas de aplicaciones de Azure es un servicio que admite pruebas funcionales y de rendimiento. Permite ejecutar pruebas funcionales con áreas de trabajo de Playwright y pruebas de rendimiento mediante Azure Load Testing.

Los entornos de implementación de Azure pueden ayudar a poner en marcha la infraestructura de aplicaciones con plantillas basadas en proyectos que establecen coherencia y procedimientos recomendados al tiempo que maximizan la seguridad.

Azure también proporciona herramientas nativas de la plataforma que admiten pruebas de confiabilidad, rendimiento y seguridad.

Vínculos relacionados

• Recomendaciones para pruebas de rendimiento
• Recomendaciones para pruebas de confiabilidad
• Recomendaciones para pruebas de seguridad

Lista de comprobación de la excelencia operativa

Consulte el conjunto completo de recomendaciones.