Cómo automatizar las pruebas de aplicaciones móviles
La capacidad de atención media de una persona es de menos de 9 segundos! ¿Alguna vez te has preguntado por qué? La mayoría de las aplicaciones móviles que han surgido en los últimos tiempos requieren que desplaces un feed hacia abajo, en el que el cerebro está afinado para no prestar atención a algo durante más de unos pocos segundos. Esto ha provocado una reducción significativa de la capacidad de atención de un usuario medio.
La gran variedad de aplicaciones móviles disponibles en la tienda de aplicaciones conlleva una gran responsabilidad en cuanto a las pruebas de aplicaciones móviles y la ampliación de los esfuerzos de pruebas de regresión. Ahí es donde las herramientas de pruebas móviles resultan útiles.
Fui uno de los primeros en adoptar los marcos de pruebas móviles y, según mi experiencia, centrarse en la automatización, los factores de forma y las pruebas de rendimiento ha desempeñado un papel igualmente importante para ampliar y aumentar el impacto en el mundo móvil. En este artículo, compartiré las técnicas más eficaces para automatizar las pruebas de tus aplicaciones móviles.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Pruebas de aplicaciones móviles: componentes que debes tener en cuenta
Las pruebas en cualquier plataforma específica presentan sus propios desafíos, pero en el caso de los dispositivos móviles hay parámetros adicionales que debes tener en cuenta. Tanto si realizas pruebas manuales como automatizadas, además de las pruebas funcionales, tus casos de prueba deben centrarse en:
Conectividad
Es importante abordar qué ocurre si un usuario utiliza su dispositivo móvil en modo avión o sin conexión, qué sucede si el ancho de banda fluctúa, etc., para garantizar que la aplicación funcione correctamente.
Ubicación
Especialmente en el caso de las aplicaciones móviles que dependen del GPS o de servicios basados en la ubicación, las pruebas deben realizarse simulando la ubicación mediante herramientas como MobileSpy, Location Spoofer, etc.; de lo contrario, sería difícil probar, por ejemplo, un escenario de prueba para una aplicación móvil de transporte compartido en el que alguien solicita un viaje desde Nueva York y se han realizado cambios en los microservicios del backend específicos para encontrar al conductor en esa ubicación. Sin simulación, las pruebas no proporcionarían resultados precisos.
Sistema operativo
Especialmente teniendo en cuenta la cantidad de teléfonos Android que hay actualmente en el mercado, probar todas las versiones de SO disponibles es casi imposible; entonces, ¿cómo se prioriza? Con iOS, existen desafíos adicionales relacionados con las versiones de Xcode asociadas a los cambios de versión del SO.
Actualmente, las empresas recurren a proveedores externos como BrowserStack para proporcionar simuladores/emuladores para diversos SO, pruebas de dispositivos y pruebas entre navegadores.
Los iconos de la interfaz de usuario son diferentes según las plataformas de sistemas operativos: Windows, iOS y Android; y, cuando se trata de automatización de pruebas, la mayoría terminamos utilizando simuladores: los de Android tardan mucho más en cargarse, mientras que los dispositivos iOS son más rápidos.
Las distintas combinaciones de teclas móviles que deben utilizarse según los diferentes tipos de sistemas operativos para realizar capturas de pantalla con las que depurar problemas constituyen un dato fundamental para cualquiera que pruebe aplicaciones móviles.
Factor de forma
Al desarrollar aplicaciones móviles, hay 5 factores de forma principales que deben tenerse en cuenta para las distintas versiones del SO, además del modo vertical u horizontal en cada uno de estos tipos de dispositivos:
| Dispositivo | Tamaño de pantalla |
| Dispositivos móviles pequeños | 3,5 pulgadas o menos |
| Dispositivos móviles medianos | De 3,5 a 5 pulgadas |
| Tabletas | De 5 a 7 pulgadas |
| Tabletas pequeñas | De 7 a 8,5 pulgadas |
| Tabletas de tamaño completo | 8,5 pulgadas o más |
Cómo elegir el marco adecuado para la automatización móvil
Tener en cuenta los factores de forma al crear aplicaciones móviles significa garantizar la capacidad de respuesta cuando la misma aplicación se abre en distintos dispositivos móviles y tipos de SO. Cuando el uso de la aplicación se extiende por todo el mundo y las empresas quieren aumentar su base de usuarios, deberán tomar esta decisión al principio del proceso de desarrollo y optar por utilizar marcos React Native en lugar del desarrollo nativo para Android o iOS.
De lo contrario, las empresas acabarán invirtiendo tiempo y esfuerzo más adelante en refactorizar y rediseñar las aplicaciones para cambiar a marcos React Native. Esto afecta directamente al número de equipos y a la sobrecarga de mantenimiento, ya que los marcos React Native permiten desarrollar aplicaciones tanto para iOS como para Android.
Cuando las aplicaciones móviles se desarrollan utilizando marcos React Native, también se reduce la carga de la automatización de pruebas, ya que solo es necesario mantener un único marco de automatización de pruebas para iOS y Android.
Existen diferentes formas de desarrollar aplicaciones móviles. Algunas empresas recurren al uso de lenguajes de programación nativos como Java y Objective C para las aplicaciones de Android e iOS, respectivamente. La ventaja de utilizar lenguajes nativos les ayuda a proporcionar una funcionalidad completa a sus aplicaciones.
Por otro lado, los identificadores de los elementos serán diferentes en ambas plataformas, lo que significa que necesitaremos marcos de pruebas nativos independientes para probar lo mismo, como Espresso en Android, XCUITest en iOS, etc.
React Native es otro lenguaje de programación utilizado habitualmente para desarrollar aplicaciones móviles adaptables que fue publicado como código abierto por Facebook. El objetivo era unificar los esfuerzos de desarrollo móvil en ambas plataformas, de modo que pudiera haber un único equipo y que los identificadores de los elementos de ambas aplicaciones fueran los mismos, lo que solo requiere un único marco de pruebas como Appium para ayudar a probar las aplicaciones móviles.
Cuando se trata de automatizar las pruebas de aplicaciones móviles, elegir las herramientas adecuadas de automatización de QA puede marcar una diferencia significativa en la eficiencia de las pruebas.
Cómo automatizar las pruebas de aplicaciones móviles de iOS
Al realizar pruebas manualmente, hay una serie de criterios que deben cumplirse: la mayoría de las empresas que desarrollan aplicaciones para iOS especifican claramente qué sistemas operativos y versiones del SDK son compatibles. Esto ayuda a limitar los esfuerzos de prueba.
Para ampliar los esfuerzos de pruebas de software, debemos invertir en automatización. Existen muchos marcos populares que admiten las pruebas automatizadas de aplicaciones móviles de iOS. De todos ellos, limitaremos el alcance de nuestro análisis a las siguientes 2 herramientas de automatización:
- XCUITest
- Appium
| XCUITest | Appium |
| Marco para aplicaciones nativas que puede residir dentro del código fuente de iOS. | Marco de pruebas aislado que se desarrolla fuera del código fuente. |
| Escrito en Objective C o Swift | Escrito en Java, Python, etc. |
| Esperas explícitas que aplican una condición. | Esperas implícitas que implican el uso de sleep(), lo que hace que las pruebas sean inestables. |
| Simulación de respuestas de API del backend mediante bibliotecas de código abierto como Mockingjay | Admite el uso de servidores simulados. |
| Dado que se trata de un marco para aplicaciones nativas, solo puede utilizarse para probar aplicaciones de iOS. | Dado que las pruebas residen fuera del código fuente y pueden escribirse en lenguajes como Java, Python, etc., puede utilizarse para probar aplicaciones multiplataforma como las de Windows, iOS y Android, siempre que los identificadores de los elementos sean los mismos en ambas plataformas. |
He utilizado servidores simulados para simular las llamadas al backend y probar exclusivamente la interfaz de usuario de la siguiente manera, mediante la creación de una clase base:
Ahora que la clase base está lista, añado la prueba real utilizando el patrón de diseño de objetos de página de la siguiente manera:
Cómo automatizar las pruebas de aplicaciones móviles de Android
Hay más de 2.000 millones de dispositivos Android activos en el mundo. ¡Probar tu aplicación de Android en distintos tipos de dispositivos y sistemas operativos es prácticamente imposible! Por eso, las empresas especifican claramente las versiones compatibles. Esto también garantiza una mejor experiencia de usuario.
Los marcos de automatización de Android sin duda ayudarán a acelerar procesos de prueba como Robotium, Selendroid, etc., y, para el alcance de nuestro análisis, limitaremos la lista a las herramientas de automatización Espresso y Appium:
| Espresso | Appium |
| Marco nativo que puede residir dentro de la base de código fuente de Android. | Marco de pruebas aislado que se desarrolla fuera de la base de código fuente. |
| Escrito en Java y Kotlin | Escrito en Java, Python, etc. |
| Esperas explícitas; operaciones asíncronas compatibles mediante la capacidad de recursos de inactividad | Esperas implícitas que implican el uso de sleep(), lo que hace que las pruebas sean inestables. |
| Simulación de respuestas del backend mediante bibliotecas de código abierto como Mockito y el generador de Retrofit | Admite el uso de un servidor simulado. |
| Dado que se trata de un marco nativo, solo puede utilizarse para probar aplicaciones de Android. | Dado que las pruebas residen fuera de la base de código fuente y pueden escribirse en lenguajes como Java, Python, etc., puede utilizarse para probar aplicaciones multiplataforma tanto en iOS como en Android, siempre que los identificadores de los elementos sean los mismos en ambas plataformas. |
Una de las ventajas de utilizar marcos de aplicaciones nativas es poder usar servidores simulados para simular las llamadas a la API del backend y probar así exclusivamente la interfaz de usuario. Este es un ejemplo de código sobre cómo lo he conseguido:
Dependiendo de cómo esté desarrollada la arquitectura de microservicios, puedes obtener la respuesta de la pestaña de red del navegador o directamente de los desarrolladores y hacer referencia a ella de la siguiente manera en tu prueba:
Como puedes ver en el ejemplo anterior, HomeTabPage se llama dentro de la prueba, en lugar de tener que comprobar explícitamente cada elemento; he aplicado el patrón de objetos de página en el marco de la siguiente manera:
Herramientas para probar aplicaciones móviles
Existen varias herramientas de pruebas en el sector y la elección depende de múltiples factores:
- Conjunto de habilidades del equipo
- Objetivo de la automatización
- Público de la automatización: responsables de producto, personal de ventas, ingenieros y probadores
- Compatibilidad del marco de pruebas con el código fuente nativo
- Número de aplicaciones híbridas
Entre las distintas herramientas utilizadas habitualmente en el sector se incluyen:
- Selendroid
- Robotium
- Appium
- Testdroid
- UiAutomator
¿No te apetece realizar tus propias pruebas internas? También puedes contratar servicios de pruebas de aplicaciones móviles para que lo hagan por ti.
Pruebas de rendimiento de aplicaciones móviles
Al probar aplicaciones móviles, además de centrarnos en la automatización para ampliar los esfuerzos de pruebas, también debemos dar prioridad a las pruebas de rendimiento, ya que desempeñan un papel crucial a la hora de determinar si un usuario va a seguir utilizando nuestra aplicación.
Si la pantalla tarda más de 2 segundos en cargarse, las personas se impacientan —lo que nos remite a nuestra investigación sobre la capacidad de atención— y, por tanto, para conservar a los usuarios, debemos invertir en pruebas de rendimiento.
Al probar el rendimiento de la aplicación, tendremos que identificar los KPI y compararlos con ellos:
- Tiempo de respuesta máximo
- Tiempo de respuesta medio
- Rendimiento medio
- Número máximo de usuarios activos para cada sistema operativo y dispositivo
El uso de una herramienta de pruebas de aplicaciones móviles puede simplificar las pruebas de rendimiento. Por ejemplo, Apptim puede realizar un seguimiento de las métricas de rendimiento del usuario final y proporcionar informes exhaustivos sobre todos los parámetros de rendimiento clave.
Para supervisar el rendimiento de las aplicaciones móviles, podemos utilizar la supervisión del rendimiento de Firebase, que proporciona control sobre los datos de rendimiento al ofrecer información sobre cómo funciona tu aplicación, con un desglose de los datos de trazas y de red en dimensiones como la versión de la aplicación, el país, el dispositivo y el tipo de red.
Existen otras herramientas como Appium Studio, Sauce Labs, Testdroid, etc., que ofrecen capacidades similares de supervisión del rendimiento.
¡Esperamos que este artículo te haya proporcionado una introducción a las pruebas de aplicaciones móviles y a los factores críticos asociados a ellas!
Para conocer más prácticas recomendadas y consejos que te ayuden a definir tu proceso de desarrollo, suscríbete al boletín de The QA Lead.
Lectura relacionada:
Consulta también:
- ¿QUÉ ES TESTGEAR? DESCRIPCIÓN GENERAL Y RECORRIDO POR SUS FUNCIONES
- MÉTRICAS DE SUPERVISIÓN DE SERVIDORES QUE DEBES SEGUIR PARA GARANTIZAR EL ESTADO Y EL RENDIMIENTO DEL SISTEMA
Lista relacionada de herramientas:
