Respuesta rápida
«More testing required» es el resultado de una solicitud de acceso a producción, no una sanción por incumplir las políticas. Google revisa la prueba cerrada que ejecutaste y las respuestas que diste, y luego escribe al propietario de la cuenta. Si la revisión no queda satisfecha, se te pide que sigas probando. Empieza por confirmar qué decisión recibiste y, después, qué demuestran tus propios registros sobre la elegibilidad, el uso de la app, los comentarios y la preparación.
Si en cambio rechazaron tu app o tu versión por un problema concreto, sigue las instrucciones para corregir ese problema y volver a enviar la app. Más testers no resuelven una decisión sobre políticas.
Este artículo es el diagnóstico: qué decisión recibiste, qué puede y qué no puede demostrar cada evidencia, y qué corregir antes de volver a solicitar. Se apoya en las pruebas cerradas que PrimeTestLab ejecuta cada semana y en la guía de Google, enlazada allí donde se usa. Información vigente al 11 de septiembre de 2026.
Cómo leer este artículo
- Requisito de Google Una condición obligatoria de elegibilidad, de envío o de políticas.
- Guía de Google Google lo recomienda, o la solicitud lo pregunta. No se publica ningún umbral.
- Nuestra sugerencia Una práctica de trabajo que viene de las pruebas que ejecutamos, no una regla con la que se te evalúa.
En esta página
Primero, identifica qué rechazó Google
A tres decisiones distintas se les llama «prueba cerrada rechazada», y cada una pide un trabajo distinto. Guíate por el texto exacto que recibiste.
¿Qué mensaje recibiste?
| Qué recibiste | Qué significa | Qué hacer después |
|---|---|---|
| El panel dice que la elegibilidad de las pruebas está incompleta | El panel identifica una condición de prueba sin cumplir. Revisa la condición concreta que aparece antes de decidir qué tiene que continuar. | Termina la prueba cerrada: al menos 12 testers, cada uno con la participación aceptada durante los últimos 14 días de forma continua. |
| «More testing required» después de solicitar | Tu solicitud se revisó y todavía no se aprobó. Google te pide que sigas probando; la decisión y el correo al propietario de la cuenta recogen las objeciones que se identificaron. | Recorre las cinco áreas de abajo, corrige lo que encuentres y vuelve a solicitar desde tu cuenta. |
| App o versión rechazada por un problema concreto | Una decisión sobre la app en sí, que nombra un problema de políticas o de calidad. No es un juicio sobre tu número de testers. | Sigue las instrucciones para corregir el problema que se nombra y volver a enviar la app. Más testers no lo van a resolver. |
Un segmento de producción bloqueado, por sí solo, no te dice si lo que sigue pendiente es la elegibilidad de las pruebas, una decisión sobre la solicitud u otro paso de la cuenta. Oriéntate por el mensaje concreto que recibiste, no por el bloqueo.
Fuentes: requisitos de prueba de las apps y acceso a producción, y publicación y estado de la revisión.
Confirma que el requisito se aplica a tu caso
Requisito de GoogleEl requisito se aplica a las cuentas personales de desarrollador creadas después del 13 de noviembre de 2023. Google indica que esas cuentas deben cumplir requisitos de prueba concretos antes de que una app sea apta para publicarse. Si la tuya está afectada, pasan tres cosas en este orden:
- 1Ejecutar una prueba cerrada, no solo una prueba interna.
- 2Mantener al menos 12 testers con la participación aceptada durante 14 días de forma continua.
- 3Solicitar el acceso a producción y responder las preguntas sobre la prueba, la app y su preparación.
Ser elegible no es estar aprobado
Cumplir el requisito te habilita para solicitar. La solicitud se revisa por separado, así que unos 14 días impecables son el comienzo del proceso, no su final. Todo el detalle: cómo funciona el requisito de testers.
Diagnostica el problema en cinco minutos
Abre Play Console junto a esta lista y responde cada pregunta con honestidad. Lo que no puedas responder es por donde debes empezar a leer.
Qué hace y qué no hace
Esto no lee nada de tu cuenta de Play Console y no puede confirmar tu número de testers ni las fechas de participación. Solo ordena lo que ya sabes en el orden en que la revisión lo pregunta.
Siguiente paso
Usa la guía para volver a solicitar con los pasos a seguir tras una decisión de más pruebas. Si tu diagnóstico muestra que necesitas más pruebas con personas reales, compara las opciones de apoyo para pruebas. Si Google señaló un problema de la app o de políticas, corrígelo primero; otro grupo de testers no lo resolverá.
Cinco áreas que revisar tras una denegación de acceso a producción
Áreas que investigar, en el orden en que puedes investigarlas. No están ordenadas por la frecuencia con la que provocan una denegación, porque ningún dato publicado establece ese orden.
La elegibilidad o la continuidad de los testers está incompleta
Google exige un mínimo de 12 testers con la participación aceptada durante al menos los últimos 14 días de forma continua. La continuidad se mide por tester: quien acepta participar, prueba menos de 14 días y deja de participar no cuenta en ese periodo interrumpido. Un tester que regresa puede volver a cumplir tras un nuevo periodo de participación de 14 días ininterrumpidos.
Qué revisar
- Confirma que estás en el segmento cerrado. Un tester que siga inscrito en una prueba interna tiene que salir de ella antes de que tu prueba cerrada le llegue.
- Cuenta a las personas que aceptaron participar, no las direcciones que agregaste a una lista. Agregar una dirección no hace nada hasta que esa persona acepta el enlace.
- Pide a los testers que sigan participando hasta el momento en que solicites el acceso a producción, no solo durante los 14 días previos.
Ejemplo: la continuidad se mide por tester
Si 15 testers entraron juntos y uno se va, los 14 restantes pueden seguir cumpliendo, porque cada uno mantuvo su propio periodo sin interrupciones. Quien entra después como sustituto arranca su propio reloj y no hereda el tiempo transcurrido del tester que se fue.
Mantén un margen pequeño por encima del mínimo. Exactamente 12 testers cumplen, así que el margen es una práctica nuestra para absorber que alguien deje de participar sin caer por debajo del mínimo, no algo que Google pida.
Fuentes: requisitos de prueba de las apps para las cuentas personales de desarrollador nuevas, y configurar una prueba abierta, cerrada o interna para las listas de testers y los enlaces de participación. Guías paso a paso: comprobar las invitaciones de testers y la participación y prueba interna frente a prueba cerrada.
Los testers no usaron la app de forma significativa
La solicitud pregunta si los testers usaron las funciones y si ese uso se pareció al que esperas en producción. Google también dice que te pueden pedir que sigas probando cuando los testers no interactuaron con la app. La guía que consultamos no especifica ningún umbral numérico de interacción, así que el trabajo consiste en describir el uso real.
Tres cifras que no son la misma cifra
| Métrica | Qué cuenta | Qué demuestra esta métrica |
|---|---|---|
| Testers con participación aceptada | Personas que aceptaron el enlace de participación de tu segmento cerrado y siguen participando. | La cifra de elegibilidad, y la única de las tres ligada a la regla de 12 y 14. |
| Audiencia instalada | Usuarios con tu app instalada en al menos un dispositivo que usaron en los 30 días anteriores. | La app llegó a un dispositivo en uso. No demuestra que alguien la haya abierto. |
| Usuarios activos diarios | Personas que abrieron la app en un día determinado. | Hubo aperturas. Sigue sin decir qué funciones se usaron ni qué les parecieron a los testers. |
Fuente: ver las estadísticas de la app. Google sí dispone de datos de uso, así que la interacción no le resulta invisible. Lo que no está documentado es qué señales pesan en la revisión, y con qué nivel.
Qué revisar
- Dales a los testers unas instrucciones breves que nombren los flujos que quieres que recorran, y un único canal para responder.
- Pide observaciones concretas, no un veredicto: qué probaron, en qué dispositivo y qué pasó.
- Pide a los testers que vuelvan sobre una corrección importante cuando se publique, para que el registro muestre un cambio comprobado.
Pide a los testers que completen las tareas que importan para tu app, que cuenten lo que ven con sus propias palabras y que vuelvan sobre las correcciones importantes cuando se publiquen. Una instrucción fija como «abrir la app una vez al día» es una rutina de pruebas opcional, no una regla de Google.
A los comentarios y a las respuestas de la solicitud les falta evidencia concreta
La solicitud te pide resumir los comentarios que recibiste y los cambios que hiciste. Google recomienda anotar los temas de los comentarios sobre la marcha, y ese registro es la diferencia entre una respuesta concreta y una genérica.
Registro de pruebas de ejemplo (la estructura, no el contenido para copiar)
| Compilación, flujo, entorno | Hallazgo | Acción o verificación |
|---|---|---|
| Compilación 8; restablecimiento de contraseña; Android 14 | El mensaje de reintento no se entendía | Aclarado en la compilación 9; el tester lo volvió a comprobar |
| Compilación 9; ajustes guardados; Android 13 | Los ajustes se mantuvieron al volver a abrir | Registrado como correcto; sin cambios necesarios |
Este es un formato de registro sugerido, no una plantilla ni un adjunto que Google exija. Usa las columnas como estructura, nunca las filas como datos para pegar. Anotar una comprobación correcta importa tanto como anotar un problema: es lo que te permite responder la pregunta sobre la preparación sin inventarte un problema.
Qué revisar
- Usa la sección de comentarios de las pruebas de Play Console, más cualquier canal que les hayas dado a los testers. Las valoraciones públicas de la tienda no entran aquí.
- Agrupa los comentarios por temas primero, para que un solo caso ruidoso no se convierta en todo el resumen.
- Conserva la observación concreta, ya sea citando al tester o resumiéndola con fidelidad.
- Confirma que las funciones que describes en la solicitud estaban en la compilación probada y que de verdad se usaron. Deja constancia de lo que se probó aparte o quedó fuera de esta prueba.
Fuentes: configurar una prueba abierta, cerrada o interna y guía de acceso a producción. Hay una plantilla de registro reutilizable en nuestro artículo de recuperación, y preparar respuestas precisas de acceso a producción recorre el formulario en sí.
Los hallazgos no se atendieron o la preparación no queda clara
La solicitud pregunta qué cambiaste a partir de lo que aprendiste, y Google recomienda actuar sobre los comentarios durante la prueba. En la guía que consultamos no aparece ninguna cuota de versiones, así que lo que importa es si la respuesta refleja lo que la prueba demostró.
Qué decir cuando no hubo nada que cambiar
Si las pruebas no sacaron a la luz nada que hubiera que corregir, describe los flujos que comprobaste, los dispositivos en los que se ejecutaron y los resultados, y explica a partir de ese registro tu decisión sobre la preparación. Inventarse un problema, o publicar una versión cosmética para tener un cambio que contar, debilita la respuesta.
Qué revisar
- Atiende primero los hallazgos reales, y di qué compilación llevó cada corrección.
- Conecta cada cambio con el comentario que lo provocó, para que la respuesta se lea como causa y efecto.
- Si queda abierto un problema importante, resuélvelo antes de presentar la app como lista.
Dónde falla esta respuesta
La respuesta débil dice que las pruebas fueron bien. La respuesta sólida nombra qué se comprobó, qué se encontró, qué se hizo y cómo se verificó. La respuesta concreta es más fácil de valorar.
Siguen los problemas de acceso, estabilidad o funcionamiento
Google no permite apps que fallen, se congelen o que, de cualquier otro modo, no funcionen con normalidad. La revisión también tiene que poder llegar a la app: cuando algo queda detrás de un inicio de sesión, las credenciales que funcionen y las instrucciones acompañan a la versión.
Qué revisar
- Para la compilación que enviaste, facilita credenciales de inicio de sesión para la revisión que funcionen y los pasos que hagan falta para llegar a las funciones restringidas.
- Confirma que los testers pueden instalar y abrir esa compilación. Quien siga en una prueba interna tiene que salir de ella primero.
- Ejecuta un informe previo al lanzamiento, después revisa las señales de fallos y de ANR de los flujos que usaron tus testers, y corrige lo que sea reproducible.
Qué no demuestra un informe limpio
Los informes previos al lanzamiento se ejecutan automáticamente cuando hay capacidad. Puede que hagan falta credenciales o una configuración personalizada para llegar al contenido protegido y recorrer los flujos relevantes. Un resultado automático limpio tampoco es una prueba manual. Android vitals se nutre de datos de diagnóstico de usuarios que aceptaron compartirlos, en un subconjunto de dispositivos y de versiones del sistema operativo, así que una vista que no está disponible puede reflejar que hay muy pocos datos dentro de los filtros que seleccionaste. Sus umbrales publicados de mal comportamiento tienen que ver con la calidad técnica, no con una nota de aprobado para el acceso a producción.
Fuentes: funcionalidad, contenido y experiencia de usuario, preparar tu app para la revisión, usar un informe previo al lanzamiento para detectar problemas y supervisar la calidad técnica con Android vitals.
Qué puede y qué no puede demostrar cada evidencia
Saber a qué pregunta responde cada elemento de evidencia es lo que separa un problema de testers de un problema de evidencia o de un problema de la app.
RespondeSi eras elegible para solicitar: al menos 12 testers, cada uno con la participación aceptada durante los últimos 14 días de forma continua.
No respondeSi alguno de ellos usó la app, ni si tus respuestas fueron lo bastante concretas.
RespondeCuántos usuarios abrieron la app cada día que se muestra.
No respondeCuántas veces la abrió cada persona, qué funciones usó ni qué le pareció la experiencia.
RespondeQue la vista seleccionada no tiene datos suficientes para detectar problemas con los filtros actuales.
No respondeQue la app no haya fallado. Vitals usa datos de usuarios que aceptaron compartirlos, de un subconjunto de dispositivos y de versiones, así que una vista vacía puede significar que se recogieron muy pocos datos, no que no haya pasado nada malo.
RespondeQue otro desarrollador reportó ese texto. Vale la pena leerlo para ver la forma de la decisión.
No respondeLo que se le dijo a tu propia cuenta. Los mensajes que la comunidad reproduce son anecdóticos y no pueden fijar tus tiempos.
RespondeUna observación concreta sobre la que puedes actuar y que puedes describir, con las palabras del propio tester.
No respondeSi está generalizado. Un solo comentario es una pista; el patrón entre varios testers es el hallazgo.
Qué revisar antes de volver a solicitar
Guía de Google- 1Lee las dos cosas, la decisión de Play Console y el correo al propietario de la cuenta, y sigue las instrucciones que se den para tu app.
- 2Completa el periodo de pruebas adicional que le hayan dado realmente a tu app, y mantén el segmento cerrado en marcha mientras tanto.
- 3Sigue resolviendo las objeciones que nombró la decisión y vuelve a solicitar con las instrucciones que aparecen en tu cuenta.
Dos conclusiones que no debes sacar
Que no aparezca una duración no es permiso para volver a solicitar de inmediato. Y una instrucción de seguir probando no es prueba de que se haya borrado el tiempo acumulado de cada tester: la guía pública que consultamos no especifica ninguna regla universal de reinicio, así que trata ambas cosas como desconocidas hasta que tu propia cuenta diga lo contrario.
Google describe la revisión posterior como algo que suele tardar siete días o menos, aunque dice que de vez en cuando puede tardar más. Eso es la revisión, no las pruebas previas. Paso a paso: cómo volver a solicitar tras una decisión de more testing required.
Fuente: siguientes pasos del acceso a producción.
Cómo mantener la interacción de los testers
Guía de GoogleGoogle dice que muchos desarrolladores reclutan entre amigos, familia, colegas, comunidades y canales sociales, y recomienda testers (verificadores en la documentación de Google en español) que representen a tus usuarios objetivo, con la variedad suficiente para sacar a la luz problemas propios de cada dispositivo.
El reclutamiento puede fallar cuando no se gestionan la participación y los comentarios: un compromiso de 14 días sin ninguna estructura alrededor compite con todo lo demás que tiene un voluntario en la semana. Tres problemas de participación y de comentarios a los que estar atento:
Dónde pierde la ventana un grupo que gestionas por tu cuenta
Fuente: requisitos de prueba de las apps, que es donde Google habla de reclutar testers. Las opciones se comparan en formas legítimas de encontrar 12 testers.
Pruebas por tu cuenta o pruebas gestionadas
Las dos vías cumplen el mismo requisito. La diferencia está en quién vigila la cuenta y persigue los comentarios durante 14 días.
| De qué depende la solicitud | Grupo por tu cuenta | Pruebas gestionadas |
|---|---|---|
| Mantener 12 testers participando durante 14 días de forma continua | Te toca vigilarlo a ti. Que alguien deje de participar puede retrasar la elegibilidad si quedan demasiado pocos testers que cumplan. | Lo vigilamos nosotros, con el grupo mantenido por encima del mínimo. |
| Dispositivos reales | Los que tengan tus voluntarios. | Dispositivos Android reales, de Android 7 a Android 17. |
| Puesta en marcha | Lo que tarde el reclutamiento. | Los testers suelen empezar en 4-6 horas. |
| Comentarios que puedes resumir | Depende por completo de cómo los recojas. | Se recogen por un solo canal y se te entregan. |
| Costo | Gratis, más tu propio tiempo durante 14 días. | Desde USD 19.99 por 12 testers. |
Ninguna de las dos vías cambia cómo se revisa la solicitud. Las pruebas gestionadas eliminan el riesgo de participación; no responden por ti las preguntas sobre los comentarios y la preparación, y nadie puede prometer una aprobación.
Soporte de pruebas
Nuestra sugerenciaSi tu diagnóstico apunta a la participación, PrimeTestLab ejecuta la prueba cerrada por ti: testers con participación aceptada, en dispositivos reales, durante los 14 días completos, mantenidos por encima del mínimo y con los comentarios en un solo lugar. Si lo que falla es un inicio de sesión roto o un problema de políticas ya nombrado, más testers no lo van a mover.
Starter
12 testers reales
$19.99
Enterprise
25 testers reales
$27.99
Professional
20 testers reales
$29.99
Esa cifra de finalización es nuestro propio registro operativo, no una tasa de aprobación de Google: la prueba gestionada mantuvo el número de testers exigido y un periodo de participación sin interrupciones hasta su fecha de cierre.
Preguntas y respuestas
¿Por qué Google Play dice «More testing required»?
Tu solicitud de acceso a producción se revisó y todavía no se aprobó, así que Google te pide que sigas probando. Entre sus ejemplos están no tener 12 testers con la participación aceptada, y testers que no interactuaron con la app durante la prueba cerrada. Lee tanto la decisión de Play Console como el correo enviado al propietario de la cuenta para ver las objeciones que se identificaron.
¿Necesito 12 testers participando durante 14 días de forma continua?
Para una cuenta personal de desarrollador creada después del 13 de noviembre de 2023, sí. Google exige una prueba cerrada con un mínimo de 12 testers que hayan aceptado participar durante al menos los últimos 14 días de forma continua. Exactamente 12 cumple, y las direcciones invitadas no cuentan hasta que cada persona acepta participar.
Un tester dejó de participar durante los 14 días. ¿Tengo que empezar de nuevo?
No necesariamente. La continuidad se mide por tester, así que quien haya mantenido su propio periodo sin interrupciones sigue contando. El periodo interrumpido en sí no cuenta, pero un tester que regresa puede volver a cumplir tras un nuevo periodo de participación de 14 días ininterrumpidos. Lo que no ocurre es la herencia: quien entra después como sustituto empieza su propio periodo en lugar de quedarse con el tiempo transcurrido del tester que se fue.
¿Qué debo responder si las pruebas no revelaron nada que corregir?
Describe los flujos que comprobaste, los dispositivos en los que se ejecutaron y los resultados, y explica a partir de ese registro tu decisión sobre la preparación. En la guía que consultamos no aparece ninguna cuota de versiones, ni nada que diga que debas publicar una actualización durante la prueba. Inventarse un problema solo debilita la respuesta.
¿Puedo volver a solicitar de inmediato tras una denegación?
Vuelve a solicitar cuando hayas corregido la causa raíz, y deja que sea tu propia preparación la que marque el momento. Algunos mensajes nombran un periodo adicional de prueba cerrada; otros solo dicen que sigas probando y no dan ninguna duración. Que no aparezca una duración no es permiso para volver a solicitar de inmediato, y la guía pública que consultamos no especifica ninguna regla universal de reinicio.
¿Cuánto tarda Google en revisar una solicitud de acceso a producción?
Google describe la revisión como algo que suele tardar siete días o menos, y dice que de vez en cuando puede tardar más. Eso cubre solo la revisión. La prueba cerrada previa son 14 días de forma continua, contados aparte, y cualquier prueba adicional que pida tu decisión va aparte otra vez.
Tu siguiente paso
Vuelve a la comprobación de cinco minutos y quédate con la primera pregunta que no pudiste responder. Corrige esa única cosa, anota lo que la prueba demostró de verdad y vuelve a solicitar con las instrucciones de tu propia cuenta. Si lo que falla es la participación y no la evidencia, consigue testers antes del siguiente intento para que la ventana no se vuelva a romper a mitad de la prueba.
En resumen
«More testing required» es una decisión sobre la prueba que ejecutaste, las respuestas que diste y si la app está lista. El mínimo es fijo y público: al menos 12 testers con la participación aceptada durante 14 días de forma continua, para una cuenta personal de desarrollador creada después del 13 de noviembre de 2023. Por encima de ese mínimo, tus respuestas deben explicar con precisión lo que la prueba demostró. Una redacción clara no sustituye unas pruebas significativas ni una app que funcione.
Documentación oficial de Google