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.

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: Para un sistema de compra de comercio electrónico, la estrategia de prueba establece un enfoque coherente en todas las versiones. Define que los flujos de pago siempre tienen prioridad, especifica herramientas de prueba para el sistema, como Selenium para pruebas de IU, JMeter para pruebas de carga y ZAP de OWASP para pruebas de seguridad y aclara las responsabilidades del equipo para diferentes tipos de prueba. El plan de prueba de la versión v2.5 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, cero errores críticos y un Acuerdo de Nivel de Servicio de dos segundos).

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 las pruebas de producción. Esta forma de hacer cosas le permite recopilar comentarios reales del usuario y datos de rendimiento, a la vez que minimiza las interrupciones en la base de usuarios más amplia.

Considere estrategias de exposición progresivas, como los deployamientos de prueba, solo después de que el volumen de trabajo cumpla con 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.

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. 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.

La ejecución de pruebas de humo de aplicaciones puede revelar problemas de infraestructura como errores de red, configuraciones incorrectas de DNS o restricciones de recursos antes de que afecten a la producción. Por ejemplo, una prueba de humo que valida los puntos finales de estado de API puede detectar rápidamente problemas de aprovisionamiento de infraestructura o problemas de políticas de red.

Con este enfoque, las pruebas específicas de la aplicación identifican y resuelven de forma proactiva los problemas de infraestructura, lo que reduce la necesidad de validación de infraestructura independiente. Ofrece confianza en que el código y la infraestructura subyacente funcionan correctamente.

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.

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.

Evalúe cada característica o cambio en función del impacto empresarial y el riesgo. Priorice los tipos de prueba en función de esta evaluación. 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. Cuando sea posible, mantenga las pruebas junto con el código en el mismo repositorio para simplificar el mantenimiento y promover la coherencia.

Si el conjunto de automatización reside en un repositorio independiente, implemente controles de gobernanza equivalentes, como revisiones de código obligatorias, políticas de solicitudes de incorporación de cambios y canalizaciones de validación de compilación para mantener los estándares de calidad.

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. Implemente prácticas de codificación seguras en el código de prueba para evitar vulnerabilidades. Trate las pruebas con los mismos estándares de seguridad que el código de producción.

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 prácticas que garantizan la independencia y confiabilidad de las pruebas, como aislar los datos de prueba, evitar el estado compartido e implementar los procesos adecuados de configuración y desmontaje. Implemente la limpieza automatizada de los datos de prueba. 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.

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. Use los mismos principios arquitectónicos para el diseño de prueba que para el código de producción.

El conjunto de pruebas de regresión debe contener las pruebas más valiosas y estables. Comience en pequeño y aumente deliberadamente la suite de regresión. 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.

Los casos de prueba capturan la intención, el ámbito y los resultados esperados. Mantener los scripts de automatización de pruebas y los casos de prueba sincronizados es esencial. 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.

Administración de deudas técnicas de prueba

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. Al identificar pruebas no confiables, priorice la corrección o eliminación de ellas 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.

Las decisiones estratégicas sobre la omisión o aplazamiento de pruebas son tan importantes como lo que se prueba. 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 logra dos objetivos clave: asegurarse de que el marco de pruebas funciona de forma confiable y ofrece visibilidad continua sobre la calidad y el estado de la carga de trabajo. Al integrar prácticas de observabilidad en el marco de pruebas, refuerza las funcionalidades de diagnóstico, facilita la supervisión en tiempo real de la estabilidad e impulsa la mejora continua de los procesos de prueba.

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 se vuelven poco confiables, pierden relevancia o no pueden mantenerse al día con los cambios de la 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. La generación de informes de cobertura facilita la identificación de 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.

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

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.

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 para que los entornos de producción reflejen 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, los casos en los que las pruebas se realizan correctamente en entornos inferiores, pero no se producen errores en producción. Apunte a mantener la coherencia en todos los entornos mientras el código avanza a través del pipeline. 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.

Al reflejar los entornos en producción, el desfase de configuración puede crear una confianza falsa en la calidad. Evite esto mediante la implementación de 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.