El informe previo al lanzamiento es una ejecución de pruebas automática que Google Play hace en tu build antes de publicarla. Funciona sin configuración adicional por tu parte, así que merece la pena leerlo cada vez. También es fácil leerlo de más: es un robot, no un usuario.
Qué hace
Según la página de ayuda de Play Console, el informe busca problemas de estabilidad, compatibilidad con Android, rendimiento y accesibilidad. Se ejecuta cuando subes un paquete de app o un APK y cuando guardas una versión para producción. La app se lanza en dispositivos del laboratorio de pruebas de Google. Después, un rastreador toca, escribe y desliza durante varios minutos. Al final se compilan los resultados.
Detalles de la misma página que influyen en cómo lo lees:
- Los resultados suelen llegar en menos de una hora desde la subida. Si un informe no está completo tras dos días, vuelve a subir la build.
- Los dispositivos de prueba usan Android 9 o superior e incluyen teléfonos, tablets, Wear OS y dispositivos de clase escritorio. Android Automotive OS y Android TV no se pueden probar.
- Los dispositivos están en Estados Unidos y funcionan en vertical por defecto.
- Puedes añadir hasta tres enlaces profundos como puntos de entrada adicionales, credenciales de cuenta de prueba, un script de Robo o un bucle de juego, y elegir hasta cinco idiomas.
- Las apps sin una actividad de lanzamiento principal no se pueden probar (Google menciona lanzadores, widgets, teclados y caras de reloj).
El alcance cambia con el tiempo. Abre la página actual antes de confiar en cualquiera de estos datos.
Lo que no puede ver
El rastreador no conoce tu producto. No puede juzgar si el onboarding tiene sentido, si un precio está claro o si el texto se entiende bien. Puede que no supere un inicio de sesión si no le das credenciales. Todo lo que está detrás de un pago, un estado poco frecuente o una acción en el mundo real (una entrega, un dispositivo Bluetooth) queda fuera de su alcance.
Cómo clasificar los hallazgos
El resumen del informe agrupa los problemas en errores, advertencias y problemas menores, y ofrece una recomendación de lanzamiento. Úsalo como punto de partida, no como veredicto.
| Hallazgo | Qué hacer |
|---|---|
| Cierre con traza de pila en tu código | Reprodúcelo a mano. Si puedes, corrígelo antes de publicar. |
| Cierre en una biblioteca de terceros | Comprueba si afecta a un flujo real; actualiza la biblioteca si es posible. |
| Cierre solo después de que el rastreador haga algo poco natural | Prioridad más baja, pero comprueba que la app maneja entradas raras sin perder datos. |
| Advertencia de accesibilidad (área táctil, contraste, etiqueta que falta) | Normalmente barata de arreglar y valiosa. Verifícala en tu propio dispositivo. |
| Advertencia de rendimiento | Compárala con un teléfono de gama media real antes de actuar. |
| Muro de inicio de sesión, nada probado | Añade credenciales de prueba y vuelve a ejecutarlo. |
Una regla sencilla: arregla lo que puedas reproducir, anota lo que no puedas y no ignores nada sin una razón escrita.
Úsalo junto a testers reales
El informe encuentra cierres y defectos evidentes en un conjunto fijo de dispositivos, y lo hace rápido. Las personas encuentran flujos confusos, textos poco claros y problemas en sus propios teléfonos. Usa los dos. Para el lado de los datos de campo, consulta Android vitals: nociones básicas; para la comparación, consulta pruebas en la nube frente a testers reales.
Parte de la guía de pruebas de Android.
¿Necesitas personas reales que prueben tu build? Empieza aquí y recibe feedback privado y estructurado.