Testing en dispositivos móviles: guía completa para probar apps mobile

Hola a todos. Pensá en las apps que usaste hoy: la del banco, la de mensajería, la del delivery, la del colectivo, la de la billetera virtual. Probablemente abriste el celular decenas de veces antes de prender una computadora. Para muchísimas personas el teléfono es la única forma de usar internet, y eso convierte a las aplicaciones móviles en uno de los productos de software más usados y, a la vez, más difíciles de probar.

Si venís del testing web, el mundo mobile tiene mucho de familiar: casos de prueba, reportes de bugs, regresiones, automatización. Pero también tiene un montón de particularidades que, si no las conocés, hacen que se te escapen bugs que el usuario encuentra en los primeros cinco minutos. Una llamada que entra en medio de un pago, un celular de gama baja que se queda sin memoria, una red que pasa de wifi a 4G en el ascensor, un permiso de cámara que el usuario negó sin querer.

En este artículo te cuento todo lo que necesitás saber para arrancar con el testing en dispositivos móviles: qué lo hace distinto, cómo elegir en qué dispositivos probar, cuándo usar emuladores y cuándo dispositivos reales, qué tipos de pruebas no te pueden faltar, cómo se automatiza, qué herramientas conviene conocer y cómo reportar bugs mobile para que el equipo de desarrollo los pueda reproducir. Al final te dejo una ruta para empezar a practicar.

¿Qué es el testing mobile?

El testing mobile (o testing en dispositivos móviles) es el conjunto de actividades de prueba que verifican que una aplicación funcione correctamente, sea usable, segura y tenga un buen rendimiento en celulares y tablets. Incluye tanto las apps que se instalan desde Google Play o la App Store como los sitios web que se usan desde el navegador del teléfono.

Dicho así parece igual que cualquier otro testing, y en esencia lo es: seguimos diseñando casos, aplicando técnicas como partición de equivalencia o valores límite, reportando defectos y validando criterios de aceptación. La diferencia está en el contexto. En mobile el software corre sobre un dispositivo que la persona lleva en el bolsillo, que se mueve, que cambia de red, que tiene poca batería, que recibe llamadas y notificaciones, que tiene cámara, GPS, sensores y una pantalla táctil de tamaños muy distintos. Todo eso forma parte de lo que hay que probar.

Por eso a los QAs mobile nos gusta decir que no probamos solo una app: probamos una app dentro de un teléfono dentro de la vida de alguien. Ese cambio de mirada es lo que separa a un testing mobile superficial de uno que realmente protege al usuario.

Un dato interesante para quienes estudian certificaciones: ISTQB tiene una certificación específica, la Certified Tester Mobile Application Testing (CT-MAT), que ordena muy bien todos estos conceptos. Si te interesa, en QARMY tenemos el material ISTQB en español y un simulador del examen CT-MAT para practicar.

Por qué probar en mobile es distinto

Antes de hablar de técnicas y herramientas, conviene entender qué hace que el mundo mobile sea tan particular. Estos son los factores que más impactan en la forma en que probamos.

Fragmentación

En la web probamos en un puñado de navegadores. En mobile hay miles de modelos de dispositivos distintos, con diferentes tamaños de pantalla, resoluciones, densidades de píxeles, procesadores, cantidades de memoria y versiones de sistema operativo. En Android el problema es todavía mayor, porque cada fabricante agrega su propia capa de personalización sobre el sistema: un mismo Android puede comportarse distinto en un Samsung, un Motorola o un Xiaomi, sobre todo en temas como notificaciones, ahorro de batería o permisos.

Redes variables

Un usuario mobile puede estar en un wifi rápido, en 5G, en un 3G pobre en la ruta o directamente sin conexión. Y lo más importante: puede cambiar de una a otra en plena operación. Una app que solo se probó en el wifi de la oficina casi seguro tiene problemas cuando la red se pone lenta o se corta.

Interrupciones

Llamadas entrantes, notificaciones, alarmas, el usuario que bloquea la pantalla, que cambia de app para copiar un código, que gira el teléfono, que conecta auriculares. En una computadora estas cosas casi no existen; en un celular pasan todo el tiempo y la app tiene que saber pausarse, guardar su estado y volver sin perder datos.

Hardware y sensores

Cámara, micrófono, GPS, acelerómetro, giroscopio, lector de huellas, reconocimiento facial, NFC, Bluetooth. Muchas apps dependen de alguno de estos componentes, y cada uno tiene sus propios permisos, comportamientos y fallas posibles.

Recursos limitados

Un celular de gama baja tiene poca memoria, almacenamiento justo y un procesador modesto. Además, el usuario se preocupa por la batería y por el consumo de datos. Una app que en un teléfono de gama alta anda perfecta puede ser lenta, calentar el equipo o cerrarse sola en uno más económico. Y en Latinoamérica, buena parte de los usuarios tiene justamente esos equipos.

Las tiendas y las actualizaciones

En la web, si encontramos un bug en producción, se corrige y se despliega en minutos. En mobile, una nueva versión tiene que pasar por la revisión de la tienda, y después cada usuario decide cuándo actualizar. Eso significa que en la calle conviven muchas versiones de nuestra app al mismo tiempo, y que un bug que se escapa puede quedarse en los teléfonos de la gente durante semanas. El costo de un error en mobile es más alto, y por eso el testing antes de publicar es todavía más importante.

Nativas, híbridas y web: qué estamos probando

No todas las aplicaciones móviles están construidas igual, y el tipo de app cambia bastante cómo la probamos y qué herramientas usamos. Estos son los tres grandes grupos:

Saber qué tipo de app tenés enfrente te ayuda a hacer mejores preguntas. Si es Flutter, por ejemplo, conviene saber que la interfaz se dibuja con su propio motor y que algunas herramientas de automatización necesitan configuraciones especiales para "ver" sus elementos. Si es una web mobile, tu foco va a estar en el responsive, en los navegadores y en el rendimiento de carga. Si es nativa, probablemente tengas dos equipos de desarrollo, dos backlogs y dos conjuntos de bugs distintos.

Un consejo práctico: preguntale al equipo de desarrollo con qué tecnología está hecha la app. Es una pregunta simple que te ahorra horas de prueba y error cuando llegue el momento de elegir herramientas.

Fragmentación: cómo elegir en qué dispositivos probar

Esta es probablemente la pregunta más frecuente en testing mobile: "¿en cuántos celulares tengo que probar?". La respuesta honesta es que nunca vas a poder probar en todos, así que el objetivo no es cubrir todo, sino elegir bien. Para eso se arma una matriz de dispositivos: una lista priorizada de combinaciones de dispositivo, sistema operativo y versión sobre la que se va a probar.

Empezá por los datos

La mejor fuente para armar la matriz son los datos reales de tus usuarios. Si la app ya está publicada, las consolas de Google Play y App Store Connect, y herramientas de analítica como Firebase, te muestran qué dispositivos y versiones de sistema usan tus usuarios. Si la app es nueva, podés apoyarte en estadísticas públicas de mercado de tu país o región, y en lo que sepa el área de negocio sobre el público objetivo.

Un detalle importante: los datos globales pueden engañar. En muchos países de Latinoamérica Android tiene una participación de mercado mucho más alta que en Estados Unidos, y los equipos de gama media y baja son mayoría. Si tu público es local, tu matriz tiene que reflejarlo.

Organizá por niveles

Una forma muy práctica de armar la matriz es dividirla en niveles de prioridad:

• Nivel 1 (crítico): los dispositivos y versiones que usa la mayoría de tus usuarios. Acá se prueba todo, en cada release, idealmente en dispositivos reales.
• Nivel 2 (cobertura): otros modelos populares, versiones de sistema un poco más viejas, tablets. Acá se prueban los flujos principales y las funcionalidades nuevas.
• Nivel 3 (bordes): el sistema más viejo que soportás, pantallas muy chicas o muy grandes, equipos con poca memoria, plegables. Acá se hace una pasada de humo antes de versiones importantes.

Qué variables combinar

Al elegir dispositivos, tratá de cubrir variedad en estas dimensiones:

• Sistema operativo y versión: la última versión, la anterior y la más vieja que la app soporta oficialmente.
• Fabricante: en Android, al menos dos o tres marcas distintas, porque cada capa de personalización tiene sus mañas.
• Tamaño y densidad de pantalla: un teléfono chico, uno estándar, uno grande y una tablet si la app la soporta.
• Gama: no te olvides de los equipos económicos. Son los que más problemas de rendimiento muestran.
• Formatos especiales: plegables, pantallas con notch o cámara perforada, modo oscuro, tamaño de fuente aumentado.

Y lo más importante: la matriz se revisa periódicamente. Cada año salen nuevos modelos y versiones de sistema, y lo que hoy es nivel 1 mañana puede pasar a nivel 3. Documentala en tu plan de pruebas para que todo el equipo sepa sobre qué se está probando y qué queda afuera.

Emuladores, simuladores, dispositivos reales y la nube

Una vez que sabés en qué dispositivos querés probar, aparece la pregunta de cómo conseguirlos. Hay tres grandes opciones, y en la práctica casi todos los equipos terminan combinándolas.

Emuladores y simuladores

Un emulador reproduce un dispositivo completo por software, incluido el hardware. El emulador de Android que viene con Android Studio es el ejemplo más conocido. Un simulador, como el que trae Xcode para iOS, imita el comportamiento del sistema pero no el hardware: corre la app compilada para la computadora. La diferencia técnica importa porque el simulador de iOS es todavía menos fiel que un emulador en cuestiones de rendimiento y hardware.

Son gratuitos, rápidos de levantar, permiten cambiar de modelo y versión en segundos, y son ideales para el desarrollo, las pruebas funcionales tempranas y la automatización en el pipeline. Además permiten simular ubicaciones GPS, condiciones de red o niveles de batería sin moverte de la silla.

Sus límites son claros: no reflejan el rendimiento real, no tienen las personalizaciones de cada fabricante, no reproducen bien la cámara, los sensores, el Bluetooth o las interrupciones reales, y no te dan la sensación física de usar la app con una mano en el colectivo.

Dispositivos reales

Nada reemplaza a probar en un teléfono de verdad. Es la única forma de validar el rendimiento real, el consumo de batería, el calentamiento, la experiencia táctil, los gestos, la cámara, las notificaciones y el comportamiento con la capa del fabricante. La contra es el costo: comprar y mantener un laboratorio de dispositivos es caro, los equipos se vuelven viejos rápido y hay que gestionarlos (cargarlos, actualizarlos, resetearlos, prestarlos).

Una práctica muy común es tener un laboratorio chico con los dispositivos de nivel 1, y complementar el resto con otras opciones.

Granjas de dispositivos en la nube

Servicios como Firebase Test Lab, BrowserStack, Sauce Labs, LambdaTest o AWS Device Farm ofrecen acceso remoto a cientos de dispositivos reales alojados en sus centros de datos. Podés usarlos de forma manual, controlando el teléfono desde el navegador, o correr tus pruebas automatizadas en muchos dispositivos en paralelo.

Son ideales para ampliar la cobertura de la matriz sin comprar equipos, para reproducir un bug que reportó un usuario con un modelo que no tenés y para correr regresiones grandes. Tienen costo (aunque varios ofrecen planes gratuitos o de prueba), cierta latencia al usarlos manualmente y algunas limitaciones con funciones como la cámara o la biometría.

¿Cuál conviene?

La combinación más habitual es: emuladores para el desarrollo, las pruebas tempranas y la automatización en cada commit; dispositivos reales propios para el nivel 1 y el testing exploratorio; y granjas en la nube para cubrir el resto de la matriz y las regresiones antes de cada release. Lo que nunca conviene es probar solo en emuladores y salir a producción.

Tipos de pruebas en mobile

Las pruebas funcionales son la base, pero en mobile hay muchos otros tipos de prueba que tienen un peso enorme en la experiencia del usuario. Este mapa resume los más importantes:

Pruebas funcionales

Verifican que la app haga lo que tiene que hacer: que el registro funcione, que el carrito sume bien, que el pago se procese, que los datos se guarden. Son las mismas que en cualquier otro producto, pero con el agregado de los flujos propios de mobile: permisos, notificaciones push, deep links, inicio de sesión con biometría, integración con otras apps (compartir, abrir un PDF, elegir una foto de la galería).

Usabilidad y experiencia de usuario

En una pantalla chica, con el pulgar como único puntero, los problemas de usabilidad se multiplican. ¿Los botones tienen un tamaño que se pueda tocar sin errar? ¿Lo importante está al alcance del pulgar? ¿El teclado tapa el campo que estoy completando? ¿Se aparece el teclado numérico cuando pido un número de teléfono? ¿Los mensajes de error se entienden? Las heurísticas de usabilidad de Nielsen son una herramienta excelente para revisar apps mobile con criterio. También conviene conocer las guías de cada plataforma: Material Design para Android y las Human Interface Guidelines de Apple para iOS. Un usuario de iPhone espera que la app se comporte como "una app de iPhone", y lo mismo pasa en Android.

Compatibilidad

Verifican que la app funcione bien en toda la matriz de dispositivos: distintas pantallas, versiones de sistema y fabricantes. Acá aparecen los clásicos textos cortados, botones que se salen de la pantalla, imágenes deformadas, elementos tapados por el notch y funciones que fallan solo en cierta versión de Android.

Interrupciones

Prueban qué pasa cuando algo interrumpe a la app: una llamada, una notificación, una alarma, el bloqueo de pantalla, pasar a otra app y volver, enchufar el cargador, quedarse sin batería. La app tiene que pausarse correctamente y retomar sin perder información. Son de las pruebas que más bugs encuentran y de las que menos se hacen.

Red y conectividad

Prueban el comportamiento con distintas calidades de red, sin conexión y en las transiciones. ¿Qué ve el usuario si la red está lenta? ¿Hay un indicador de carga o la pantalla se queda congelada? ¿Qué pasa si se corta la conexión en medio de un pago? ¿Se duplica la operación al reintentar? ¿La app funciona en modo offline si se supone que debe hacerlo? ¿Sincroniza bien cuando vuelve la red? Detrás de casi todo esto hay una API, así que si querés profundizar te recomiendo nuestras guías de testing de APIs con Postman y de Swagger.

Rendimiento, batería y recursos

Miden tiempos de arranque, fluidez de las animaciones, tiempos de respuesta, consumo de memoria, CPU, batería y datos móviles. También verifican que la app no se cierre sola (crash) ni se congele (en Android, el famoso diálogo de "la aplicación no responde", conocido como ANR). Probá especialmente en equipos de gama baja y con poco espacio libre.

Seguridad

Revisan cómo la app protege los datos: que no guarde contraseñas o tokens en texto plano en el dispositivo, que use conexiones cifradas, que no muestre información sensible en las capturas de la pantalla de apps recientes, que la sesión expire, que los permisos pedidos sean los mínimos necesarios y que no filtre datos en los logs. La referencia en este tema es el proyecto OWASP Mobile, con su lista de riesgos principales (OWASP Mobile Top 10) y su guía de verificación (MASVS).

Accesibilidad

Verifican que la app se pueda usar con los lectores de pantalla (TalkBack en Android, VoiceOver en iOS), con tamaños de fuente aumentados, con buen contraste, sin depender solo del color para transmitir información y con elementos que tengan un nombre accesible. La accesibilidad no es un extra: es una parte de la calidad que impacta en millones de personas y que en muchos países ya es una exigencia legal.

Instalación, actualización y desinstalación

Prueban que la app se instale correctamente, que el primer arranque funcione, que al actualizar desde la versión anterior no se pierdan datos ni se rompa la sesión, y que al desinstalar no queden restos problemáticos. La prueba de actualización es crítica y muchas veces se olvida: probamos la app nueva instalada desde cero, pero los usuarios reales vienen de la versión anterior, con datos y configuraciones guardadas.

Localización e internacionalización

Si la app se usa en varios idiomas o países, hay que verificar traducciones, formatos de fecha, moneda y números, textos más largos que rompen el diseño, zonas horarias y, si corresponde, idiomas que se escriben de derecha a izquierda.

Casos de prueba que no pueden faltar

Además de los casos propios de cada funcionalidad, hay un conjunto de escenarios típicos de mobile que conviene tener siempre a mano. Podés sumarlos como una checklist a tu plantilla de casos de prueba:

Permisos

• Aceptar el permiso la primera vez que se pide y verificar que la función ande.
• Negar el permiso y verificar que la app explique por qué lo necesita y no se rompa.
• Negar el permiso de forma permanente y verificar que la app guíe al usuario a la configuración.
• Revocar el permiso desde la configuración del sistema con la app abierta y volver a ella.
• Permisos parciales: ubicación aproximada en vez de precisa, acceso solo a algunas fotos.

Ciclo de vida de la app

• Mandar la app a segundo plano en medio de un formulario y volver: los datos tienen que seguir ahí.
• Dejarla en segundo plano mucho tiempo y volver: el sistema puede haberla cerrado para liberar memoria.
• Girar la pantalla en cada vista: en Android, rotar puede recrear la pantalla y perder el estado.
• Cerrar la app a la fuerza en medio de una operación y volver a abrirla.

Red

• Activar el modo avión en medio de una carga o un envío.
• Pasar de wifi a datos móviles durante una operación.
• Usar la app con una red muy lenta (los emuladores y algunas herramientas permiten simularlo).
• Tocar dos veces seguidas un botón de "Pagar" o "Enviar" con la red lenta: ¿se duplica la operación?

Entrada de datos y teclado

• Verificar que cada campo abra el teclado adecuado: numérico, email, teléfono.
• Comprobar que el teclado no tape el campo activo ni el botón para continuar.
• Pegar texto, usar el autocompletado del sistema y el gestor de contraseñas.
• Probar emojis, caracteres especiales y textos muy largos.

Gestos y pantalla

• Deslizar, mantener presionado, pellizcar para hacer zoom, arrastrar para actualizar.
• Gesto o botón de "atrás" en Android en cada pantalla: ¿vuelve adonde el usuario espera?
• Modo oscuro y tamaño de fuente aumentado.
• Pantalla dividida o ventanas múltiples, si la app las soporta.

Notificaciones y deep links

• Recibir una notificación con la app abierta, en segundo plano y cerrada.
• Tocar la notificación y verificar que lleve a la pantalla correcta.
• Abrir un link a la app sin tener sesión iniciada, o sin tener la app instalada.

Otros escenarios del mundo real

• Batería baja y modo de ahorro de energía activado.
• Poco espacio de almacenamiento disponible.
• Cambio de fecha, hora o zona horaria del dispositivo.
• Auriculares o dispositivos Bluetooth que se conectan y desconectan durante la reproducción de audio o video.

No hace falta correr todos estos casos en cada versión. Elegí los que tengan más riesgo para tu app y rotá el resto. Lo importante es que estén escritos y que nadie dependa de la memoria de un QA para acordarse de ellos.

Automatización de pruebas mobile

Automatizar en mobile es más desafiante que en web: los entornos tardan más en levantar, los dispositivos son más variados y las pruebas tienden a ser más lentas e inestables. Por eso es todavía más importante tener una estrategia clara de qué automatizar y en qué nivel.

La pirámide en mobile

La pirámide de pruebas también aplica, y en mobile su importancia es mayor. La base son las pruebas unitarias, que escribe desarrollo y corren en segundos. En el medio están las pruebas de integración y de API, que validan la lógica de negocio sin pasar por la interfaz. Arriba, menos y bien elegidas, están las pruebas de interfaz de punta a punta, que recorren los flujos críticos en emuladores o dispositivos. Y por encima de todo, el testing manual y exploratorio en dispositivos reales, que ninguna automatización reemplaza.

Un error muy común es querer automatizar todo por la interfaz. Si una regla de negocio se puede validar contra la API, validala ahí: es más rápido, más estable y más barato de mantener. Reservá la interfaz para lo que realmente necesita la interfaz: que el usuario pueda completar los flujos críticos.

Las herramientas principales

Para la web mobile, herramientas como Playwright permiten emular dispositivos (tamaño de pantalla, eventos táctiles, agente de usuario) y son excelentes para validar el diseño responsive y los flujos principales, aunque no reemplazan a probar en navegadores mobile reales. Si ya usás Playwright, el framework k0lmena te da una base lista con Cucumber y soporte para APIs y performance.

Cómo elegir

Algunas preguntas que ayudan a decidir:

• ¿Quién va a escribir y mantener las pruebas? Si es el equipo de desarrollo, las herramientas nativas (Espresso, XCUITest) se integran mejor con su trabajo. Si es QA, Appium o Maestro suelen ser más accesibles.
• ¿Con qué tecnología está hecha la app? Flutter y React Native tienen herramientas específicas que funcionan mejor que las genéricas.
• ¿Necesitás una sola suite para Android e iOS? Appium y Maestro lo permiten; las nativas, no.
• ¿Dónde van a correr? Verificá que la herramienta sea compatible con la granja de dispositivos o el pipeline que vas a usar.

Buenas prácticas de automatización mobile

• Pedí identificadores estables. Acordá con desarrollo que los elementos importantes tengan un identificador de accesibilidad o de prueba. Es la diferencia entre una suite estable y una que se rompe cada semana. Y de paso mejora la accesibilidad.
• Nunca uses esperas fijas. Esperar "cinco segundos" hace que las pruebas sean lentas cuando todo anda bien e inestables cuando la red está lenta. Usá esperas por condición.
• Prepará los datos por API. Si una prueba necesita un usuario con un pedido pendiente, crealo con una llamada a la API antes de la prueba, no recorriendo la interfaz.
• Mantené las pruebas independientes. Cada prueba debe poder correr sola y en cualquier orden.
• Guardá evidencia. Capturas, video y logs de cada fallo. En mobile, reproducir un fallo puede ser muy difícil sin ellos.
• Corré en paralelo. Las pruebas mobile son lentas; la paralelización en varios emuladores o dispositivos es lo que las vuelve viables en el pipeline.

Y una mención especial para la inteligencia artificial: los agentes de IA ya pueden explorar una app mobile, interpretar sus pantallas y ejecutar flujos a partir de instrucciones en lenguaje natural. Si te interesa el tema, en el artículo sobre QA agéntico te explico cómo funcionan, qué pueden hacer hoy y cuáles son sus riesgos.

Herramientas para el día a día

Más allá de la automatización, hay un conjunto de herramientas que todo QA mobile termina usando a diario. No hace falta dominarlas todas desde el primer día, pero conviene saber que existen.

Del lado de Android

• Android Studio: incluye el emulador, el inspector de diseño y los perfiladores de rendimiento (CPU, memoria, red, batería). Aunque no programes, te sirve para crear emuladores de distintas versiones y tamaños.
• adb (Android Debug Bridge): una herramienta de línea de comandos para comunicarte con el dispositivo. Con ella podés instalar apps, tomar capturas, grabar la pantalla, cambiar la configuración y, sobre todo, obtener los logs del sistema con adb logcat.
• Opciones de desarrollador: un menú oculto en los teléfonos Android (se activa tocando varias veces el número de compilación) que permite mostrar los toques en pantalla, limitar los procesos en segundo plano, forzar el cierre de las actividades al salir y mucho más. Ideal para encontrar bugs de ciclo de vida.

Del lado de iOS

• Xcode: trae el simulador de iOS y la herramienta Instruments para medir rendimiento, memoria y consumo de energía. Solo funciona en Mac.
• Consola: la app Consola de macOS permite ver los logs de un iPhone conectado por cable.
• Grabación de pantalla: el propio iPhone permite grabar la pantalla desde el centro de control, algo muy útil para documentar bugs.

Proxies de red

Herramientas como Charles Proxy, Proxyman, mitmproxy o HTTP Toolkit permiten ver todas las llamadas que la app hace al servidor, sus respuestas y sus tiempos. También permiten modificar respuestas para provocar errores, o simular una red lenta. Para un QA es una herramienta valiosísima: muchas veces el bug no está en la app, sino en lo que devuelve el servidor, y con un proxy lo ves en segundos. Para entender lo que estás viendo, tené a mano nuestra referencia de códigos HTTP.

Monitoreo de fallos

Herramientas como Firebase Crashlytics o Sentry registran los cierres inesperados y errores que les ocurren a los usuarios reales, con información del dispositivo, la versión y el punto exacto del código. Revisarlas después de cada release es una práctica clave de Shift-Right: te enterás de los problemas antes de que lleguen las reseñas negativas.

Builds, betas y tiendas

En mobile, conseguir la versión correcta de la app para probar ya es parte del trabajo. Conviene conocer cómo se distribuyen las versiones de prueba:

• Android: las apps se pueden instalar directamente desde un archivo APK, o distribuir a testers a través de los canales de prueba de Google Play (prueba interna, cerrada y abierta) o de Firebase App Distribution.
• iOS: la instalación es más restrictiva. Lo habitual es usar TestFlight, la plataforma de Apple para distribuir betas a testers internos y externos.

Algunas cosas que conviene verificar en esta etapa:

• Sabé siempre qué build estás probando. Número de versión, número de compilación y ambiente (desarrollo, QA, staging, producción). Un bug reportado sobre la build equivocada es tiempo perdido para todos.
• Probá la build que realmente se va a publicar. Las versiones de depuración pueden comportarse distinto que las de producción, por ejemplo por optimizaciones del compilador o configuraciones de seguridad.
• Revisá la ficha de la tienda. Capturas, descripción, permisos declarados, clasificación por edad. También es parte del producto.
• Conocé las reglas de las tiendas. Apple y Google tienen políticas de revisión, y una app puede ser rechazada por motivos que QA podría haber detectado antes: enlaces rotos, funciones que no andan, pedidos de permisos sin justificación, falta de una opción para eliminar la cuenta.
• Usá lanzamientos graduales. Ambas tiendas permiten publicar una versión primero a un porcentaje de usuarios y monitorear antes de llegar a todos. Es una red de seguridad excelente.

Cómo reportar un bug mobile

Un reporte de bug mobile necesita más contexto que uno web, porque el mismo bug puede aparecer en un dispositivo y no en otro. Si el equipo de desarrollo no puede reproducirlo, el bug se queda en el limbo. Estos son los datos que no pueden faltar:

• Dispositivo: marca y modelo exactos.
• Sistema operativo: plataforma y versión exacta.
• Versión y build de la app: y el ambiente contra el que estaba apuntando.
• Condiciones: tipo de red, orientación, idioma, modo oscuro, nivel de batería o cualquier otra condición relevante.
• Pasos para reproducir: claros, numerados y desde un punto de partida conocido.
• Resultado esperado y resultado obtenido.
• Frecuencia: ¿pasa siempre, a veces, una sola vez? Los bugs intermitentes son comunes en mobile y es importante decirlo.
• Evidencia: un video de la pantalla vale más que mil palabras en mobile. Sumá capturas y, si es un cierre inesperado, los logs del dispositivo.
• Alcance: si lo probaste en otros dispositivos, decí dónde pasa y dónde no. Esa información ayuda muchísimo a encontrar la causa.

Si querés un formato listo para usar, en QARMY tenemos una plantilla de reporte de bugs gratuita que podés adaptar sumando los campos específicos de mobile.

Errores comunes en el testing mobile

Estos son los errores que más veo en equipos que recién empiezan con mobile. Si los evitás, ya estás un paso adelante:

• Probar solo en el teléfono propio. Tu celular probablemente sea más nuevo y potente que el de buena parte de los usuarios. Lo que anda bien en tu equipo no dice mucho de la experiencia real.
• Probar solo en emuladores. Sirven muchísimo, pero no detectan problemas de rendimiento, hardware ni personalizaciones de los fabricantes.
• Probar siempre con wifi. La oficina tiene una red rápida y estable; la calle no.
• Olvidarse de la actualización. Probar solo instalaciones limpias y nunca la actualización desde la versión anterior, que es lo que hace la mayoría de los usuarios.
• Ignorar las interrupciones y el ciclo de vida. Son una de las fuentes más grandes de bugs y una de las menos probadas.
• Dejar la accesibilidad para el final. Cuando se deja para último momento, casi nunca se hace. Y corregirla después cuesta mucho más.
• Automatizar todo por la interfaz. Termina en suites lentas, frágiles y caras de mantener. La interfaz es para los flujos críticos.
• No mirar lo que pasa en producción. Los reportes de fallos y las reseñas de las tiendas son una fuente de información valiosísima sobre lo que el testing no encontró.

Cómo empezar a practicar

Si querés meterte en el mundo del testing mobile, te propongo un camino en seis pasos:

1. Afianzá los fundamentos del testing. Diseño de casos, técnicas de prueba, reporte de bugs. Todo lo que sabés de testing sirve en mobile. Nuestro curso gratuito de QA desde cero es un buen punto de partida.
2. Usá tu propio celular como laboratorio. Elegí una app que uses seguido y probala con mirada de QA: girá la pantalla, poné el modo avión, negá permisos, mandala a segundo plano en medio de una operación. Vas a sorprenderte de cuántas cosas encontrás.
3. Instalá Android Studio y armá emuladores. Creá dos o tres dispositivos con distintas versiones y tamaños. Aprendé a instalar una app, a simular una red lenta y a cambiar la ubicación.
4. Aprendé a leer logs y a usar un proxy. Probá adb logcat y alguna herramienta como Charles o HTTP Toolkit. Te van a cambiar la forma de investigar bugs.
5. Arrancá con la automatización. Maestro es una excelente puerta de entrada por lo simple que es; después podés pasar a Appium. Hay apps de ejemplo pensadas para practicar, y en nuestra lista de webs para practicar testing vas a encontrar recursos para empezar.
6. Formalizá lo que aprendiste. Si te gustan las certificaciones, la CT-MAT de ISTQB ordena muy bien todos estos temas. Podés practicar con nuestro simulador CT-MAT y repasar con el material ISTQB en español.

Preguntas frecuentes

¿Necesito una Mac para probar apps de iOS?

Para usar el simulador de iOS y las herramientas de Apple como Xcode, sí. Para probar manualmente, alcanza con un iPhone y acceso a las betas por TestFlight. También podés usar iPhones reales a través de granjas de dispositivos en la nube, sin tener una Mac.

¿Es suficiente probar en emuladores?

No. Los emuladores son excelentes para el desarrollo, las pruebas funcionales tempranas y la automatización, pero no reflejan el rendimiento real, el comportamiento del hardware ni las personalizaciones de cada fabricante. Antes de publicar, siempre hay que probar en dispositivos reales, propios o en la nube.

¿Qué es mejor para empezar a automatizar: Appium o Maestro?

Maestro es más simple para arrancar y obtener resultados rápido. Appium tiene más trayectoria, una comunidad enorme, soporta muchos lenguajes y es muy pedido en el mercado laboral. Un buen camino es empezar con Maestro para entender los conceptos y aprender Appium después.

¿El testing mobile tiene salida laboral?

Sí, y mucha. Casi todas las empresas tienen una app o un sitio que se usa mayormente desde el celular, y los perfiles de QA con experiencia en mobile, sobre todo en automatización, son muy buscados. Además es una especialidad que combina muy bien con el testing de APIs, la accesibilidad y la performance.

¿Cuántos dispositivos necesito para un laboratorio propio?

Depende de tu matriz, pero para empezar suele alcanzar con tres a cinco equipos que cubran los dispositivos de nivel 1: algún iPhone reciente, un par de Android de distintas marcas y gamas, y uno con una versión de sistema más vieja. El resto se puede cubrir con emuladores y granjas en la nube.

Conclusión

El testing en dispositivos móviles no es una rama aparte del testing, es el mismo testing de siempre aplicado a un contexto mucho más variado e impredecible. Las técnicas, el pensamiento crítico y la curiosidad que usás para probar cualquier software siguen siendo la base. Lo que cambia es que tenés que pensar en la persona que usa la app en el colectivo, con un celular de hace cuatro años, la batería al quince por ciento y una señal que va y viene.

Elegí bien tus dispositivos con datos, combiná emuladores, equipos reales y la nube, no te olvides de las interrupciones, la red, la accesibilidad y las actualizaciones, automatizá con criterio y reportá bugs con todo el contexto que el equipo necesita. Con eso vas a estar protegiendo lo que realmente importa: que la app funcione para quien la usa, donde sea que esté.

Si querés seguir aprendiendo, sumate al canal de WhatsApp de QARMY, donde compartimos novedades, recursos y anunciamos los próximos cursos. Y si tenés alguna experiencia probando apps mobile, contanos: siempre se aprende algo nuevo de los bugs de otros.