Sí: los últimos 14 días
Un tramo sin cortes que termina cuando solicitasGoogle cuenta tus últimos 14 días de forma continua con al menos 12 testers que aceptaron participar, terminando el momento en que solicitas acceso a producción. No es cualquier tramo de 14 días ni 14 días sumados: es una sola ventana actual y sin cortes.
14 días repartidos o sumados no cuentan.
5 días ahora, 4 la próxima semana y 5 después suman 14 en total, pero cero ventanas válidas. En cuanto tu conteo de participación aceptada baja de 12, la racha se rompe y el reloj vuelve al día uno.
Respuesta rápida
Los 14 días deben ser de forma continua y los más recientes, no 14 días repartidos o sumados. Al menos 12 testers deben mantener la participación aceptada en esa ventana sin cortes, que termina cuando solicitas acceso a producción. La regla aplica a cuentas personales de Google Play creadas después del 13 de noviembre de 2023. Un tester que acepta participar, se va y vuelve no conserva los días anteriores: el conteo se reinicia. Desinstalar no es lo mismo que dejar de participar, pero sí debilita el engagement que Google revisa. Lo prudente es reclutar más de 12 para que un abandono no te baje del mínimo.
Esta es la pregunta que más se hace sobre la regla de prueba cerrada (closed testing) de Google Play, y tropieza a desarrolladores todo el tiempo. Abajo está exactamente qué exige Google, qué reinicia el reloj y cómo proteger tu ventana de 14 días sin cortes para tener mejores chances de salir bien a la primera. Está actualizado al 30 de junio de 2026. Dos herramientas interactivas te dejan probar cualquier escenario antes de arriesgarlo en tu cuenta real.
En esta guía
¿Qué exige Google de verdad?
Respuesta corta: al menos 12 testers que aceptaron participar en tu prueba cerrada durante los últimos 14 días de forma continua. Ambos números deben cumplirse al mismo tiempo, y la ventana debe estar vigente cuando pulses Solicitar acceso a producción.
Si creaste una cuenta personal de desarrollador de Google Play después del 13 de noviembre de 2023, no puedes publicar en producción hasta completar una prueba cerrada. El requisito de Google es que tu app ejecute una prueba cerrada con al menos 12 testers que hayan, en palabras de Google, aceptado participar "durante al menos los últimos 14 días de forma continua". Solo entonces se activa el botón Solicitar acceso a producción en Play Console.
Dos números definen la regla, y funcionan juntos:
12 testers deben haber aceptado participar en tu prueba cerrada.
14 días de forma continua es el tiempo que deben mantener esa participación, terminando cuando solicitas.
El requisito aplica solo a cuentas personales creadas después del corte del 13 de noviembre de 2023. Las cuentas de organización (las que piden número D-U-N-S y verificación de negocio) están exentas, y también las cuentas personales creadas en esa fecha o antes: comparamos ambos en nuestra guía de cuenta personal vs organización. El mínimo de testers era 20. Google lo bajó a 12 el 11 de diciembre de 2024 tras el feedback de desarrolladores, pero dejó intacta la duración de 14 días, así que cualquier guía que aún te diga que busques 20 testers está desactualizada (en inglés). Esa ventana de 14 días sigue siendo el verdadero punto de fricción, y es donde vive esta guía.
¿Los 14 días deben ser los últimos 14?
Sí. La redacción de Google es "los últimos 14 días de forma continua". No es cualquier tramo de 14 días ni un total de 14: son los últimos 14, sin cortes, terminando cuando envías la solicitud de acceso a producción.
La palabra que hace el trabajo en la política es "últimos". El propio FAQ de Google cierra cualquier lectura acumulativa: el sistema no cuenta a testers que aceptaron participar, probaron menos de 14 días y luego dejaron de participar, y aunque vuelvan a aceptar para sumar dos semanas en total, esos 14 días deben ser consecutivos para contar.
En claro: no puedes coser 5 días ahora, 4 la próxima semana y 5 la siguiente. Un tester que interrumpe su participación reinicia un conteo fresco de 14 días y pierde los días anteriores. La ventana es un solo tramo sin cortes. La herramienta de abajo lo vuelve tangible: marca los días en que tuviste al menos 12 testers con participación aceptada y mira qué racha contaría Google de verdad.
Toca un día para marcarlo en verde (12 o más testers con participación aceptada ese día). La última celda es hoy: el día en que solicitas acceso a producción. Google solo cuenta tu racha más reciente sin cortes que termina ahí.
Modelo didáctico de la regla de días de forma continua, no una lectura en vivo de Play Console. Google mide la racha más reciente sin cortes con 12+ testers que aceptaron participar, terminando cuando solicitas.
Prueba el preset Días dispersos: marca 13 días sueltos, pero como nunca forman una racha sin cortes que termine hoy, la ventana que cuenta es minúscula. Esa es la trampa de lo acumulado en un clic: mucha actividad, cero racha válida.
Consecutivos vs acumulados: la distinción que confunde a todos
Los días acumulados no sirven aquí. Google no suma tus días de testing. Busca una sola racha continua, así que 17 días a trozos pueden seguir valiendo cero ventanas válidas.
Este es el modelo mental con el que casi todo desarrollador empieza, y por qué falla:
Sumar tramos interrumpidos no funciona. Cada corte descarta los días previos, así que 17 días en total pueden seguir significando cero ventanas válidas.
Una racha sin cortes de 14 días con 12+ testers, vigente cuando solicitas. Menos días en total, pero es el único patrón que cumple.
La distinción que más importa es qué patrones exactos acredita Google. Así se resuelven los escenarios comunes:
El patrón es consistente: solo un tramo sin cortes de tus últimos 14 días, con al menos 12 testers con participación aceptada todo el tiempo, satisface la regla.
¿Qué rompe la racha de 14 días?
La parte difícil de esta regla no es reclutar a 12 personas. Es mantener la ventana sin cortes durante dos semanas completas. Algunos eventos comunes reinician el reloj, y otros a los que se culpa a menudo en realidad no. Aquí separamos hechos de mitos.
Lo que de verdad rompe o detiene la racha
El conteo baja de 12
Este es el núcleo de la regla. Si se van suficientes testers y caes a 11, disparas el rechazo por no suficientes testers y necesitas una ventana fresca de 14 días cuando vuelvas a 12 o más. El fallo DIY número uno.
Un tester deja de participar de forma formal
Dejar de participar significa que el tester visita la página web de la prueba cerrada y elige salir del programa. Eso corta su participación. Si te baja de 12, se rompe la continuidad.
Pausar o despublicar el canal de pruebas
Si la prueba no está activa, no se acumulan días de participación. Pausar el release o dejar expirar el build de prueba detiene el conteo. Reanudar inicia una ventana fresca.
Se culpa a menudo, pero NO reinicia por sí solo
Subir un build o actualización nueva. La continuidad que importa es que los testers mantengan la participación aceptada, no tu version code. Una actualización controlada incluso es una señal positiva: ver nuestra guía de actualizar durante la prueba cerrada.
Un tester desinstala la app. Desinstalar no es dejar de participar de forma formal, así que el reloj técnicamente sigue. El riesgo es el engagement, no el conteo de días.
Maneja tu lista de testers con cuidado. Si quitas gente, o vuelves a subir una lista que por error deja fuera nombres, puedes bajar tu conteo de participación aceptada por debajo de 12 sin querer. Muchos desarrolladores gestionan testers con un Google Groups vinculado en lugar de re-subir listas de correo una y otra vez, justo para evitar borrados accidentales.
¿No estás seguro si una acción concreta amenaza tu ventana? Elige el escenario abajo y obtén un veredicto al instante.
¿Qué está por pasar en tu prueba?
Basado en el requisito publicado de Google (12 testers con participación aceptada × 14 días de forma continua) más experiencia reportada por desarrolladores. Pausar el canal y el canje tardío son precauciones de la comunidad, no política documentada.
Dejar de participar vs desinstalar: ¿cuál es la diferencia?
Solo dejar de participar saca a un tester de tu conteo. Desinstalar deja el reloj corriendo, pero una app sin uso no genera engagement, y Google puede rechazar por eso por sí solo.
Estas dos acciones se sienten iguales para un tester casual, pero no lo son, y la diferencia importa:
Dejar de participar (deliberado)
El tester abre el enlace de la prueba cerrada en el navegador y elige salir del programa. Eso lo saca de tu pool de participación aceptada de inmediato.
Si te baja de 12, se rompe la ventana continua y el reloj vuelve al día uno.
Desinstalar (solo borrar)
Borrar la app del teléfono. Si el tester nunca visita la página web para salir, el backend de Google aún lo trata como con participación aceptada, y el reloj de 14 días sigue avanzando.
El riesgo aquí es el engagement, no el conteo de días.
Entonces, ¿por qué no confiar solo en desinstalaciones para mantener el conteo? Porque Google no solo revisa el calendario. También mira si tus testers usaron la app de verdad durante la prueba. Google lista la falta de engagement como un motivo directo de rechazo, y muchos desarrolladores ven el mensaje "Testers were not engaged with your app during your closed test" aunque el conteo y las fechas se vean bien en papel. Un tester que instala una vez, borra la app el día dos y no vuelve no genera actividad. En papel sigues con 12. En la práctica, la revisión puede fallarte por engagement poco auténtico, uno de varios patrones que desglosamos en por qué se rechaza la prueba cerrada.
La conclusión: llegar al conteo es la barra de elegibilidad, pero el uso real y repetido a lo largo de las dos semanas es lo que favorece una revisión limpia. Testers que de verdad abren la app, recorren sus pantallas clave y vuelven durante los 14 días son lo que se ve como un proceso sano.
¿Los 12 testers deben empezar el mismo día?
No de forma estricta, pero ambas lecturas convergen en el mismo comportamiento seguro. Mantén al menos 12 testers con participación aceptada a lo largo de los mismos últimos 14 días de forma continua, con ventanas que se solapan y están vigentes cuando solicitas.
Aquí la redacción de Google es genuinamente ambigua, y conviene saberlo de antemano. Hay dos lecturas defendibles:
Cada tester necesita sus propios 14 sin cortes
Leída al pie de la letra, la política se formula por tester: descarta los días de una persona concreta si se va y vuelve. Eso sugiere que quieres 12 personas específicas que cada una haya aceptado participar durante los mismos últimos 14 días de forma continua, de modo que sus ventanas se solapen y estén vigentes cuando solicitas.
Mantén el pool en 12+ durante 14 días
En la práctica, muchos desarrolladores lo tratan como un agregado: mantener el total de testers con participación aceptada en 12 o más durante 14 días sin cortes. Bajo esa vista, podrías empezar con unos de más, perder uno o dos por el camino y seguir bien mientras el pool nunca baje de 12.
Ambas lecturas convergen en el mismo comportamiento seguro
Mantén a tus testers originales calificados con participación aceptada durante toda la ventana sin cortes, y trata a cualquier tester añadido tarde como alguien cuyo propio conteo de 14 días apenas empieza. No necesitas resolver el debate para salir bien: el enfoque conservador satisface ambas interpretaciones.
Lo que Google nunca ha documentado es si puedes canjear libremente a un tester que se fue por uno completamente nuevo a mitad de ventana sin reiniciar el reloj. Nadie puede citarte una respuesta oficial, así que la suposición conservadora es la correcta. Cuando un consejo en internet presenta el canje y seguir como un hecho, trátalo como folklore de la comunidad, no como política de Google.
Por qué 12 testers es el piso, no el objetivo
Reclutar de más es un seguro de continuidad. Doce es el mínimo que te hace elegible. No es un lugar cómodo para quedarte 14 días, porque un solo abandono el día 11 puede costarte toda la ventana.
Cuando entiendes que el riesgo real es una ventana rota, el caso para reclutar más de 12 se vuelve obvio. Si empiezas con colchón, las desinstalaciones inevitables y la persona ocasional que pierde interés no te bajan del mínimo. Así se comparan tres tamaños de pool comunes para una cuenta personal:
Tamaño del pool
Exactamente 12
Colchón ante abandonos
Ninguno: una salida rompe la ventana
Riesgo al primer intento
AltoTamaño del pool
15 a 18
Colchón ante abandonos
Algunos testers pueden irse sin problema
Riesgo al primer intento
ModeradoTamaño del pool
20 a 25
Colchón ante abandonos
Margen cómodo frente a abandonos
Riesgo al primer intento
BajoLos tres tamaños son elegibles. La única diferencia es cuánto te duele un abandono a mitad de ventana, y esa diferencia es todo el juego.
El patrón es el mismo al que llegan desarrolladores experimentados y servicios gestionados: no corras una prueba con exactamente el mínimo. Construye un margen para que el modo de fallo principal de la regla (bajar de 12 a mitad de ventana) simplemente no te pase. Hacemos el caso completo en por qué necesitas más de 12 testers.
Dos notas prácticas al armar ese pool. Primera: los 12 tienen que ser 12 personas reales y distintas con participación aceptada; no puedes ser tu propio tester en dispositivos extra para inflar el conteo. Segunda: si aún te faltan para llegar a 12, hay formas legítimas de conseguir testers que mantienen el engagement genuino.
Esta regla también se inserta en un endurecimiento más amplio de 2026 de los estándares de publicación de Google Play, así que un primer intento limpio vale más que nunca. Acertar la prueba cerrada a la primera significa que no estás reiniciando un reloj de 14 días mientras se mueven los plazos: nuestra guía de requisitos de publicación 2026 sigue el calendario completo.
La redacción exacta de Google (y por qué importa "últimos")
Si quieres el lenguaje fuente, el requisito en sí es corto. La ayuda de Play Console define el umbral de la prueba cerrada como tener testers que hayan estado:
opted-in for at least the last 14 days continuously.
Dos palabras cargan toda la regla. "Last" (últimos) significa que tiene que ser tu ventana más reciente, vigente al solicitar: no un tramo de hace un mes. "Continuously" (de forma continua) significa sin cortes: sin huecos, sin pausas, sin bajar de 12 a mitad de camino. En la práctica, eso es lo mismo que pedir 14 días consecutivos en un solo tramo actual.
El FAQ de Google cierra el atajo acumulativo de forma directa. Explica que los testers que aceptan participar, prueban menos de 14 días y luego dejan de participar no se cuentan, y que aunque un tester vuelva a aceptar para que su tiempo combinado llegue a dos semanas, esos 14 días siguen teniendo que ser de forma continua para calificar. En otras palabras, el sistema busca de forma explícita una racha sin cortes, no una suma.
Las tres piezas que deciden todo
Últimos: la ventana más reciente, vigente al solicitar
14 días: la duración completa sin cortes
De forma continua: nunca bajo 12, sin huecos
Cómo PrimeTestLab mantiene tu ventana intacta
PrimeTestLab está construido alrededor del modo de fallo exacto que crea esta regla. En lugar de dejarte reclutar desconocidos y esperar que mantengan la participación aceptada, aportamos un pool gestionado de testers humanos reales con participación aceptada en dispositivos Android reales, y mantenemos ese pool por encima del mínimo durante los 14 días de forma continua completos. Mantenemos una tasa de éxito de 99.9% en 7,400+ apps, con la prueba en línea en 4-6 horas. Así es como funciona de punta a punta.
Elige el tamaño de pool que se ajuste a tu tolerancia al riesgo. Para la mayoría de desarrolladores, el plan Enterprise es la opción sensata: 25 testers para el mayor colchón frente a una ventana rota, por solo unos dólares más que el mínimo.
Mira el desglose completo en nuestra página de precios o lee la guía completa del requisito de 12 testers. Cuando estés listo, el paquete de 12 testers te pone en marcha, y nuestro servicio de prueba cerrada detalla qué incluye.
Preguntas frecuentes
¿Puedo usar 14 días de testing no consecutivos?
No. Google exige los últimos 14 días de forma continua. Los días completados, interrumpidos y reanudados después no se suman. Los 14 días deben ser un tramo único sin cortes que termina cuando solicitas acceso a producción.
¿Qué pasa si un tester deja de participar el día 10?
Si al dejar de participar tu conteo de quienes aceptaron participar cae por debajo de 12, se rompe la ventana continua. Cuando vuelvas a tener al menos 12 testers que aceptaron participar, empieza un conteo fresco de 14 días. Correr con exactamente 12 es riesgoso, así que conviene un colchón.
¿Desinstalar la app reinicia los 14 días?
No técnicamente. Desinstalar no es lo mismo que dejar de participar de forma formal, así que el reloj sigue corriendo. Pero una app desinstalada y sin uso no genera engagement, y Google puede rechazar tu solicitud de acceso a producción si los testers no estuvieron activos durante la prueba.
¿Los 12 testers deben empezar el mismo día?
Google no exige de forma estricta la misma fecha de inicio, pero el enfoque más seguro es que tus 12 o más testers hayan aceptado participar a lo largo de los mismos últimos 14 días de forma continua, con ventanas que se solapan y están vigentes cuando solicitas.
¿Puedo agregar testers nuevos durante los 14 días?
Puedes agregar testers, pero uno añadido tarde inicia su propio conteo de 14 días desde ese momento. Google no ha documentado si un tester tardío puede sustituir a uno que se fue sin reiniciar el reloj, así que mantén a tus testers originales calificados con participación aceptada durante toda la ventana.
¿Publicar una actualización reinicia el reloj de 14 días?
No. Enviar un build nuevo a tu canal de pruebas cerradas no reinicia el conteo de días. La continuidad que importa es que los testers sigan con participación aceptada. Actualizar a mitad de prueba incluso puede ser una señal positiva, siempre que los testers pasen al build nuevo.
¿Cuánto tarda el acceso a producción después de los 14 días?
Después de solicitar, Google revisa tu prueba cerrada y el cuestionario y envía un correo al dueño de la cuenta. La revisión suele tardar 7 días o menos, aunque a veces puede demorar más. Las respuestas vagas en el cuestionario son un motivo frecuente de rechazo.
¿Esta regla aplica a cuentas de organización?
No. El requisito de prueba cerrada de 12 testers y 14 días aplica solo a cuentas personales de desarrollador creadas después del 13 de noviembre de 2023. Las cuentas de organización están exentas, al igual que las cuentas personales creadas en esa fecha o antes. En la documentación oficial de Google en español, a los testers también se les llama verificadores.
Conclusión
Resumen
Los 14 días no son acumulativos. Google solo cuenta tus últimos 14 días de forma continua con al menos 12 testers que aceptaron participar, y esa ventana debe estar sin cortes cuando solicitas acceso a producción. La forma más rápida de fallar es correr con exactamente 12 y ver cómo un solo abandono reinicia el reloj; la forma más sólida de cumplir es reclutar de más para que la ventana no se rompa y asegurarte de que tus testers usen la app de verdad durante las dos semanas. PrimeTestLab cubre ambos frentes: un pool gestionado de testers reales con participación aceptada, dimensionado para quedarse por encima del mínimo los 14 días completos, desde $19.99 con la prueba en línea en 4-6 horas. Ver planes de precios →