Cómo integrar validaciones de la performance de una aplicación móvil en un pipeline de CI/CD

Cuando se trata de crear software de calidad, es esencial entender por qué es importante integrar las validaciones de la performance de una aplicación móvil en un pipeline de CI/CD, y específicamente cómo hacerlo. Descubre en este artículo cómo Apptim, herramienta de mobile performance testing, ayuda en este proceso, y a establecer criterios de aceptación para los KPI más importantes que afectan a la experiencia del usuario, con una entrevista a su CEO, Sofia Palamarchuk.

Apptim: Herramienta para Testing de Performance Mobile

La importancia de la integración continua y la entrega continua en el mundo actual es indiscutible. Gracias a estas prácticas, los profesionales IT son capaces de crear mejor software cada segundo, lo cual resulta crucial en esta era, en la que contar con software de calidad es prioritario para casi todos los ámbitos de la vida. Esto también tiene un profundo impacto en el crecimiento, la sostenibilidad y la escalabilidad de las empresas.

Según el informe CISQ 2020 “The Cost of Poor Software Quality in the US”, el costo total de la mala calidad del software en Estados Unidos fue de 2080 billones de dólares (T) en 2020.

Tal como expresó Roger Abelenda, Chief Technology Officer de Abstracta, “un pipeline de integración continua eficiente es la clave para crear software de calidad y seguir siendo competitivo en el panorama tecnológico actual”. ¿Por qué? Porque permite centrarse en los cambios entregados. Así, proporciona valor a los usuarios antes, probando ideas más rápido, evitando problemas de regresión y agilizando la entrega de software”.

En pocas palabras, cuando se trata de pruebas de software, entender cómo integrar las validaciones de performance de una aplicación móvil en un pipeline de CI/CD es más que relevante. Y Apptim es una herramienta sumamente útil para lograr este objetivo.

¿Cuál es el aporte de Apptim en todo esto?

Apptim ha sido nuestro primer spin-off en Abstracta. Es una solución de pruebas de performance de aplicaciones móviles utilizada por más de 250 empresas en todo el mundo. Una de ellas es Playtika, con sede en Israel y una de las mayores empresas de juegos móviles del mundo.

Como explicó Matías Reina, director general de Abstracta, “Apptim mide la performance del lado del dispositivo en lugar de la performance del lado del servidor como la mayoría de las herramientas. Es cierto que algunas de estas métricas se ven afectadas por el servidor, pero ese no es su enfoque”.

Para entender mejor este punto, Matías ejemplificó que Apptim mide desde que un usuario hace clic en la búsqueda de productos hasta que todos los productos se muestran realmente en la pantalla. “Se trata de dos métodos de procesamiento diferentes, uno en el servidor y otro en el móvil”.

Matías profundizó: “El problema viene cuando se necesita simular una alta demanda, con grandes cantidades de carga y miles de usuarios, y se utilizan herramientas como JMeter en lugar de Apptim. En estos casos, se suele dividir el análisis en dos: scripts/automatización enfocados al servidor (con Jmeter) y scripts/automatización enfocados al cliente (con Apptim)”.

“Por otro lado, el procesamiento del lado del cliente depende mucho del tipo de dispositivo, por lo que es bueno poder medir en diferentes tipos de dispositivos para garantizar que todos los usuarios objetivo tengan una buena experiencia”, continuó.

Con todo esto en mente, está claro que Apptim puede ser un gran aliado a la hora de realizar pruebas de performance en aplicaciones móviles. Pero, ¿cómo automatizar estas validaciones en una aplicación móvil? ¿Y cómo aprovechar todas las ventajas que ofrece Apptim? Hablamos de esto y más con Sofia Palamarchuk, CEO de Apptim.

Sofia Palamarchuk, CEO de Apptim y Partner en Abstracta Inc.

¿Cómo se pueden automatizar las validaciones de performance de una aplicación móvil?

Sofía Palamarchuk: Lo primero que hay que hacer es encontrar una forma de ejecutar un profiling automatizado de la aplicación. La forma más fácil de empezar es reutilizar las pruebas funcionales automatizadas que se han creado para la validación funcional. Estas pruebas se ejecutan a nivel de la interfaz de usuario en una versión del paquete de la aplicación que puede instalarse en un dispositivo real o en un emulador y simular un recorrido real del usuario. Mientras se ejecuta esta prueba, se pueden capturar datos de performance de lo que ocurre “under the hood”.

La mayoría de los equipos de desarrollo de apps ya tienen algún tipo de prueba de interfaz de usuario automatizada en su pipeline de integración continua. Si la aplicación está en fase beta o es nueva en el mercado, puede que estén pensando en añadirlas en un futuro próximo. Este es el mejor momento para pensar en cómo incluir las validaciones de performance en el proceso de lanzamiento de la aplicación.

Para ejemplificar, esto es lo que ocurre en una prueba de Appium que ejecuta un recorrido típico del usuario en una aplicación de comercio electrónico: un usuario busca un producto, selecciona el producto de una lista, lo añade a un carrito, navega hasta el carrito y completa el pago. Esta prueba funcional puede comprobar que se ha añadido el producto correcto al carrito de compras, que la cantidad del producto es correcta o que el proceso de compra funciona de manera esperada.

Al mismo tiempo, podemos validar cuál es el tiempo de respuesta para una acción simple como hacer clic en el botón “añadir al carrito”, así como el uso de memoria si la acción se realiza varias veces. ¿Causará un error OutOfMemory?

Si tu equipo no tiene ninguna prueba funcional automatizada, te recomendamos que automatices un caso de uso pequeño y valioso para empezar a medir la performance a lo largo del tiempo. Por ejemplo, medir el tiempo de inicio de la aplicación la primera vez que se abre o probar la experiencia del usuario en el inicio de sesión.

¿Se deben realizar estas validaciones con emuladores o con dispositivos reales?

Sofía Palamarchuk: Depende. Si lo que más te interesa es comparar o hacer un benchmarking de diferentes métricas de performance de tu aplicación (como la v2.6 frente a la v2.5), deberías tener entornos de prueba lo más parecidos posible. En particular, los dispositivos utilizados para las pruebas deben ser los mismos.

Seguramente, vas a querer minimizar el ruido en los datos que se produce al usar diferentes entornos y observar las diferencias en la performance medida en cada versión. Para ello, los emuladores pueden ser de gran ayuda, ya que puedes especificar la versión de hardware y SO del dispositivo emulado y utilizar el mismo emulador para la evaluación comparativa. También es una alternativa rentable al uso de dispositivos reales si ejecutas benchmarks con frecuencia.

Por otro lado, si lo que quieres es evaluar la experiencia real del usuario, tienes que acercarte lo máximo posible a las condiciones del mundo real. Esto significa realizar pruebas en hardware real. Además de buscar diferencias de rendimiento notables entre una versión de la aplicación y otra, querrás asegurarte de que la performance de la aplicación es aceptable en dispositivos específicos.

Para ello, puedes definir umbrales por dispositivo. Por ejemplo, el uso de la memoria no puede ser superior a 300 MB en un dispositivo específico. O puedes recibir una notificación si los FPS (frames por segundo) son inferiores a 10 en cualquier pantalla (y probablemente fallar el pipeline).

¿Qué criterios de aceptación deberían utilizar los equipos de desarrollo?

Sofía Palamarchuk: Esta es una de las preguntas más comunes que nos hacen y, posiblemente, la más difícil de responder. Google y Apple detallan algunas buenas prácticas para los criterios de aceptación. Por ejemplo, una aplicación que se renderiza a 60 FPS proporciona la mejor experiencia al usuario final. ¿Significa esto que tienes un problema de performance si tu aplicación se renderiza a 30 FPS? Depende del tipo de aplicación que tengas. Un juego para móviles o una aplicación con gráficos pesados tendrán requisitos de FPS más altos.

Las aplicaciones transaccionales pueden no necesitar mayores FPS porque es más importante saber la rapidez con la que se completan ciertas transacciones. Medir el tiempo de respuesta del usuario final en la página de inicio de sesión o en una acción como añadir un artículo al carrito es una buena forma de medir la velocidad de las transacciones.

Nuestra recomendación es definir con todo el equipo de desarrollo los criterios de aceptación como requerimientos no funcionales. Puede ser el número de crashes o errores, el porcentaje medio de uso de la CPU (menos del 50%) o el tiempo de inicio de la aplicación (menos de 3 segundos). El objetivo final es tener más confianza en la calidad de cada nueva versión entregada. Si cumple con sus objetivos de aceptación cada vez, tendrás más certeza en cuanto a la experiencia del usuario final.

¿Cómo se puede utilizar Apptim en CI/CD?

Sofía Palamarchuk: Tenemos una herramienta CLI que permite a los desarrolladores de aplicaciones móviles ejecutar validaciones de performance automatizadas de su aplicación, integrarlas en CI/CD y establecer criterios de aceptación para los KPI más importantes que afectan a la experiencia del usuario. Los interesados en una demo, pueden ponerse en contacto con nuestro equipo.

¡Más de 10.000 equipos han usado Apptim para las pruebas de performance en aplicaciones móviles!

¡Síguenos en LinkedIn, Twitter, Facebook, Instagram y Youtube para ser parte de nuestra comunidad y aprender más acerca de buenas prácticas y herramientas testing de performance móvil!