{"id":13396,"date":"2022-11-09T08:00:00","date_gmt":"2022-11-09T11:00:00","guid":{"rendered":"https:\/\/cl.abstracta.us\/blog\/?p=13396"},"modified":"2024-02-15T17:02:07","modified_gmt":"2024-02-15T20:02:07","slug":"testing-performance-integracion-continua","status":"publish","type":"post","link":"https:\/\/es.abstracta.us\/blog\/testing-performance-integracion-continua\/","title":{"rendered":"La mejor forma de hacer testing de performance en integraci\u00f3n continua"},"content":{"rendered":"\n

\u00bfCu\u00e1les son las ventajas del Continuous Performance Testing? \u00bfPor qu\u00e9 es tan importante lograr un pipeline de CI eficiente? <\/strong>Desc\u00fabrelo en el segundo art\u00edculo de nuestra saga denominada \u201cTesting de Performance a fondo\u201d.<\/h3>\n\n\n
\n
\"\"
Foto de Burak The Weekender<\/em><\/figcaption><\/figure><\/div>\n\n\n

Creemos que un pipeline de integraci\u00f3n continua eficiente es la clave para crear software de calidad y seguir siendo competitivos en el panorama tecnol\u00f3gico actual. \u00bfPor qu\u00e9? La respuesta es simple: porque la integraci\u00f3n continua permite probar las ideas m\u00e1s r\u00e1pidamente. De este modo, evita problemas de regresi\u00f3n, agiliza la entrega de software y, as\u00ed, logra aportar valor antes a los usuarios.<\/strong><\/p>\n\n\n\n

Para comprender mejor c\u00f3mo es posible esto, es importante explicar qu\u00e9 es la integraci\u00f3n continua<\/strong>. Se trata de una pr\u00e1ctica que permite integrar continuamente (idealmente a cada hora o cada d\u00eda) las funcionalidades y los cambios de forma eficiente mediante la automatizaci\u00f3n de pruebas que verifiquen el buen funcionamiento del software despu\u00e9s de cada cambio.<\/p>\n\n\n\n

Para poder figurarlo, se puede decir que lo contrario ser\u00eda integrar solo en momentos concretos grandes caracter\u00edsticas o m\u00f3dulos completos; probar la integraci\u00f3n, normalmente a trav\u00e9s de alg\u00fan proceso manual o semimanual; y reci\u00e9n despu\u00e9s de eso proceder a solucionar cualquier problema potencial.<\/p>\n\n\n\n

Las herramientas de integraci\u00f3n continua permiten definir una secuencia de tareas a realizar de forma autom\u00e1tica y alcanzar el m\u00e1ximo nivel de madurez de las pruebas seg\u00fan nuestro modelo de madurez. Sin dudas, el Continuous Performance Testing forma parte del n\u00facleo de este camino.<\/strong><\/p>\n\n\n\n

Los equipos deben ser capaces de detectar cualquier error lo antes posible. Pr\u00e1cticas como el Continuous Performance Testing van de la mano de la integraci\u00f3n continua (CI), y cobran especial importancia en los equipos \u00e1giles.<\/strong><\/p>\n\n\n\n

Son un pilar fundamental para tener p\u00e1ginas 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\u00e9s del tiempo, con la introducci\u00f3n de nuevas funcionalidades.<\/p>\n\n\n\n

En este art\u00edculo, nos centraremos en los beneficios del Continuous Performance Testing<\/strong> y en c\u00f3mo lo abordamos en Abstracta. Entrevistamos a Andr\u00e9i Guchin, ingeniero de Performance y l\u00edder del Hub de Performance en Abstracta<\/strong>, con el objetivo de poder dar cuenta de la importancia para avanzar en la madurez de las pruebas<\/a>.<\/p>\n\n\n

\n
\"Andr\u00e9i<\/figure><\/div>\n\n\n

\u00bfQu\u00e9 es el Continuous Performance Testing?<\/strong><\/h2>\n\n\n\n

En l\u00edneas generales, Continuous Performance Testing es el m\u00e9todo para evaluar la calidad de un sistema en lo que respecta a su rendimiento cuando trabajamos con un enfoque de Continuous Integration<\/strong><\/p>\n\n\n\n

Consiste en realizar pruebas continuas, de la misma manera que las que verifican la funcionalidad de la aplicaci\u00f3n, con foco en que la performance de la aplicaci\u00f3n se encuentre dentro de los par\u00e1metros considerados aceptables para dicho sistema. O que al menos no se haya degradado respecto a la versi\u00f3n anterior.<\/p>\n\n\n\n

\u00bfEs la mejor forma de hacer testing?<\/strong><\/h2>\n\n\n\n

Es la mejor forma de hacer testing de performance cuando estamos trabajando en continuous integration, ya que a diferencia de las pruebas de performance \u201ctradicionales\u201d, se enfoca en medir degradaciones en el rendimiento entre una versi\u00f3n del sistema y la anterior<\/strong>, en lugar de obtener resultados para una versi\u00f3n espec\u00edfica que pueden quedar obsoletos r\u00e1pidamente.<\/p>\n\n\n\n

Adem\u00e1s, siguiendo las buenas pr\u00e1cticas de continuous integration, este tipo de testing busca automatizar la ejecuci\u00f3n de pruebas repetitivas que de otra manera deber\u00edan correrse \u201cmanualmente\u201d<\/strong>. Esto permite que el tester pueda enfocarse en tareas m\u00e1s desafiantes o cr\u00edticas que le posibiliten desplegar todo su potencial humano.<\/p>\n\n\n\n

De todos modos, esto no significa que solo haya que hacer Continuous Performance Testing, tambi\u00e9n es necesario realizar testing de software tradicional para los releases importantes, en los cuales haya alg\u00fan cambio grande o que se prevea que pueda llegar a introducir alg\u00fan problema de performance. Todo esto en consideraci\u00f3n de los requerimientos particulares de cada release y de los eventos particulares esperados.<\/p>\n\n\n\n

\u00bfC\u00f3mo incorporar el Testing de performance continuo en el pipeline del desarrollo?<\/strong><\/h2>\n\n\n\n

Antes que nada, es preciso definir la estrategia de testing<\/a> que se va a implementar. Entre otras cosas, es necesario hacer foco en qu\u00e9 funcionalidades se van a probar, qu\u00e9 datos se necesitan, qu\u00e9 carga o qu\u00e9 escenarios se van a ejecutar para cada test, c\u00f3mo y cu\u00e1ndo se van a ejecutar, qu\u00e9 m\u00e9tricas se van a obtener, y c\u00f3mo se van a mostrar los resultados<\/strong>.<\/p>\n\n\n\n

Tambi\u00e9n 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\u00f3modo al utilizarlas.<\/p>\n\n\n\n

Luego, se comienza con la automatizaci\u00f3n de los tests y, a medida que vayan quedando listos se van a ir integrando al pipeline de ejecuci\u00f3n.<\/p>\n\n\n\n

Es importante destacar que todo este proceso que yo lo cuento de manera resumida lleva su tiempo de an\u00e1lisis, de trabajo e idas y vueltas, como todo proyecto. A veces no es tan directo como lo estoy contando y hay que volver atr\u00e1s en algunas decisiones, probar otras opciones o quitar del alcance cosas previamente definidas. A fin de cuentas, m\u00e1s all\u00e1 de intentar seguir una metodolog\u00eda formal de pruebas de performance en CI\/CD<\/strong>, lo importante es lograr adaptar dicha metodolog\u00eda a mis necesidades, o las de mi negocio, e incorporar aquellas pr\u00e1cticas que realmente nos aporten valor.<\/p>\n\n\n\n

\u00bfCu\u00e1les son los beneficios?<\/strong><\/h2>\n\n\n\n

Por un lado, est\u00e1n 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\u00f3n. Esto reduce la probabilidad de que los usuarios se vean impactados por estos problemas, as\u00ed como que la imagen del producto desarrollado y del negocio se vea afectada.<\/p>\n\n\n\n

Por otro lado, tenemos los beneficios espec\u00edficos de realizar este tipo de pruebas con un enfoque CI\/CD<\/strong>: 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\u00e9 trabajando en otra cosa y que le cueste m\u00e1s trabajo hacer foco nuevamente el problema.<\/p>\n\n\n\n

Dentro de los beneficios espec\u00edficos de las pruebas de performance en CI\/CD, tambi\u00e9n permite lograr mayor colaboraci\u00f3n entre desarrolladores y performance testers<\/strong>, siguiendo la l\u00ednea de las metodolog\u00edas \u00e1giles donde se promueven equipos interdisciplinarios, y generar un benchmark de performance para las funcionalidades m\u00e1s cr\u00edticas del sistema.<\/p>\n\n\n\n

\u00bfTiene alguna desventaja?<\/strong><\/h2>\n\n\n\n

Actualmente, la principal desventaja que veo es que este tipo de pruebas no suplanta 100% la prueba de performance \u201ctradicional\u201d. La informaci\u00f3n que brindan los dos enfoques es complementaria una de otra. Luego, est\u00e1 el desaf\u00edo de evaluar si tiene sentido o no ejecutar pruebas de performance \u201ctradicionales\u201d en un esquema CI\/CD, pero esa es una discusi\u00f3n aparte.<\/p>\n\n\n\n

\u00bfEs m\u00e1s caro o m\u00e1s barato?<\/strong><\/h2>\n\n\n\n

La respuesta a esta pregunta es un gran \u201cdepende\u201d. Depende del proyecto, de la empresa, de las demandas de calidad y estabilidad de la aplicaci\u00f3n, de la imagen establecida de la empresa. Depende de la madurez del equipo, de qu\u00e9 tan cr\u00edtico sea para el sistema la calidad a nivel de performance, y de la empresa. Pero sobre todo depende de qu\u00e9 se considere caro y qu\u00e9 barato.<\/p>\n\n\n\n

Para ejemplificar, alguien puede considerar caro en t\u00e9rminos de tiempo y dinero ir al m\u00e9dico peri\u00f3dicamente a hacerse chequeos, pero si no lo hacemos y a la larga nos enfermamos de algo complicado que pod\u00edamos haber prevenido con esas consultas nos termina saliendo muy caro.<\/p>\n\n\n\n

En general en el corto plazo podr\u00eda decirse que es m\u00e1s caro, ya que inicialmente requiere una inversi\u00f3n adecuada. Pero en el largo plazo, implementado adecuadamente, resulta mucho m\u00e1s barato, m\u00e1s redituable.<\/p>\n\n\n\n

\n\n\n\n

\u00bfQuieres saber c\u00f3mo implementar pruebas de performance continuas en tu empresa?<\/strong><\/h3>\n\n\n\n

En Abstracta, podemos ayudarte a mitigar los riesgos asociados al rendimiento de tu sistema, con soluciones que se ajustan a tus necesidades espec\u00edficas. \u00a1Hablemos<\/a>!<\/p>\n\n\n\n

\n\n\n\n

Otros contenidos relacionados<\/h3>\n\n\n\n
\n