Cómo funciona la prueba cerrada de Google Play con 12 testers y 14 días (2026)

Políticas verificadas el 27 de septiembre de 2026. Todo lo que sigue refleja la documentación publicada por Google sobre pruebas cerradas y acceso a producción a esa fecha. Donde Google no ha publicado nada, este artículo lo dice en lugar de rellenar el hueco.

Uno de los mayores cambios es el requisito de prueba cerrada con 12 testers: las cuentas personales de desarrollador afectadas deben completar una prueba cerrada que califique antes de poder solicitar acceso a producción. Alcanzar el umbral de 12 por 14 días no publica la app ni garantiza la aprobación.

Muchos desarrolladores no tienen claro por qué existe este requisito, cómo funciona el proceso ni por qué es tan difícil encontrar 12 testers fiables dispuestos a participar dos semanas completas. Este artículo lo explica todo con claridad, paso a paso, para que entiendas el proceso completo antes de lanzar tu app. Si prefieres ahorrarte el trabajo, nuestro servicio de pruebas puede encargarse de todo el proceso por ti.

¿Cuál es el requisito de prueba cerrada de Google Play en 2026?

Google lo anunció el 9 de noviembre de 2023, y la regla tal como quedó se aplica a las cuentas personales de Google Play Console creadas después del 13 de noviembre de 2023. Esas dos fechas son hechos distintos y se mezclan constantemente: el 9 es cuando Google dijo que llegaba; el 13 es la fecha límite de creación de cuenta que de verdad decide si te afecta.

Lee esa última parte con atención, porque de ahí sale casi toda la decepción con este tema. Superar el umbral no publica tu app. Desbloquea la solicitud, que Google revisa después.

Google documenta el requisito para las cuentas personales, lo que deja a las cuentas de organización fuera de su alcance declarado. Esa no es, a propósito, la misma frase que "las cuentas de organización están exentas", algo que Google nunca escribe y que resulta importante para cualquiera que haya movido una app entre tipos de cuenta. Lo tratamos como es debido en la sección de aplicabilidad de más abajo.

Google introdujo el requisito de pruebas para mejorar la calidad de las apps animando a los desarrolladores a:

• Probar antes de lanzar
• Detectar problemas y recoger comentarios
• Confirmar que la app está lista para los usuarios
• Ese mismo anuncio de noviembre de 2023 amplió por separado la verificación de desarrolladores para ayudar a frenar el malware y el fraude. Es una iniciativa distinta de la prueba cerrada.

Es decir, antes de estar en vivo, tu app debe completar:

Cuando al menos 12 testers acumulan cada uno 14 días continuos de participación, Play Console muestra la opción de solicitar acceso a producción. Google pregunta por la participación de los testers, los comentarios, los cambios hechos durante la prueba y la preparación para producción. La diversidad de dispositivos e IP son prácticas de calidad, no umbrales de revisión publicados.

¿Se aplica el requisito de los 12 testers a mi cuenta?

Ten en cuenta que el 13 de noviembre de 2023 es la fecha límite de creación de la cuenta, no el día en que Google anunció la política. El anuncio llegó el 9 de noviembre de 2023, y las dos fechas se confunden constantemente. Si tu cuenta se creó en ese intervalo, la que importa es la fecha límite.

Cuando alguien sabe que la regla le afecta, surgen constantemente dos preguntas más, y tienen respuestas distintas.

La primera es si cada app nueva necesita su propia prueba. En la práctica el requisito se aplica app por app, y los desarrolladores con cuentas afectadas cuentan que vuelven a cumplirlo en cada app nueva que publican. Lo que Google no publica es la promesa de que esto dure para siempre, y algunos Product Experts indican que el requisito puede dejar de aparecer cuando la cuenta acumula historial de publicaciones. Trátalo como un requisito a nivel de app mientras el panel lo muestre, y revisa cada app nueva en vez de darlo por hecho. Lo desarrollamos en ¿necesito 12 testers para cada app?.

La segunda es si las actualizaciones rutinarias de una app que ya tiene acceso a producción reinician el plazo. No existe ningún requisito publicado de repetir la prueba de 12 por 14 días en cada actualización normal una vez que esa app tiene acceso a producción. La revisión habitual de Play y el resto de comprobaciones de políticas de Google siguen aplicándose a cada versión.

La decisión entre cuenta personal y de organización tiene consecuencias mucho más allá de esta regla: coste, verificación y quién es el dueño legal de la ficha. Si todavía estás decidiendo, lee cuentas personales frente a cuentas de organización en Google Play antes de registrarte.

¿Cuántos testers necesito para Google Play en 2026?

La pregunta más útil es para qué sirve el requisito. Google lo planteó como una cuestión de probar, no de contar: sacar problemas a la luz, recoger comentarios, actuar sobre ellos y confirmar que la app está lista.

Así que: recluta 12 porque esa es la regla, y plantéate reclutar unos cuantos más porque las bajas son una causa habitual de que la fecha de elegibilidad se retrase. Solo lo primero es un requisito de Google.

¿Qué cuenta realmente para los 12 testers y los 14 días?

Casi todas las discusiones entre desarrolladores sobre esta regla nacen de mezclar dos etapas distintas en una. Separarlas es la diferencia entre esperar los días justos y esperar el doble.

Google indica que puede pedirte seguir probando cuando no se cumplió el requisito de testers o cuando tus testers no usaron la app durante la prueba cerrada. Son dos fallos distintos con dos soluciones distintas, y solo el primero es una cifra.

¿Los testers tienen que abrir la app todos los días?

Ninguna regla publicada lo dice. La condición numérica de Google es la continuidad de la participación, y en el requisito actual no hay por ningún lado un número de aperturas diarias, un mínimo de sesiones, un suelo de minutos al día ni un número de pantallas que cada tester deba alcanzar.

Eso no es permiso para reclutar a doce personas que instalan una vez y se olvidan. La solicitud de acceso a producción pregunta cómo usaron la app tus testers y cómo se compara ese uso con lo que esperas de usuarios reales, y Google señala la participación insuficiente como motivo por el que puede pedirte seguir probando. Así que merece la pena buscar participación, pero como cuestión de calidad y no como cuota, porque no hay ninguna cuota publicada que alcanzar.

¿Los testers necesitan dispositivos reales o direcciones IP distintas?

Ninguna de las dos cosas aparece en el requisito de prueba cerrada publicado por Google. No existe ninguna condición declarada de elegibilidad que exija que cada tester que califica use un dispositivo físico único, y ninguna fuente primaria de Google afirma que tus 12 testers necesiten 12 direcciones IP, redes, hogares o países distintos.

La afirmación sobre las IP merece en especial una etiqueta más que una respuesta. Circula mucho, incluso en respuestas de Community Product Experts, y esas respuestas a veces se contradicen entre sí. Trátala como reportada por la comunidad: está bien saber que la gente se lo cree, pero no es algo sobre lo que planificar una prueba como si Google lo hubiera escrito. Si quieres la versión larga, tratamos la cuestión de los dispositivos en emuladores y prueba cerrada y la cuestión geográfica en testers en distintos países.

¿La prueba interna cuenta para los 12?

No cuenta. El requisito de Google nombra específicamente una prueba cerrada, y describe la prueba interna como control de calidad temprano opcional. La prueba interna admite hasta 100 testers y sirve de verdad para detectar problemas antes de que los testers reales vean la versión, pero hacerla no te acerca al acceso a producción.

Hay además una trampa práctica que conviene conocer antes de empezar: una persona que participa en tu prueba interna no es elegible para la prueba cerrada hasta que se da de baja de la interna y acepta participar en el segmento cerrado. Si metiste a tus primeros testers en la interna por error, moverlos es un paso que tienes que dar a propósito.

La comparación completa, con cuándo merece la pena cada canal, está en nuestro análisis de pruebas internas, cerradas y abiertas.

Cómo funciona el plazo de 14 días cuando los testers entran tarde o se dan de baja

Si un tester se da de baja antes de que pasen los 14 días, deja de contar, y si eso te deja por debajo de 12 ya no cumples la condición que Google publica: al menos 12 testers participando durante al menos los últimos 14 días de forma continua. Como la ventana son siempre los 14 días más recientes, perder gente es lo que aleja la elegibilidad. Google no publica ningún algoritmo para esto: no hay regla documentada de que una baja devuelva a todos los demás testers al día cero, y la comprobación práctica es sencillamente cuántos testers cumplen ahora mismo la condición de continuidad. Es un motivo habitual por el que los desarrolladores no llegan a la fecha de elegibilidad que esperaban.

Añadir un correo a la lista de testers no basta. Un tester cuenta cuando acepta participar a través del enlace de la prueba con una cuenta de Google válida. Después debe instalar y probar la app a través de Google Play con esa misma cuenta. Play Console muestra cuántos testers participan, no un historial fiable persona por persona. Confirma ahí el número y lleva tus propios registros de cuándo entró cada tester si necesitas estimar tu fecha de elegibilidad.

¿Qué pasa si un tester se da de baja?

El periodo de participación de ese tester queda roto, y un periodo roto no califica. Los días que cumplió antes de la baja no se pueden sumar a los que cumpla tras volver para formar 14 días que califiquen. Si vuelve, trátalo como un periodo nuevo de 14 días desde el día en que acepta participar de nuevo.

Lo que eso te cuesta depende tanto de tu número de testers como de cuándo entraron los adicionales. Con exactamente 12, una baja te deja por debajo del mínimo. Con 20 conservas un buen margen de número, pero tu fecha de elegibilidad solo queda protegida si al menos 12 de los testers restantes tienen historiales de participación continua suficientemente antiguos. Los testers que entraron más tarde pueden proteger tu número sin proteger tu fecha original.

¿Y si un tester desinstala la app?

Desinstalar y darse de baja no son el mismo hecho, y aquí conviene ser preciso porque muchas páginas los tratan como intercambiables. Google define el criterio numérico por el estado de participación. Ninguna fuente primaria establece que una desinstalación por sí sola termine el periodo de participación de un tester ni reinicie su cuenta.

Lo que no admite duda es el efecto indirecto. Una app que no está instalada no genera uso, y un tester que desinstaló el segundo día no te deja nada que describir cuando la solicitud de acceso a producción pregunta cómo usaron la app tus testers. Persigue las reinstalaciones porque merece la pena tener esas pruebas de uso, no porque se sepa que una desinstalación rompe el recuento.

¿Actualizar la app reinicia los 14 días?

No existe ninguna regla publicada que diga que publicar una versión nueva reinicia la participación continua. Google va en la dirección contraria y considera buena práctica actualizar durante la prueba cerrada: el sentido del ejercicio es encontrar problemas y corregirlos, y la solicitud de acceso a producción pregunta qué cambiaste a raíz de ello. Subir una versión y entrar en pánico creyendo que has destruido dos semanas de avance es un miedo muy común y, según toda la documentación primaria, infundado.

La única salvedad es que esto es la ausencia de una regla publicada, no una frase explícita de Google diciendo "las actualizaciones nunca reinician el periodo". Si Play Console te dice otra cosa sobre tu app concreta, hazle caso a Play Console. Desmenuzamos la cuestión como es debido en ¿actualizar tu app reinicia la prueba cerrada?.

Por eso ha crecido la demanda de servicios de pruebas profesionales. Muchos desarrolladores prefieren contratar testers profesionales antes que perder semanas en intentos fallidos por su cuenta.

¿Cuál es la forma más rápida de conseguir 12 testers para Google Play?

Eso replantea la pregunta de forma útil. No estás comprando velocidad, estás comprando dos cosas: cuán rápido llegas a 12 participantes y qué probabilidad hay de que esos 12 sigan participando dos semanas después. Cada vía de abajo equilibra ambas cosas de forma distinta.

La propia sugerencia de Google es recurrir a tus redes personales y profesionales: amigos, familia, compañeros de trabajo y de clase, además de comunidades relevantes, seguidores en redes sociales y personas parecidas a tus futuros usuarios. Esa última parte merece tomarse en serio aunque no sea obligatoria, porque la solicitud pregunta cómo se compara el uso de los testers con lo que esperas de usuarios reales, y unos testers que no se parecen en nada a tu público hacen esa pregunta más difícil de responder.

Las indicaciones de Google sobre la prueba cerrada no dicen que los testers deban ser no remunerados. A partir de esas indicaciones publicadas, un acuerdo de pago puede ser compatible con el requisito cuando aporta pruebas y comentarios auténticos. No debe usarse para manipular valoraciones públicas, reseñas, instalaciones, posiciones ni la colocación en la tienda.

Qué aporta un servicio de pruebas gestionado

Como encontrar testers es dificilísimo, muchos desarrolladores recurren a servicios de testers en línea con usuarios de dispositivos reales dispuestos a completar el requisito de los 14 días.

Un equipo de pruebas profesional aporta:

PrimeTestLab le quita toda la complejidad a los requisitos de Google Play. Aportamos testers verificados que usan dispositivos Android reales en 120+ países. En lugar de pasarte semanas buscando y coordinando testers por tu cuenta, puedes conseguir 12 testers reales por USD 19.99 y arrancar la prueba en cuestión de horas.

El servicio de PrimeTestLab incluye actividad de los testers y comentarios durante todo el periodo de 14 días. Es nuestro estándar de servicio, no una obligación de apertura diaria publicada por Google. Con una tasa de finalización de pruebas del 99.9% en 9,800+ apps probadas, te quita el problema del reclutamiento de encima. Lee por qué conviene tener un margen de testers por encima de 12.

Así, los desarrolladores en solitario y los equipos pequeños pueden publicar apps sin pasarse las dos semanas persiguiendo gente.

Nuestro historial: 9,800+ apps probadas

PrimeTestLab ayuda a los desarrolladores a cumplir el requisito de prueba cerrada de Google con tres paquetes:

Operamos una red de testers construida para la prueba cerrada de 12 por 14 días. Datos internos de proyectos de PrimeTestLab, actualizados el 15 de agosto de 2026. Finalización de la prueba significa que un proyecto de pago completó la prueba cerrada gestionada y llegó a la fase de solicitud de acceso a producción. No significa que Google concediera el acceso a producción. Las estadísticas de servicio de abajo se basan en esos pedidos completados.

El problema de siempre:

Y resolvemos el problema del reclutamiento de inmediato. La prueba arranca en 4-6 horas, y seguimos acompañando al desarrollador (los testers siguen participando) hasta que envía la solicitud y tú nos confirmas la decisión de Google.

¿Cómo configuro la prueba cerrada de Google Play paso a paso?

¿Por qué el enlace de la prueba dice que la app no está disponible?

Es un fallo frecuente y casi siempre se debe a una de estas nueve cosas. Recorre la lista en orden en vez de saltar a las explicaciones exóticas.

1. El tester ha iniciado sesión con exactamente la cuenta de Google que invitaste, no con una segunda cuenta personal del mismo teléfono.
2. Si usaste un Grupo de Google, el tester se unió al Grupo antes de abrir el enlace de la prueba.
3. La versión está en estado Publicada, no en Borrador, En revisión ni Pendiente de publicación.
4. Han pasado varias horas desde tu primer despliegue en el canal.
5. El país del tester está incluido en la disponibilidad de la app.
6. El dispositivo del tester es compatible con el bundle que subiste.
7. El tester se dio de baja del segmento interno, si alguna vez estuvo en él.
8. Está usando el enlace de la prueba cerrada, no uno interno ni abierto.
9. Ha completado los dos pasos: aceptar participar y luego instalar desde Google Play.

Si sobrevive a los nueve, profundizamos en la app no está disponible para los testers. Para el flujo de invitación en general, consulta cómo invitar testers, y para el fallo propio de los Grupos, el Grupo de Google no funciona en la prueba cerrada.

Qué cubre de verdad una prueba con sentido

Google no publica ningún plan de pruebas, ni un calendario diario, ni una lista de cobertura, y este artículo no va a inventarse uno. Lo que sigue es nuestro plan editorial de control de calidad: una forma razonable de organizar dos semanas de pruebas reales, que ofrecemos porque "no hay cuota diaria" es cierto pero por sí solo no ayuda. Tómalo como un menú, no como un formulario de cumplimiento.

El motivo para hacer todo esto no es que Google lo cuente. Es que la solicitud del final pregunta qué hicieron los testers, qué te dijeron y qué cambiaste, y una prueba con la forma de la lista de arriba produce respuestas a las tres preguntas.

Cómo solicitar acceso a producción después de la prueba

Esta es la parte del proceso que la mayoría de los artículos se salta, y es la que realmente decide el resultado. Alcanzar el umbral es aritmética. La solicitud es un argumento escrito que tienes que construir.

Qué pregunta Google en el formulario de acceso a producción

Google publica las preguntas. Lo que no publica es un baremo de puntuación, un número de palabras, una lista de frases que suspenden, ni fórmula alguna que convierta tus respuestas en una decisión. Quien te diga que una frase concreta provoca un rechazo automático está describiendo un patrón que dedujo, no una regla escrita por Google.

Lo que sí puedes hacer es responder con registros que realmente hayas guardado. Cada pregunta de abajo se corresponde con algo que deberías poder señalar de tus propios 14 días, y ese es el verdadero motivo para tomar notas mientras la prueba avanza en lugar de reconstruirlas después.

Si la respuesta llega como una petición de más pruebas en vez de una concesión, es un resultado documentado y no un callejón sin salida, y la siguiente sección explica qué dice Google realmente que lo provoca.

Por qué Google dice "se requieren más pruebas": lo que sabemos y lo que no

Completar 14 días y que aun así te digan que sigas probando es el desenlace más desmoralizante de todo este proceso, y pasa lo bastante a menudo como para que existan hilos de foro enteros dedicados a ello. La respuesta honesta es que Google te cuenta menos de lo que querrías saber, y la reacción útil es arreglar las dos cosas que Google sí nombra antes de perseguir las que no.

Lee los dos casos de abajo como los ejemplos concretos de Google, no como la lista completa. Son las causas que conviene descartar primero porque son las únicas que alguien de fuera de Google puede señalar.

Si ahora mismo estás lidiando con un mensaje concreto de "se requieren más pruebas", desmenuzamos todo el proceso en qué hacer cuando Google pide más pruebas, y los patrones de rechazo en general en por qué se rechaza una prueba cerrada.

Para quién es este servicio

Una nota breve de confianza, no un segundo discurso de venta:

Incluye:

¿Bastan 12 testers o conviene tener más?

Conviene decir con claridad lo que los testers de más no hacen, porque muchas páginas dan a entender lo contrario. No acortan los 14 días, no sustituyen a una participación real y no garantizan el acceso a producción. Dicho esto, aquí tienes una comparación honesta de tus opciones.

Para la mayoría de los desarrolladores, el plan Starter de PrimeTestLab con 12 testers es la opción más rentable. Si quieres protección extra frente a las bajas, el plan Professional con 20 testers añade un margen de 8 testers. El plan Enterprise con 25 testers añade un margen de 13 testers y un gestor de cuenta dedicado. Si no se concede el acceso a producción tras la prueba que califica, todos los planes incluyen una repetición gratis o un reembolso completo, según nuestra Política de Reembolsos. Lo que ningún plan puede prometer es la decisión de Google en sí.

Otros requisitos que pueden bloquear un lanzamiento

La prueba cerrada es un requisito de publicación, no el único. Una app puede superar el requisito de los 12 testers y quedarse igualmente atascada por algo ajeno a las pruebas, así que conviene saber qué más hay en la cola antes de fijar una fecha de lanzamiento.

Los demás que conviene revisar en tu propia app:

• Nivel de API objetivo. Las apps nuevas y las actualizaciones deben apuntar a una versión reciente de Android, y el mínimo varía según el tipo de dispositivo. Consulta la guía del nivel de API objetivo para las cifras actuales y el proceso de prórroga.
• Política de permisos. Los permisos sensibles tienen sus propias declaraciones y plazos, y esas fechas cambian. El calendario de actualizaciones de políticas hace seguimiento de cada uno con su fecha de entrada en vigor actual.
• Declaraciones de contenido de la app. Seguridad de los datos, política de privacidad, anuncios, clasificación de contenido y público objetivo deben estar completos antes de que se despliegue una versión.
• Revisión habitual de políticas. Cada versión se revisa por sí misma, con independencia del historial de pruebas.

Mantenemos las fechas de todo esto en un único calendario de políticas en lugar de repetirlas aquí, porque los plazos que viven en varios sitios acaban descuadrándose y una de las copias termina siendo falsa.

Planes y precios

Ahórrate el trabajo de buscar testers por tu cuenta. Todos los planes incluyen lo necesario para cumplir el requisito de prueba cerrada de 14 días de Google Play. Enterprise es ahora mismo el plan promocional con mejor relación calidad-precio: incluye más testers que Professional con un descuento mayor, y por eso 25 testers pueden costar menos que 20. Si no se concede el acceso a producción tras la prueba que califica, todos los planes incluyen una repetición gratis o un reembolso completo, según nuestra Política de Reembolsos.

Preguntas frecuentes

Conclusión

Si lo haces por tu cuenta, todo el proceso se reduce a una secuencia corta. Todo lo demás en este artículo son detalles que cuelgan de uno de estos diez pasos.

1. Confirma que el panel de Play Console de la app muestra realmente el requisito.
2. Termina la configuración de la app: ficha de Play Store, declaraciones de contenido y Seguridad de los datos.
3. Publica una versión en el canal de prueba cerrada y espera a que llegue al estado Publicada.
4. Consigue que al menos 12 testers acepten participar, y confirma el número en la pestaña de testers, no en la lista de invitaciones.
5. Mantén al menos 12 participando de forma continua los 14 días completos. La fecha la marca el duodécimo que califica.
6. Haz una prueba de verdad: dales algo que hacer a los testers y anota lo que te digan.
7. Corrige los problemas reales que aparezcan y anota qué cambiaste.
8. Solicítalo desde el panel en cuanto Play Console lo ofrezca.
9. Responde el formulario con tus registros reales, no con una plantilla.
10. Toma la revisión de Google como normalmente 7 días o menos, no como algo garantizado, y sigue probando si te pide más.

La gente pierde semanas en el paso 5 por contar desde la primera invitación en lugar del duodécimo tester que califica, y en el paso 6 por tratar esas dos semanas como una espera en vez de como una prueba.

Encontrar 12 personas fiables dispuestas a mantener tu app instalada 14 días es realmente difícil. Ahí es donde entra PrimeTestLab.

Contrasta esto con Google

Este artículo separa lo que Google publica de lo que solo afirman los foros, así que deberías poder verificar la primera categoría por tu cuenta. Estas son las páginas de las que sale cada afirmación importante de arriba.

Cuando este artículo dice que Google publica algo, está en una de esas tres páginas. Cuando dice que una afirmación viene de la comunidad o no está documentada, significa que las revisamos y no estaba allí.