«Se requieren más pruebas» en Google Play: qué significa y cómo repetir la solicitud de producción (2026)

El correo de Google Play «Se requieren más pruebas para acceder a la producción de Google Play» significa que Google ha rechazado tu solicitud de acceso a producción. No es una infracción de políticas ni suspende tu app. Pero sí te cuesta tiempo: necesitas otro bloque de 14 días de prueba cerrada antes de volver a solicitarlo. Esta guía explica cada motivo del correo, enumera qué cambiar durante esos 14 días extra y muestra cómo reescribir el cuestionario para que tu segunda solicitud sea la definitiva. Si aún no has empezado una prueba cerrada, comienza con nuestro plan de prueba de 12 testers y 14 días.

¿Qué significa «Se requieren más pruebas para acceder a la producción de Google Play»?

Significa que un revisor de Google leyó tu solicitud de acceso a producción y decidió que tu prueba cerrada no había aportado suficientes evidencias de que la app está lista para el público. La producción y el prerregistro siguen bloqueados hasta que hagas más pruebas y vuelvas a solicitarlo.

A noviembre de 2026, los requisitos de pruebas de apps de Google se aplican a las cuentas de desarrollador personales creadas después del 13 de noviembre de 2023. Esas cuentas deben ejecutar «una prueba cerrada de su app con un mínimo de 12 testers que hayan estado inscritos de forma continua durante al menos 14 días». Cumplir esas cifras solo te permite presentar la solicitud. La solicitud en sí se revisa, y Google menciona dos motivos por los que podrías necesitar más pruebas: «tener menos de 12 testers inscritos o una interacción insuficiente de los testers durante el periodo de prueba». Google dice que la revisión «suele tardar siete días o menos, pero en ocasiones puede tardar más», y el propietario de la cuenta recibe la decisión por correo electrónico.

¿Qué significa cada motivo del correo de rechazo?

Cada línea del correo apunta a una carencia concreta: testers que no usaron realmente la app, una prueba sin cambios visibles en respuesta a los comentarios o respuestas del cuestionario demasiado vagas para evaluarlas. El correo puede incluir uno, dos o los tres motivos.

Los desarrolladores que han publicado el correo citan los mismos motivos: «Los testers no interactuaron con tu app durante tu prueba cerrada», «No seguiste las prácticas recomendadas de pruebas, que pueden incluir recopilar comentarios de los usuarios y actuar en consecuencia mediante actualizaciones de tu app», y respuestas sobre la app, la prueba cerrada o la preparación para producción que eran «incompletas o insuficientes». La instrucción final es: «Antes de volver a solicitarlo, prueba tu app mediante una prueba cerrada durante 14 días más con testers reales». Google no publica cómo mide la interacción, así que la tabla relaciona cada motivo con el texto correspondiente de la propia página de ayuda de Google y con una solución.

¿Qué deberías hacer justo después del rechazo?

Mantén la prueba cerrada activa, pide a tus testers que sigan inscritos y publica una nueva compilación en el canal cerrado en pocos días. La página de Google dice que, si no te aprueban, «puede que tengas que seguir ejecutando tu prueba cerrada», así que desmontarla y empezar una nueva supone tirar tu base de testers.

1. No elimines el canal cerrado ni tu lista de testers. Google advierte que «si un tester se da de baja y vuelve a inscribirse más tarde, los 14 días deben ser consecutivos», así que cualquier tester que se vaya ahora reinicia su propio contador.
2. Escribe a todos los testers. Explícales que la prueba continúa 14 días más, que deben seguir inscritos y qué quieres que prueben en esta ronda.
3. Revisa tu número de testers en Play Console. Sustituye a quien nunca instaló la app por personas que realmente la vayan a usar. Los amigos que instalan la app y nunca la abren son la causa habitual del motivo «no interactuaron».
4. Configura un único canal de comentarios. Google sugiere un chat de grupo; un formulario compartido también sirve. Elijas lo que elijas, guarda cada mensaje con su fecha.
5. Escribe una lista de tareas que cubra cada función principal: registro, la acción principal, ajustes, compras (con testers de licencias si la app tiene facturación) y cualquier flujo sin conexión o de notificaciones.
6. Publica en la primera semana una actualización en el canal cerrado que corrija algo que haya reportado un tester, y menciona la corrección en las notas de la versión. Planifica una segunda actualización antes del día 14.
7. Ejecuta el informe previo al lanzamiento y corrige los fallos y avisos de accesibilidad que detecte.
8. Antes de volver a solicitarlo, comprueba que la clasificación de contenido, el público objetivo y el formulario de Seguridad de los datos son correctos. Si la app requiere inicio de sesión, incluye «credenciales de inicio de sesión válidas y que funcionen», como pide la página de Google.

Si además tu app necesita subir el SDK de destino antes de publicarse, hazlo dentro de la misma ventana. Nuestra guía del nivel de API objetivo 36 cubre la fecha límite del 1 de noviembre de 2026.

¿Cómo reescribir las respuestas del cuestionario de acceso a producción?

Sustituye las afirmaciones genéricas por datos concretos: qué funciones usaron los testers, cuántos reportes llegaron, cómo los recopilaste, qué versión corrigió qué y qué evidencias demostraron que la app era estable. Cada respuesta debería ser algo que solo podría escribir un desarrollador que hizo una prueba real.

El formulario se abre desde el Panel de Play Console con Solicitar acceso a producción. Tiene tres partes: tu prueba cerrada, tu app y tu preparación para producción. Si sales de una parte antes de pulsar Siguiente, pierdes el progreso, así que redacta antes tus respuestas en un documento. Un desarrollador en itch.io informó de «un límite de 300 caracteres por respuesta», otra razón para redactar y recortar con antelación. Las respuestas de la Parte 2 no se muestran públicamente y no afectan a la visibilidad de tu app.

Ejemplo práctico para una app hipotética de seguimiento de hábitos. Las respuestas débiles son típicas de las solicitudes que vuelven con «incompletas o insuficientes»:

¿Qué han contado otros desarrolladores tras un rechazo por «más pruebas»?

Los casos públicos siguen un patrón: los testers que se inscribieron pero nunca enviaron comentarios llevaron al rechazo, mientras que un grupo pequeño que envió comentarios y vio cambiar la app obtuvo la aprobación. El número de testers importó menos que las evidencias de uso.

• En la comunidad de MIT App Inventor, el desarrollador shigeki_suzuki contó en julio de 2024 que su app Season Clock alcanzó 20 testers durante 14 días mediante una app de intercambio de testers, y luego recibió «Se requieren más pruebas para acceder a la producción de Google Play» con «Los testers no interactuaron con tu app durante tu prueba cerrada». Escribió que no sabía quiénes eran los testers y que no había recibido comentarios, así que no podía describir cómo fue la prueba ni qué cambió. Tuvo que repetir la prueba.
• En el foro de Adalo, el usuario siang32195 informó del mismo mensaje «Se requieren más pruebas» en agosto de 2024 tras usar testers reclutados. Preguntó cómo verificar que los testers habían usado realmente la app. La respuesta sugirió herramientas de control de tiempo o un informe escrito con los escenarios de prueba que cubrió cada tester. El hilo no dice si la segunda solicitud tuvo éxito.
• Un desarrollador independiente de videojuegos que escribe en itch.io tenía «apenas 12 testers», pero contó que había «hecho varias actualizaciones del juego» y «registrado todo lo que pude de mis interacciones con mis testers». Usó ese registro en la solicitud e informó: «En menos de 36 horas tras enviar la solicitud, me concedieron el acceso a producción».

La comparación: 20 testers sin rastro de comentarios fueron rechazados, mientras que 12 testers con un registro documentado de comentarios y actualizaciones fueron aprobados. Vuelve a solicitarlo cuando tus notas puedan responder a cada campo del cuestionario con datos concretos, no en cuanto el contador llegue a 14 días.

¿Cuándo deberías volver a pulsar Solicitar acceso a producción?

Vuelve a solicitarlo cuando al menos 12 testers lleven inscritos otros 14 días consecutivos y hayas publicado durante ese tiempo actualizaciones basadas en sus comentarios. La página de Google no menciona ningún periodo de espera, pero solicitarlo con las mismas evidencias probablemente obtendrá la misma respuesta.

• Al menos 12 testers inscritos, sin interrupciones por bajas, durante otros 14 días consecutivos (apunta a 15 o más como margen)
• Al menos dos versiones en el canal cerrado desde el rechazo, cada una con notas de la versión que mencionen una corrección reportada por un tester
• Un registro de comentarios con fechas y recuentos por tipo (errores, UX, peticiones) y cómo se recopiló cada uno
• Testers que usaron todas las funciones principales, incluidos el inicio de sesión, las compras y las notificaciones cuando corresponda
• Un informe previo al lanzamiento sin fallos pendientes
• Clasificación de contenido, público objetivo y formulario de Seguridad de los datos correctos, además de credenciales de acceso para el revisor que funcionen
• Respuestas del cuestionario redactadas en un documento, con funciones, cifras y números de versión

La página de Google también advierte que «enviar apps que no cumplen las políticas esperando que los revisores detecten los problemas provoca rechazos, retrasos en la revisión y procesos de apelación más largos», así que corrige cualquier problema de políticas antes de solicitarlo, no después. Si prefieres delegar la configuración de Play Console, el plan de prueba cerrada y la solicitud, nuestro servicio de publicación en App Store cubre ambas tiendas por $599. Las tarifas de las cuentas de desarrollador se pagan aparte.