En esta guía
Si construiste tu app describiéndosela a una herramienta de programación, tienes un producto funcional y un mapa mental del código más pequeño que el de alguien que escribió cada línea. Es normal. Significa que tus pruebas deben basarse en lo que la app hace, no en lo que recuerdas haber escrito.
Este plan lleva una tarde. Anota cada fallo; arréglalos al terminar una pasada, no durante ella.
1. Empieza con una instalación limpia
Desinstala la app y luego instala la build que vas a publicar (no una ejecución de depuración desde tu ordenador). Ábrela como un usuario recién llegado.
- ¿El primer inicio funciona sin cuenta, sin datos y sin ajustes guardados?
- ¿Se entienden todos los avisos de permisos, y la app sigue funcionando si pulsas "No permitir"?
Por qué: la versión que tienes en el teléfono mientras programas guarda datos y permisos sobrantes que un usuario nuevo no tiene.
2. Recorre cada pantalla y luego rompe el orden
Haz una lista de pantallas y acciones. Recórrelas una vez como se pensaron. Luego recórrelas mal:
- Pulsa los botones dos veces seguidas.
- Vuelve atrás a mitad de un flujo.
- Gira el teléfono, cambia el tamaño de la fuente, activa el modo oscuro.
- Deja la app cinco minutos y vuelve.
Por qué: las pantallas generadas suelen probarse solo por el camino feliz que describiste. El orden y el tiempo son donde están las sorpresas.
3. Dale entradas incómodas
Campos vacíos, un nombre muy largo, emojis, un número donde se espera texto, solo espacios. Más sobre esto: ver la checklist de testing de apps móviles.
Por qué: los formularios rara vez dicen qué hacen con una entrada que no describiste. Lo descubres probando.
4. Apaga la red
Activa el modo avión en distintos momentos: antes de abrir, a mitad de una carga, a mitad de un guardado. Luego vuelve a desactivarlo.
- ¿Aparece un mensaje comprensible o un spinner que no termina?
- ¿Se pierde algo de lo que el usuario escribió?
Detalles en prueba el comportamiento sin conexión de tu app.
5. Prueba en un teléfono real, idealmente dos
Un emulador es un comienzo, no el final. Usa un teléfono reciente y, si puedes, uno más antiguo o más pequeño. Ver qué dispositivos Android probar.
6. Revisa lo que no se ve
Repasa el proyecto en busca de cualquier cosa que no deba publicarse: claves, cuentas de prueba, pantallas de depuración, texto de relleno. Ver API keys y secretos en apps generadas con IA.
7. Deja que lo pruebe otra persona
Sabes cómo debe usarse la app, así que evitarás los problemas. Dásela a alguien que nunca la haya visto y obsérvalo sin ayudar. Luego recoge los crashes y ordénalos por prioridad: cómo priorizar los reportes de crash.
Lleva un registro sencillo
Por cada fallo anota: qué hiciste, qué esperabas, qué pasó y en qué dispositivo. Ese es también el formato que puedes pegar después en tu herramienta de código. Ver bugs que encuentran los testers en apps hechas con IA.
Siguiente paso
AppReviewX te da feedback privado y estructurado de otros desarrolladores sobre una build que estás a punto de publicar. Un feedback que escribes te da un crédito; las cuentas nuevas empiezan con 0. Empieza gratis.
Relacionado: hub de vibe coding, checklist de lanzamiento, API keys y secretos.