¿Cuáles son las ventajas del Continuous Performance Testing? ¿Por qué es tan importante lograr un pipeline de CI eficiente? Descúbrelo en el segundo artículo de nuestra saga denominada “Testing de Performance a fondo”.
Creemos que un pipeline de integración continua eficiente es la clave para crear software de calidad y seguir siendo competitivos en el panorama tecnológico actual. ¿Por qué? La respuesta es simple: porque la integración continua permite probar las ideas más rápidamente. De este modo, evita problemas de regresión, agiliza la entrega de software y, así, logra aportar valor antes a los usuarios.
Para comprender mejor cómo es posible esto, es importante explicar qué es la integración continua. Se trata de una práctica que permite integrar continuamente (idealmente a cada hora o cada día) las funcionalidades y los cambios de forma eficiente mediante la automatización de pruebas que verifiquen el buen funcionamiento del software después de cada cambio.
Para poder figurarlo, se puede decir que lo contrario sería integrar solo en momentos concretos grandes características o módulos completos; probar la integración, normalmente a través de algún proceso manual o semimanual; y recién después de eso proceder a solucionar cualquier problema potencial.
Las herramientas de integración continua permiten definir una secuencia de tareas a realizar de forma automática y alcanzar el máximo nivel de madurez de las pruebas según nuestro modelo de madurez. Sin dudas, el Continuous Performance Testing forma parte del núcleo de este camino.
Los equipos deben ser capaces de detectar cualquier error lo antes posible. Prácticas como el Continuous Performance Testing van de la mano de la integración continua (CI), y cobran especial importancia en los equipos ágiles.
Son un pilar fundamental para tener páginas web y aplicaciones de todo tipo que sean confiables y de alto rendimiento, para estar seguros de que la experiencia de usuario no se deteriore a través del tiempo, con la introducción de nuevas funcionalidades.
En este artículo, nos centraremos en los beneficios del Continuous Performance Testing y en cómo lo abordamos en Abstracta. Entrevistamos a Andréi Guchin, ingeniero de Performance y líder del Hub de Performance en Abstracta, con el objetivo de poder dar cuenta de la importancia para avanzar en la madurez de las pruebas.
¿Qué es el Continuous Performance Testing?
En líneas generales, Continuous Performance Testing es el método para evaluar la calidad de un sistema en lo que respecta a su rendimiento cuando trabajamos con un enfoque de Continuous Integration
Consiste en realizar pruebas continuas, de la misma manera que las que verifican la funcionalidad de la aplicación, con foco en que la performance de la aplicación se encuentre dentro de los parámetros considerados aceptables para dicho sistema. O que al menos no se haya degradado respecto a la versión anterior.
¿Es la mejor forma de hacer testing?
Es la mejor forma de hacer testing de performance cuando estamos trabajando en continuous integration, ya que a diferencia de las pruebas de performance “tradicionales”, se enfoca en medir degradaciones en el rendimiento entre una versión del sistema y la anterior, en lugar de obtener resultados para una versión específica que pueden quedar obsoletos rápidamente.
Además, siguiendo las buenas prácticas de continuous integration, este tipo de testing busca automatizar la ejecución de pruebas repetitivas que de otra manera deberían correrse “manualmente”. Esto permite que el tester pueda enfocarse en tareas más desafiantes o críticas que le posibiliten desplegar todo su potencial humano.
De todos modos, esto no significa que solo haya que hacer Continuous Performance Testing, también es necesario realizar testing de software tradicional para los releases importantes, en los cuales haya algún cambio grande o que se prevea que pueda llegar a introducir algún problema de performance. Todo esto en consideración de los requerimientos particulares de cada release y de los eventos particulares esperados.
¿Cómo incorporar el Testing de performance continuo en el pipeline del desarrollo?
Antes que nada, es preciso definir la estrategia de testing que se va a implementar. Entre otras cosas, es necesario hacer foco en qué funcionalidades se van a probar, qué datos se necesitan, qué carga o qué escenarios se van a ejecutar para cada test, cómo y cuándo se van a ejecutar, qué métricas se van a obtener, y cómo se van a mostrar los resultados.
También hay que elegir el conjunto de herramientas que voy a utilizar, de forma tal que las mismas cumplan con las necesidades del proyecto y que el equipo se sienta cómodo al utilizarlas.
Luego, se comienza con la automatización de los tests y, a medida que vayan quedando listos se van a ir integrando al pipeline de ejecución.
Es importante destacar que todo este proceso que yo lo cuento de manera resumida lleva su tiempo de análisis, de trabajo e idas y vueltas, como todo proyecto. A veces no es tan directo como lo estoy contando y hay que volver atrás en algunas decisiones, probar otras opciones o quitar del alcance cosas previamente definidas. A fin de cuentas, más allá de intentar seguir una metodología formal de pruebas de performance en CI/CD, lo importante es lograr adaptar dicha metodología a mis necesidades, o las de mi negocio, e incorporar aquellas prácticas que realmente nos aporten valor.
¿Cuáles son los beneficios?
Por un lado, están los beneficios generales de las pruebas de performance, como mitigar el riesgo de observar problemas asociados al rendimiento del sistema una vez que es puesto en producción. Esto reduce la probabilidad de que los usuarios se vean impactados por estos problemas, así como que la imagen del producto desarrollado y del negocio se vea afectada.
Por otro lado, tenemos los beneficios específicos de realizar este tipo de pruebas con un enfoque CI/CD: detectar cuanto antes desviaciones en el producto y corregirlas a tiempo. Esto permite reducir el cambio de contexto en los desarrolladores. Cuando se trabaja en sprints, el contexto suele cambiar de un sprint a otro. Si no se detectan los bugs a tiempo, luego cuando el desarrollador tiene que retomar la tarea para corregirlo puede ser que esté trabajando en otra cosa y que le cueste más trabajo hacer foco nuevamente el problema.
Dentro de los beneficios específicos de las pruebas de performance en CI/CD, también permite lograr mayor colaboración entre desarrolladores y performance testers, siguiendo la línea de las metodologías ágiles donde se promueven equipos interdisciplinarios, y generar un benchmark de performance para las funcionalidades más críticas del sistema.
¿Tiene alguna desventaja?
Actualmente, la principal desventaja que veo es que este tipo de pruebas no suplanta 100% la prueba de performance “tradicional”. La información que brindan los dos enfoques es complementaria una de otra. Luego, está el desafío de evaluar si tiene sentido o no ejecutar pruebas de performance “tradicionales” en un esquema CI/CD, pero esa es una discusión aparte.
¿Es más caro o más barato?
La respuesta a esta pregunta es un gran “depende”. Depende del proyecto, de la empresa, de las demandas de calidad y estabilidad de la aplicación, de la imagen establecida de la empresa. Depende de la madurez del equipo, de qué tan crítico sea para el sistema la calidad a nivel de performance, y de la empresa. Pero sobre todo depende de qué se considere caro y qué barato.
Para ejemplificar, alguien puede considerar caro en términos de tiempo y dinero ir al médico periódicamente a hacerse chequeos, pero si no lo hacemos y a la larga nos enfermamos de algo complicado que podíamos haber prevenido con esas consultas nos termina saliendo muy caro.
En general en el corto plazo podría decirse que es más caro, ya que inicialmente requiere una inversión adecuada. Pero en el largo plazo, implementado adecuadamente, resulta mucho más barato, más redituable.
¿Quieres saber cómo implementar pruebas de performance continuas en tu empresa?
En Abstracta, podemos ayudarte a mitigar los riesgos asociados al rendimiento de tu sistema, con soluciones que se ajustan a tus necesidades específicas. ¡Hablemos!
Otros contenidos relacionados
Etiquetas
Posts Relacionados
Historia del WOPR: una mirada desde adentro
¿Cómo nació el “Workshop on Performance and Reliability” (WOPR)? ¿Cuál es la visión que hay detrás? Descubrilo en este artículo, con entrevistas a Eric Proegler y Paul Holland.
¿Qué es el rendimiento en las pruebas de performance?
Las pruebas de performance buscan mejorar la eficacia y preparación de las aplicaciones de software. En el centro de este proceso, encontramos una métrica clave denominada “rendimiento”. Nos adentramos en los matices del rendimiento y su importancia.