X
BLOG

¿Qué son las pruebas continuas y cómo incorporarlas a su organización?

¿Qué son las pruebas continuas y cómo incorporarlas a su organización? Tiempo de leer: 7 minutos
Las empresas se centran cada vez más en la experiencia del cliente como parte de su estrategia de comercialización, y una pieza clave de la experiencia del cliente es su capacidad para recorrer su software de forma rápida y sin problemas.

Para reducir los riesgos de una mala experiencia del cliente, las organizaciones están duplicando sus iniciativas de calidad y la industria del desarrollo de software está adoptando las pruebas continuas como una actividad principal.

¿Qué son las pruebas continuas?

Las pruebas continuas son un principio de las pruebas de software, en el que todas sus pruebas se ejecutan todo el tiempo, proporcionando información continua sobre la calidad y el estado de sus aplicaciones. Pero para lograr pruebas continuas, las organizaciones primero deben adoptar la automatización de pruebas. Hay muchos tipos de automatización de pruebas, que abarcan la amplitud de una aplicación, comenzando en la capa de interfaz de usuario, pasando por los sistemas de middleware e incluso los sistemas de back-end. Comprender cómo incorporar estos diferentes tipos de prácticas de automatización de pruebas de la manera más eficiente posible le permite avanzar hacia el camino de las pruebas continuas.

Creación de la estrategia de automatización de pruebas adecuada

El ahora ampliamente aceptado pirámide de prueba (popularizado por Michael Cohen y Martin Fowler) identifica la estrategia óptima para los diferentes tipos de actividades de prueba. En la base, que representa la mayor cantidad de pruebas, queremos establecer una amplia cobertura de pruebas unitarias y de API, que son más fáciles de ejecutar en la automatización, pero que a menudo requieren habilidades técnicas para su construcción. Al llegar a la cima de la pirámide de pruebas, encontrará pruebas de IU automatizadas y pruebas manuales. Queremos este tipo de actividad de prueba en la parte superior porque es la única forma de garantizar la experiencia del cliente.

La mayoría de las personas se concentran en la parte inferior y superior de la pirámide de pruebas con una "Automatizar lo que es manual" enfoque para las pruebas de IU y un "Los desarrolladores deberían probar" mentalidad para las pruebas unitarias. Si bien estas prácticas son importantes, centrarse en la parte superior e inferior crea un espacio en el medio, en la capa de API, entre la interfaz de usuario y el código. Pero esta brecha solo continuará volviéndose cada vez más problemática, con un encuesta reciente de Programmable Web prediciendo más de 22,000 API disponibles públicamente para 2021. Las pruebas de API son más críticas que nunca, deben convertirse en una parte integrada de la estrategia de pruebas continuas que está creando.

Tres pasos para habilitar las pruebas continuas con la automatización de pruebas

discutido previamente cómo elegir la mejor solución de prueba de API para las necesidades únicas de su organización, destacando las características clave que podría necesitar según su industria y aplicación. Es útil comenzar con una solución de prueba de API que pueda crecer con usted a medida que crece la madurez de sus pruebas de API. Una vez que haya elegido una herramienta, ¿cómo empezar? Estos son los tres pasos críticos para lograr la automatización de pruebas funcionales más rápido y permitir sus pruebas continuas.

Paso 1: establezca una amplia cobertura de prueba de sus API existentes para la automatización

Para crear un amplio conjunto de pruebas automatizadas, puede crear pruebas sin script a partir de grabaciones web y contratos de API, y luego usar esas pruebas para validar continuamente el estado de sus API, asegurando que las API estén funcionando como fueron diseñadas. Piense en esto como una prueba unitaria para API, pero sin el trabajo pesado; no solo es una técnica de prueba valiosa, sino que también es uno de los primeros tipos de validación de prueba funcional que puede hacer porque los contratos de servicio para API suelen ser una de las primeras cosas que se escriben, a medida que se crean nuevas características o funcionalidades.

Como ejemplo, digamos que el equipo ha agregado alguna funcionalidad nueva en nuestro aplicación bancaria. Como primer paso, el equipo de desarrollo ha publicado un nuevo definición de servicio. En este caso, se generó un documento de arrogancia. El nuevo servicio que se estaba agregando era el servicio RequestLoan. Este servicio toma una serie de insumos y responde con un prestamista para el nuevo préstamo. Para probar este servicio, podría consumir el Swagger YAMLy crear una serie de clientes para cada operación individual.

Uno de esos clientes sería el servicio de solicitud de préstamo. Podría crear una serie de entradas, tanto positivas como negativas, para validar que el servicio se comportó adecuadamente. Luego podría reutilizar estas pruebas con fines de regresión.

Por supuesto, si bien este tipo de prueba es extremadamente valioso, es solo la mitad del acertijo de prueba de API porque no valida cómo se utilizan realmente las API. Ingrese al paso 2.

Paso 2: cerrar la brecha entre la interfaz de usuario y la API

La segunda parte de la estrategia de prueba de API es poder modelar el uso humano de su aplicación en escenarios completos de prueba de API. Puede comenzar a cerrar esa brecha en la pirámide de pruebas aprovechando inteligencia artificial para aumentar su capacidad de comprender lo que realmente sucede detrás de escena cuando los usuarios navegan por su aplicación e interpretar esas transacciones detrás de escena como llamadas a la API. Este tipo de prueba le permite alinear la experiencia del usuario con sus pruebas API críticas.

La IA es un componente clave de la estrategia porque podemos utilizar IA de forma fiable para ayudarnos a dividir estas comunicaciones en relaciones y patrones, para comprender las reglas comerciales de cómo se prueban nuestras aplicaciones. Podemos unir esto con nuestras pruebas de API a nivel de unidad para obtener una amplia cobertura de nuestro espectro de API.

Continuando con mi ejemplo anterior, notará que el servicio de solicitud de préstamo requiere aportaciones de otras áreas de mi aplicación. Específicamente:

Ahora, aunque podría proporcionar customerID y accountAccountID de forma arbitraria, realmente necesito que existan en mi aplicación. Por lo tanto, necesitaré crear un escenario dinámico en el que primero consulto al usuario individual para obtener la identificación del cliente y la identificación de la cuenta para poder entregar esa información al servicio de solicitud de préstamo y asegurarme de que un escenario dinámico funcione como se describe. Asegurarme de que estoy trabajando con datos dinámicos reales garantiza que ese comportamiento que existe como resultado de las API que interactúan entre sí se pueda desarrollar.

Este tipo de técnicas nos permitirán cambiar a la izquierda la práctica de prueba de API y crear una amplia cobertura de nuestras aplicaciones en las etapas más tempranas posibles. Una vez logrado, hay un tercer componente crítico de esta práctica, que se trata de nuestra capacidad para comprender y adaptarnos al cambio.

Paso 3: garantizar la confianza a través de un proceso de gestión de cambios mantenible

He hablado con mucha gente sobre su iniciativa de pruebas funcionales que fracasó una vez que cambió su aplicación. Esta es una ocurrencia común porque los evaluadores pasan la mayor parte de su tiempo creando pruebas de API excelentes y ricas, solo para que se rompan cuando cambian las API de la aplicación. Esto puede tener el efecto acumulativo de reducir la confianza en la estrategia de prueba de API porque los evaluadores dedican una gran parte de su tiempo a mantener sus pruebas de API en lugar de generar valor nuevo.

La gestión del cambio es una pieza clave de cualquier estrategia de prueba funcional, y la IA también puede ser un habilitador crítico aquí. Al escanear automáticamente las definiciones de servicio (sí, las mismas definiciones de servicio que se usaron para crear inicialmente los casos de prueba) para identificar cuándo han cambiado sus API, puede comprender cuándo se verá afectado y luego crear una plantilla para migrar los servicios existentes a los nuevos. versión.

Volviendo a la primera parte de nuestro ejemplo de aplicación bancaria, hice la declaración de que se agregó un nuevo servicio a mi aplicación. En realidad, esto representa un cambio de API. Desde que creé la primera ronda de pruebas de referencia utilizando la definición del servicio, ahora puedo comparar las diferentes versiones de la definición del servicio entre sí, no solo para identificar lo que ha cambiado sino para construir un mapa para actualizar mis casos de prueba existentes:

Al revisar la plantilla de cambios, es fácil ver que no solo se ha agregado un nuevo servicio, sino que también se han refactorizado muchos de mis servicios existentes. En la imagen de arriba notarás que conseguir clientes tiene una serie de nuevos campos que se han agregado. Con un flujo de trabajo de gestión de cambios, puede identificar de forma proactiva los cambios en el servicio y, al mismo tiempo, gestionar la actualización de los casos de prueba existentes, de modo que pueda recuperarse del cambio lo más rápido posible.

Esta es posiblemente la práctica más importante que uno debe establecer al construir su estrategia de pruebas funcionales, y tener una comprensión y un compromiso con la calidad desde el principio le ayudará a usted y a su organización a adoptar esta práctica.

¿Qué pasa con los entornos de prueba inestables?

Por lo tanto, sería fácil detenerse allí, con su excelente automatización de pruebas que permite realizar pruebas continuas. Pero supongamos que ha dedicado una buena cantidad de tiempo a la construcción de esta estrategia de prueba funcional rica y poderosa, ejecuta sus pruebas en su entorno como parte de su proceso de prueba continuo nocturno automatizado y, al revisar los resultados, ve que una gran parte de sus pruebas han fallado debido a un sistema que está fuera de su control. ¿Significa esto que sus pruebas fueron malas? ¿Se le responsabiliza ahora de los sistemas que técnicamente están fuera del alcance de sus pruebas?

Esta no es una historia infrecuente. Lo sabemos Las pruebas funcionales solo pueden ser tan efectivas como los entornos de prueba en los que se ejecutan.. Los entornos de prueba inestables, no disponibles o simplemente inestables pueden reducir el retorno de la inversión que obtenemos de nuestras herramientas de prueba funcionales. Así que debo, al menos brevemente, mencionar una de las mejores formas de estabilizar sus entornos de prueba, y es: virtualización de servicios.

No confundir con máquinas virtuales (eso es hardware virtualización), la virtualización de servicios le permite simular realmente los servicios que se comunican entre diferentes piezas de hardware. Por ejemplo, piense en una aplicación que llama a una base de datos. ¿Realmente necesita esa base de datos en su entorno de prueba?¿Qué pasa si no tiene los datos que necesita? Con la virtualización de servicios, puede registrar las transacciones con la base de datos y luego usar ese registro para crear una versión simulada de esa base de datos, con todo el comportamiento que desee para su entorno de prueba. Pero, por supuesto, no se limita solo a las bases de datos, puede ser cualquier tipo de servicio, como una API SOAP o REST, incluso TCP y microservicios.

Como parte de la creación de una estrategia de prueba de API sostenible, deberá crear una estrategia de virtualización de servicios sostenible, y eso comienza respondiendo preguntas como:

  • ¿Qué servicios son buenos candidatos para la virtualización?
  • ¿Cómo se crean los servicios virtuales?
  • ¿Cómo puedo mantener un entorno virtual?
  • ¿Cómo puedo implementar un entorno virtual como parte de mi estrategia de prueba continua?

La virtualización de servicios es un habilitador clave para una estrategia de prueba continua sostenible, pero la comprensión donde y cuando traerlo y cómo ser lo más eficaz posible es clave para el éxito.

¿Ahora que?

Entonces, ahora que comprende mejor cómo integrar las pruebas de API como parte de su estrategia de prueba continua, ¡el siguiente paso es ponerse en marcha! Comprometerse con un Herramienta de prueba de API proveedor y comience con el paso uno. Comprender el objetivo final al comenzar lo ayudará a tomar decisiones inteligentes a lo largo del camino. ¡Feliz prueba continua!

Cómo elegir la solución de prueba de API adecuada

Escrito por

Chris Colosimo

Como Gerente de Producto en Parasoft, Chris elabora estrategias para el desarrollo de productos de las soluciones de pruebas funcionales de Parasoft. Su experiencia en la aceleración de SDLC a través de la automatización lo ha llevado a implementaciones empresariales importantes, como Capital One y CareFirst.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft