Tres obstáculos para las pruebas continuas y cómo eliminarlos

Las pruebas continuas son un proceso que permite a los equipos incorporar calidad en el desarrollo de software y acelerar la entrega de experiencias de alta calidad para los clientes. Con las pruebas continuas, los equipos obtienen comentarios instantáneos sobre el estado del código mediante pruebas automatizadas.

Las pruebas continuas permiten a las organizaciones evaluar el riesgo empresarial. Las encuestas recientes de la industria muestran las principales métricas utilizadas para rastrear el progreso y el éxito del proyecto:

• Cobertura de prueba alta
• Mayor corrección de defectos
• Disminución de defectos en la producción.

Construyendo calidad en el proceso de desarrollo

La calidad es un tema importante para los niveles directivos superiores. A continuación, se muestran algunos hallazgos interesantes de los líderes empresariales encuestados:

• El 48% dijo que la mejora de la calidad estaba entre sus tres iniciativas principales.
• El 68% buscaba formas de mejorar la velocidad y la calidad de la entrega.

¿El nuevo objetivo? Incorpore calidad en el proceso de desarrollo para acelerar la entrega de experiencias de cliente de alta calidad.

¿Cómo se consigue esta combinación de velocidad y calidad? Pruebas continuas. Pero viene con sus desafíos.

Superar los obstáculos de las pruebas continuas

Con la calidad a gran velocidad como objetivo, normalmente hay tres obstáculos principales que superar al implementar pruebas continuas.

• Falta de pericia. El equipo puede carecer de disponibilidad para adoptar nuevos enfoques y habilidades necesarias para aprender y adoptar nuevas herramientas y técnicas.
• Ejecución inestable. La automatización de pruebas tal como está actualmente en la organización puede ser inestable y poco confiable. A medida que el código crece, también lo hace el tiempo de ejecución.
• Entorno no disponible. El entorno de prueba a menudo no está disponible, es incontrolable y está limitado por dependencias del sistema.

Los equipos deben eliminar estos obstáculos para que las pruebas continuas se arraiguen en la cultura de desarrollo de una organización de software.

Obstáculo 1: falta de experiencia en el equipo

Inicialmente, la falta de experiencia no es solo la falta de conocimientos y habilidades del equipo. También son las limitaciones de las herramientas que se utilizan.

Considere la automatización de pruebas de interfaz de usuario (UI). Es una práctica común y confiable, pero la automatización reutilizable es difícil. El selenio es el estándar de facto. Si bien es de código abierto y gratuito, tiene su propia curva de adopción, y se necesita experiencia y tiempo para dominarlo.

Las pruebas de selenio pueden no ser fiables y lo que se registra un día no se puede reproducir al siguiente. El mantenimiento de las pruebas se convierte en un problema creciente a medida que se automatizan más pruebas de IU. El selenio requiere más herramientas de soporte para que sea más fácil de usar y mantener.

Pruebas de nivel de servicio o API es una práctica relativamente nueva, pero valiosa. Sin embargo, se encuentra en tierra de nadie entre desarrolladores y evaluadores. Los desarrolladores son los que mejor entienden las API, pero no están motivados ni obligados a probarlas y los evaluadores carecen del conocimiento necesario para realizar pruebas de API.

El desafío número uno cuando las organizaciones intentan adoptar las pruebas de API es comprender cómo se utilizan realmente las API. Esto no quiere decir que las API no estén bien documentadas o diseñadas. Más bien, no hay mucha información sobre cómo se usan los servicios juntos en un caso de uso, flujo de trabajo o escenario.

Además, es importante que la automatización de las pruebas de API vaya más allá de la grabación (durante la operación) y la reproducción (para las pruebas). Es necesario modelar el comportamiento y las interacciones entre las API, así como utilizar estas interacciones para dirigir los procesos de creación y gestión de pruebas.

Las pruebas de rendimiento a menudo se ven como algo que realiza otro equipo de la organización, tal vez como un elemento de casilla de verificación. Pero cuando surgen problemas de rendimiento, es posible que el desarrollo de productos haya avanzado y que se requiera una reversión disruptiva.

Idealmente, las pruebas de rendimiento deben realizarse antes en el proceso de desarrollo de software y aprovechar el trabajo que ya se está realizando con las pruebas funcionales automatizadas. Al mismo tiempo, el equipo está adoptando las pruebas de API, pueden aprovechar ese trabajo para permitir que las pruebas de rendimiento se desplacen a la izquierda, convirtiéndolas en una responsabilidad conjunta de desarrolladores y evaluadores.

Cómo quitar: Simplify Test Automation

La falta de experiencia y capacitación en el equipo de desarrollo y prueba no debe reflejarse en el equipo en sí, sino más bien en la complejidad al adoptar la automatización de pruebas y las herramientas asociadas. Hay soluciones disponibles que se esfuerzan por simplificar la automatización de pruebas. Estas soluciones hacen que la adopción sea menos disruptiva y se integran mejor en los procesos existentes.

Cree scripts de prueba reutilizables, fáciles de mantener y comprensibles. Parasoft Selenic resuelve los principales problemas con la adopción de Selenium: creación y mantenimiento de pruebas. Al registrar las interacciones de la IU a través del navegador Chrome, los casos de prueba de Selenium se crean automáticamente en función de estas interacciones. Además, los localizadores se registran utilizando el modelo de objetos de página para que sean más resistentes a los cambios en la interfaz de usuario. Selenic utiliza la autocuración de pruebas impulsada por IA para que cuando los cambios en la interfaz de usuario rompan las pruebas existentes, la herramienta hace suposiciones inteligentes para evitar que los casos de prueba fallen.

Modele escenarios de prueba de API del mundo real mediante el registro de interacciones de IU manuales y automatizadas. La adopción de pruebas de API se ve obstaculizada por la capacidad de crear pruebas. Parasoft SOAtest utiliza pruebas de IU existentes (incluidas las pruebas creadas por Selenic) para registrar la interacción de la API durante la ejecución de la aplicación. AI dentro de SOAtest organiza estas interacciones registradas en escenarios reconocibles que luego forman la base de un repositorio de prueba API. Estos escenarios de API se pueden reproducir, editar, clonar y reutilizar para formar un conjunto completo de pruebas de API. La automatización y con inteligencia artificial toma de decisiones SOAtest hace que las pruebas de API sean más fáciles de adoptar, usar y mantener. Además, ayuda a cerrar la brecha de conocimientos sobre pruebas de API en el equipo de desarrollo.

Reutilice los artefactos de prueba existentes para escalar de manera eficiente las pruebas de carga, rendimiento y seguridad como parte de Prueba DevOps tubería. A medida que el equipo de desarrollo se vuelve más competente en la automatización de pruebas para los niveles de interfaz de usuario y API, el repositorio de pruebas se convierte en un importante recurso reutilizable. Las pruebas se pueden reutilizar para pruebas de carga y rendimiento y para aumentar la cobertura de código y casos de uso.

Obstáculo 2: la ejecución de las pruebas es inestable, poco fiable y tarda demasiado en ejecutarse

Es comprensible que las organizaciones de software esperen que las pruebas automatizadas sean eficientes y no impidan el progreso del desarrollo. Sin embargo, a medida que crecen las suites de prueba, también aumentan los problemas para mantenerlas y ejecutarlas. Las pruebas, como el código, se ven afectadas por los cambios. La nueva funcionalidad agregada durante un sprint puede afectar significativamente la interfaz de usuario o los flujos de trabajo de la aplicación. Estos cambios rompen las pruebas existentes, haciéndolas inestables. Es importante abordarlos lo más rápido posible.

Cuando las pruebas fallan, debe comprender el contexto de la falla. No todos los fallos de las pruebas son iguales. Algunos casos de uso son más importantes que otros o, quizás, algunas pruebas son inestables por naturaleza. Lo que falta es una comprensión del impacto de las fallas o inestabilidades de las pruebas en las prioridades comerciales de la aplicación. La investigación de estas constantes fallas en las pruebas se convierte en una distracción de la estrategia general de automatización de pruebas. La correlación entre los requisitos comerciales y las pruebas es fundamental para garantizar que se materialice el valor de la automatización.

Otro obstáculo es el tiempo de ejecución real de las suites de prueba. A medida que crece la cartera de pruebas, también lo hace el tiempo de ejecución más allá de un período de espera razonable para recibir comentarios. La retroalimentación rápida para el cambio es esencial para una canalización de CI / CD exitosa, por lo que se requiere la eficiencia y el enfoque de las pruebas.

Cómo eliminar: ejecución de prueba impulsada por IA

La solución al obstáculo de la ejecución de la prueba es realizar pruebas más inteligentes con IA. Esto significa aprovechar la IA de automatización de pruebas para hacer que las pruebas sean más resistentes a los cambios y apuntar a la ejecución solo en pruebas clave.

Pruebas inteligentes de UI con Selenium y Selenic. Usando IA, Parasoft Selénic pruebas de autocuración cuando se detectan cambios en la IU. Estos se utilizan automáticamente, pero se envían recomendaciones al desarrollador para ayudar a corregir las pruebas. Estas correcciones se pueden aplicar automáticamente a las pruebas de Selenium, eliminando la depuración manual y los cambios de código.

Planifique las pruebas de los elementos de trabajo en función de los requisitos afectados. Para priorizar las actividades de prueba, se requiere la correlación de las pruebas con los requisitos comerciales. El seguimiento de las historias de los usuarios y los requisitos proporciona visibilidad en tiempo real de la calidad del flujo de valor. Las historias de usuarios y los requisitos deben revisarse para dar prioridad. Las capacidades de trazabilidad en Prueba SOA de Parasoft se utilizan para planificar la ejecución de las pruebas que validan los elementos en los que se trabaja en el sprint. Sin embargo, se requiere más, ya que no está claro cómo los cambios recientes han afectado el código.

Utilice el análisis de impacto de prueba para validar solo lo que ha cambiado. Para optimizar completamente la ejecución de la prueba, es necesario comprender el código que cubre cada prueba y luego determinar el código que ha cambiado. Las herramientas de Parasoft brindan esta capacidad a través de un repositorio central para los resultados de las pruebas y el análisis. El análisis de impacto de las pruebas permite a los evaluadores centrarse solo en las pruebas que validan los cambios.

Obstáculo 3: el entorno de prueba no está disponible, es incontrolable y está restringido por las dependencias del sistema

El entorno de prueba es el eje de los obstáculos que impiden que las organizaciones se conviertan en pruebas continuas de forma automatizada. Hay tres tipos de desafíos a los que se enfrentan las organizaciones cuando intentan hacer que las pruebas se ejecuten en cualquier momento y en cualquier lugar y se ocupan de las dependencias externas de la aplicación. Esto es especialmente cierto para una arquitectura de microservicios. El número de dependencias se dispara debido a la propia naturaleza del diseño.

Desafíos del entorno de prueba

Esperando acceso a un sistema compartido, como un mainframe o una dependencia externa proporcionada por un tercero. La disponibilidad puede ser costosa y limitada en el tiempo. También es un desafío si la dependencia externa está muy cargada con varias personas trabajando en ella al mismo tiempo, lo que resulta en inestabilidad de prueba debido a colisiones de datos.

Cuellos de botella causados ​​por el acceso retrasado. Esto se debe a la naturaleza del desarrollo paralelo y típico de los procesos modernos. Por ejemplo, varios equipos están colaborando para ofrecer nuevas funciones al flujo de valor, como microservicios interdependientes. Las pruebas no pueden continuar en un microservicio porque todavía no hay otro disponible.

Datos de prueba incontrolables. Aunque los microservicios son relativamente fáciles de implementar y probar de forma aislada, su dependencia de los datos o las características de rendimiento limitan la capacidad de los mismos para ser probados a fondo. Por ejemplo, la dependencia de los datos de una base de datos de producción compartida puede limitar la capacidad de probar los servicios.

Cómo quitar: controlar el entorno de prueba

Comience a simular estas dependencias para darle al equipo un control total mediante una solución de virtualización de servicios. Virtualización de Parasoft simula servicios que están fuera de su control o que no están disponibles. Proporciona flujos de trabajo que:

• Permita que los usuarios accedan a entornos de prueba completos y realistas.
• Estabilice su entorno de prueba.
• Obtenga acceso a dependencias que de otro modo serían inaccesibles.
• Gestione la lógica empresarial compleja, los datos de prueba y las características de rendimiento necesarias para que los servicios virtuales se comporten como servicios reales en el entorno real que representan.

La virtualización de servicios elimina los cuellos de botella. Así es cómo.

Grabe y simule: capture, modele y proporcione simulaciones de sistemas en vivo.

Usando la capacidad de grabación de Parasoft SOAtest, es posible capturar el comportamiento de la aplicación en su entorno. Parasoft Virtualize modela el comportamiento de las dependencias externas haciendo posible eliminar y simular el comportamiento de las dependencias, dinámicamente sobre la marcha, cambiando entre lo real y lo virtual. Hacer que estos servicios y dependencias estén disponibles y estables, virtualmente, acelera el proceso de prueba y permite realizar pruebas continuas.

Entregue un prototipo primero: comportamiento del modelo basado en descripciones de contratos o ejemplos de carga útil.

La virtualización de servicios permite el desarrollo de prototipos basados ​​en las descripciones del contrato derivadas de los registros y análisis de interacción API en SOAtest.

Los servicios dependientes se pueden simular con buena fidelidad para crear versiones prototipo que satisfagan sus roles en el sistema al probar otro servicio adyacente. Esto elimina la limitación de programación inherente al desarrollo paralelo; incluso cuando los servicios no están completos, se pueden virtualizar para probar otros servicios.

Sintetice datos de prueba privados.

Otro obstáculo para probar aplicaciones empresariales son los datos de prueba. Muchas organizaciones usan datos reales, pero esto está plagado de problemas de privacidad. Los datos puramente sintéticos a menudo no son lo suficientemente realistas para probarlos, por lo que se necesita un compromiso. Sintetizar datos reales mediante la eliminación de información de identificación personal (PII) proporciona datos realistas y seguros de usar. La gestión de datos de prueba es necesaria junto con la virtualización de servicios para proporcionar un entorno de prueba realista y de alta disponibilidad que no resulte en ningún compromiso de privacidad.

Los beneficios de las pruebas continuas

La eliminación de los obstáculos clave para las pruebas continuas permite que las pruebas se realicen en un horario regular y predecible. Transforma las pruebas de aplicaciones que permiten a los equipos:

• Prueba antes. Cambie a la izquierda a las pruebas in-sprint, donde es más rápido, más barato y más fácil solucionar el problema.
• Prueba más rápido. Automatice y ejecute continuamente para obtener retroalimentación inmediata cuando se introduzcan defectos.
• Prueba menos. Concéntrese y dedique menos tiempo a crear, mantener y ejecutar escenarios de prueba. Reducir el costo de la infraestructura de prueba.