En esta guía
Un emulador es una buena primera pasada. Es rápido y gratuito, y puedes ejecutarlo en la misma ventana que tu editor. Pero es un modelo de teléfono, y los detalles que un modelo deja fuera son los que encuentran los usuarios reales. Esto vale para cualquier app, sin importar cómo se construyó. Pesa un poco más cuando no escribiste cada línea, porque tienes menos intuición de dónde puede ser frágil.
Lo que muestra un teléfono real
- Velocidad y calor. Una pantalla fluida en tu ordenador puede tartamudear en un teléfono más antiguo o barato. Haz scroll en listas largas, abre la pantalla más pesada y usa la app durante diez minutos.
- Permisos. Cámara, ubicación, notificaciones, almacenamiento: pulsa "Permitir", luego "No permitir", y más tarde desactívalo en los ajustes del sistema. ¿La app se explica y sigue funcionando?
- El teclado. ¿Tapa el campo de entrada? ¿Aparece el tipo de teclado correcto para email o números? ¿Qué pasa cuando lo cierras con el gesto atrás?
- Interrupciones. Una llamada, una notificación, cambiar de app, girar la pantalla, el bloqueo de pantalla por tiempo. Vuelve a la app: ¿sigue ahí lo que escribiste?
- Conexiones reales. Señal débil, cambio de Wi-Fi a datos móviles, modo avión. Ver probar el comportamiento sin conexión.
- Toque y tamaño. ¿Los botones son fáciles de tocar con el pulgar? ¿El texto cabe en una pantalla pequeña y con tamaños de fuente grandes del sistema?
- Instalar y actualizar. Instala la build de publicación desde cero, luego actualiza sobre una build antigua. ¿Sobreviven los datos?
No puedes comprobar nada de esto de forma convincente desde un escritorio.
Un plan corto de dispositivos
No necesitas un cajón de teléfonos. Cubre diferencias, no cantidad. Esta tabla no tiene cifras de cuota de mercado a propósito; elige de lo que tengas a mano.
| Tipo de dispositivo | Por qué | Dónde conseguirlo |
|---|---|---|
| Tu propio teléfono | Uso diario, hábitos reales | Ya lo tienes |
| Un teléfono más antiguo o barato | Muestra límites de velocidad y memoria | Un amigo, la familia, uno de segunda mano |
| Un teléfono con otro tamaño de pantalla | Problemas de diseño | Igual |
| Otra versión del SO | El comportamiento y los diálogos de permisos cambian entre versiones | Igual, o un tester |
| Una persona que no sea desarrolladora | Encuentra los pasos que ya dejaste de ver | Pídelo |
Qué modelos y versiones priorizar está explicado en qué dispositivos Android deberías probar de verdad.
Cuando no puedes conseguir dispositivos
Pide a testers. El feedback privado y estructurado de personas en sus propios teléfonos te da dispositivos que no tienes, y el reporte incluye modelo y versión del SO. Pídelo explícitamente en tu brief de pruebas.
En Google Play, el requisito de prueba cerrada ya pone tu app delante de los teléfonos de otras personas. Consulta los requisitos de la prueba cerrada (DE) y qué cuenta como 14 días (DE). Usa esos días para feedback real, no solo como contador.
Una pasada de 30 minutos
- Instala la build de publicación en un teléfono real.
- Primer inicio, registro y flujo principal, de principio a fin.
- Deniega cada permiso una vez y concédelo una vez.
- Interrumpe la app de tres formas: llamada o notificación, cambio de app, rotación.
- Activa el modo avión a mitad de un flujo.
- Anota cada problema con pasos, resultado esperado, resultado real y dispositivo. Luego usa la plantilla de prompt si lo arreglas con un asistente.
Dónde encaja AppReviewX
AppReviewX te da feedback privado y estructurado de otros desarrolladores en sus propios teléfonos. Un feedback que escribes te da un crédito, los créditos compran feedback para tu app, y las cuentas nuevas empiezan con 0 créditos. Para Android hay grupos de prueba de 12 testers durante 14 días seguidos, para el requisito de Google Play.
Relacionado: hub de vibe coding, cómo probar antes de lanzar, checklist de lanzamiento.