Respuesta rápida
Las pruebas internas de Google Play se configuran en Test and release › Testing › Internal testing: crea o selecciona una lista de correos de testers, crea una versión y añade tu app bundle, lánzala y después copia y comparte el enlace de la prueba. Google permite hasta 100 testers internos por app, y puedes empezar antes de terminar de configurar la app. Un tester solo pasa a ser elegible cuando está en la lista configurada y además ha aceptado participar en la prueba: añadir una dirección de correo hace que esa cuenta sea elegible para el canal, pero por sí sola no da acceso. La prueba interna es opcional y no cuenta para el requisito de acceso a producción de Google: ese exige de forma expresa una prueba cerrada (closed testing) con al menos 12 testers que hayan aceptado participar de forma continua durante 14 días. La prueba interna sirve para hacer QA privado rápido, pero el requisito de acceso a producción se cumple en el canal de prueba cerrada y en ningún otro sitio.
La prueba interna es el único canal de Play Console que se comporta como un desarrollador espera que se comporte el software: subes una versión, aparece y la gente la instala. Hasta que deja de hacerlo. Entonces te quedas mirando un enlace que abre una página de Play Store diciendo que la app no está disponible para tu cuenta, sin código de error, sin diagnóstico, y con un artículo de ayuda que mezcla los tres canales de prueba a lo largo de varios cientos de líneas. Este artículo separa el canal interno de los otros dos, te da la ruta de la consola y las reglas de las listas de testers en el orden en que realmente las necesitas, y luego dedica tiempo de verdad a la familia de fallos que llena los hilos de soporte. Donde las propias páginas de Google se contradicen entre sí, y en los tiempos claramente lo hacen, aquí verás las dos lecturas y no solo la que conviene. Todo lo que sigue está vigente a fecha de 12 de agosto de 2026.
Tabla de contenidos
¿Cómo se configuran las pruebas internas?
Respuesta corta
Ve a Test and release › Testing › Internal testing, arma una lista de correos de testers, añádela al canal junto con una dirección para comentarios, crea una versión a partir de un app bundle válido, lánzala y después copia el enlace para testers y repártelo tú mismo. Seis pasos, y el último no te toca a ti: cada tester tiene que aceptar participar. Todo esto se puede hacer antes de terminar la ficha de tu tienda.
Antes de empezar
Prepara la app, la compilación, las cuentas de los testers y tu propio acceso a Play Console. Fíjate en lo que no hace falta: una ficha de tienda terminada, capturas, una clasificación de contenido o un formulario de seguridad de los datos completado. Google permite explícitamente ejecutar una prueba interna antes de terminar de configurar la app. Verificado
-
01
Una app que exista en Play Console Creada, no necesariamente rellenada. El primer artefacto que subas fija el nombre del paquete de esa app y ya no se puede cambiar, así que asegúrate de que el applicationId sea el que piensas conservar.
-
02
Un app bundle válido La redacción de Google es "un app bundle válido". Ese es el único requisito de artefacto para poner una versión interna temprana en manos de los testers.
-
03
Las direcciones de correo de los testers Cuentas de Google. La ayuda vigente especifica una cuenta de Google con Gmail, o una cuenta de Google Workspace. Recoge la dirección exacta con la que cada persona va a iniciar sesión, porque esa es la identidad a la que está atado todo el canal.
-
04
El acceso a Play Console para hacerlo Los propietarios y los administradores ya lo tienen. Un usuario delegado necesita permiso para lanzar apps a los canales de prueba, y gestionar el canal y sus listas de testers puede requerir el permiso aparte para administrar canales de prueba y editar listas de testers. Un botón de lanzamiento ausente o en gris es un problema de acceso, no de compilación.
-
05
Play App Signing, solo en la primera versión Para la primera versión de una app, Play Console te lleva por la configuración de Play App Signing. Es un paso único que te vas a encontrar durante la subida y no algo que tengas que preparar antes, pero conviene saber que viene antes de empezar.
Paso 1: abre el canal de pruebas internas
Selecciona tu app y después ve a Test and release › Testing › Internal testing. Google documenta esta ruta de dos formas distintas. El artículo de ayuda de Play Console sobre cómo montar una prueba la abrevia a Testing › Internal testing, mientras que otra página de ayuda vigente muestra el menú padre completo. Las dos describen el mismo destino, así que si tu consola enseña un menú más corto que el escrito aquí, no estás en el sitio equivocado.
La navegación es lo más perecedero de esta página. Los agrupamientos de menús y las etiquetas de los botones de Play Console cambian sin ningún cambio de política detrás. La ruta completa de arriba se contrastó con la ayuda en vivo de Google el 12 de agosto de 2026. Todas las reglas del resto del artículo sobreviven a un cambio de nombre en el menú; la ruta de clics es la parte que conviene verificar en tu propia consola.
Paso 2: crea tu lista de testers internos
Abre la pestaña Testers del canal de pruebas internas y elige Create email list. Ponle nombre a la lista, añade las direcciones, guarda los cambios y después crea la lista. Las direcciones se pueden escribir directamente en la interfaz separadas por comas, o subirse en un CSV. La vía del CSV es donde las listas se destruyen en silencio, porque arrastra tres reglas que están documentadas una sola vez y nunca se repiten.
Tres reglas del CSV que rompen listas de testers
Una dirección por línea y sin comas. El formato separado por comas es del campo de texto de la interfaz, no del archivo. Subir sobrescribe. Un CSV subido reemplaza las direcciones que ya había en esa lista en lugar de sumarse a ellas, así que una segunda subida que solo contenga a tus testers nuevos borra a los originales. Nada de UTF-8 con BOM. Play Console no acepta archivos CSV con esa codificación, que es exactamente lo que produce una hoja de cálculo cuando eliges "CSV UTF-8" al exportar. Las tres están en la respuesta 9845334 de la ayuda de Play Console. Verificado
Validador de listas de testers
Herramienta 01
Pega tu lista de testers y revísala antes de que lo haga Play Console
Plazas de testers internos
0 de 100 usadas
Google limita la prueba interna a 100 testers por app.
Esto funciona por completo en tu navegador. Nada de lo que pegues se sube, se guarda ni se envía a ningún sitio. Solo comprueba las restricciones documentadas de Play Console, y no puede decirte si una dirección es una cuenta de Google real.
Paso 3: añade la lista y un canal de comentarios
De vuelta en la pestaña Testers, selecciona la lista o las listas de usuarios que quieras usar en este canal y después dale a Google una URL o una dirección de correo para comentarios. Ese destino se les muestra a los testers en la página para aceptar participar, lo que lo convierte en la única vía integrada que tienen para avisarte de que algo está roto.
La distinción sobre la que se apoya todo el artículo
Añadir una dirección a una lista controla la elegibilidad. No es lo mismo que el tester se una. La regla de Google es que una cuenta tiene que estar incluida en la configuración de testers del canal y haber aceptado participar en ese programa de prueba antes de poder recibir versiones. Dos condiciones, en serie. Una lista llena de direcciones correctas donde nadie ha aceptado participar entrega exactamente nada. Verificado
Paso 4: crea y lanza la versión
Elige Create new release, añade tu app bundle, revísalo y lánzalo con los controles vigentes de la consola. Las variantes de Play Console difieren lo suficiente en la redacción exacta de sus botones como para que memorizar una secuencia de clics más allá de esto sea un lastre y no una ayuda, así que la instrucción se detiene donde se detiene la documentación vigente de Google.
El único paso irreversible
Subir el primer artefacto fija el nombre del paquete de esa app de Play. La redacción de Google es que en cuanto subes un artefacto el nombre del paquete queda fijado y ya no se puede cambiar. Si todavía estás decidiendo entre com.company.app y com.company.appname, decídelo antes de esta subida y no después. Verificado
Paso 5: copia y comparte el enlace de la prueba
Copia el enlace para testers y repártelo. Este es el paso que confunde a los desarrolladores desde al menos 2018, y la confusión es del todo razonable: cualquier otro sistema de invitaciones de internet manda un correo, y el flujo documentado de Google te entrega en su lugar un enlace para que lo distribuyas. No cuentes con que Play Console invite a los testers por ti.
“Copia el enlace para compartir”
Hay dos condiciones que deciden si ese enlace siquiera existe todavía. El enlace de la prueba solo se muestra cuando el estado de la app es Published. Mientras la app está en Draft o en Pending publication no hay nada que copiar, y por mucho que releas la pestaña Testers no va a aparecer ninguno. Verificado
Paso 6: cada tester acepta participar e instala
El último paso le pertenece al tester, y es el que no puedes hacer por él. Cada persona abre tu enlace con la sesión iniciada en la cuenta exacta que añadiste, acepta participar en esa página y después sigue el enlace de Play Store e instala. Hasta que eso pasa son elegibles pero no están inscritos, y los testers elegibles no reciben nada. Manda el enlace con el nombre de la cuenta que invitaste escrito al lado, porque aceptar participar con la identidad equivocada es uno de los fallos más reportados de este flujo y se ve exactamente igual que un enlace roto.
Quién hace qué
Esto lo haces tú
- Añadir a una lista las direcciones exactas de las cuentas de Google
- Seleccionar esa lista en la pestaña Testers
- Indicar una URL o un correo para comentarios
- Crear la versión y lanzarla
- Esperar a que el estado de la app llegue a Published
- Copiar el enlace para testers y enviárselo a cada persona
- Decirles con qué cuenta tienen que iniciar sesión
Esto solo pueden hacerlo ellos
- Abrir tu enlace con la sesión iniciada en la cuenta invitada
- Completar el paso de aceptar participar en esa página
- Seguir el enlace de Play Store desde esa página
- Instalar desde Google Play con esa misma cuenta
- Seguir participando mientras los necesites en el canal
- Encontrar la app buscando en Play. Eso no va a funcionar
- Esperar un correo de invitación. El flujo de Google no incluye ninguno
Toda la secuencia, en una tabla
| Etapa | Qué hacer en 2026 | A qué prestar atención |
|---|---|---|
| Abrir el canal | Selecciona tu app y después Test and release › Testing › Internal testing | La página general de pruebas de Google lo acorta a Testing › Internal testing. Mismo destino. |
| Crear testers | Testers › Create email list | El canal está limitado a 100 testers por app. |
| Rellenar la lista | Escribe las direcciones separadas por comas, o sube un CSV | CSV: una dirección por línea y sin comas. La subida sobrescribe lo que ya hubiera. UTF-8 con BOM se rechaza. |
| Activar la lista | Guárdala y créala, y después selecciónala en Testers | Estar en la lista no es lo mismo que haber aceptado participar. |
| Comentarios | Indica una URL o una dirección de correo para comentarios | Se les muestra a los testers en la página para aceptar participar. |
| Crear la versión | Create new release, añade un app bundle válido | Puedes hacerlo antes de terminar de configurar la app. El primer artefacto fija el nombre del paquete para siempre. |
| Lanzar | Revisa la versión y lánzala | La disponibilidad de la versión y la propagación del enlace son dos relojes distintos. |
| Invitar | Copia el enlace para testers y compártelo | La distribución te toca a ti. No les digas a los testers que busquen la app. |
| El tester se une | Abre el enlace con la cuenta invitada y acepta participar | La elegibilidad necesita la configuración de testers y la aceptación de participar. |
| Instalar | Sigue el enlace de Play Store e instala | La app no se puede encontrar por la búsqueda de Play antes de llegar a prueba abierta o a producción. |
Desplaza la tabla en horizontal para ver todas las columnas
¿Cuánto tardan los testers en poder instalar?
Respuesta corta
La versión va rápido y el enlace no. Google describe las versiones internas como disponibles normalmente en segundos en una página y en minutos en otra, pero dice que un primer enlace de prueba puede tardar unas horas y que los cambios posteriores pueden tardar varias horas. Son etapas distintas, no contradicciones, y por eso "la prueba interna es instantánea" es una mala creencia justo en el momento en que te falla el enlace.
Durante una prueba interna corren cinco relojes distintos, y las quejas por los tiempos suelen venir de comparar los dos que no tocaba. Que la versión llegue al sistema de distribución de Google es una cosa. Que el enlace de la prueba que ve el tester se active es otra. Que un cambio publicado llegue a quien ya se unió es una tercera. Que una app instalada se actualice sola es una cuarta. Y que la ficha temporal de la tienda se sustituya por el nombre real de tu app es una quinta, que es la razón de que una versión interna perfectamente funcional pueda seguir pareciendo a medio hacer un par de días.
¿Mi espera ya es normal?
La única versión útil de esa pregunta incluye qué estás esperando, porque la respuesta cambia por un factor de cientos según la etapa. La herramienta de abajo te pide las dos cosas, cita lo que Google publica de verdad para esa etapa y etiqueta sus propios puntos de control numéricos como la lectura de este artículo y no como la de Google.
Reloj de propagación
Herramienta 02
Dile qué estás esperando y cuánto llevas esperando
¿Qué estás esperando?
¿Cuánto llevas esperando?
Elige qué estás esperando
Selecciona la etapa de arriba e indica cuánto tiempo llevas esperando. Sin eso no hay diagnóstico.
Google publica redacciones, no números: "unas horas" y "varias horas" no tienen una duración definida. Todos los umbrales de esta herramienta son puntos de control editoriales de esta guía, no plazos de Google ni un nivel de servicio que Google haya comprometido. Junto a cada veredicto verás la redacción exacta de Google para que juzgues la lectura por tu cuenta.
Todos los relojes, uno al lado del otro
| Evento | Qué dice Google ahora mismo | Cómo leerlo |
|---|---|---|
| Versión interna añadida en Play Console | Normalmente disponible en segundos | Esto es el sistema de distribución aceptando la versión, no tu tester recibiéndola. |
| App bundle nuevo en el canal interno | Disponible en minutos | Una segunda página de Google, que describe la misma etapa de forma algo más conservadora. |
| Primer enlace de prueba tras la primera publicación | Puede tardar unas horas | El número más útil de todos. No diagnostiques como roto un enlace recién creado. |
| Cambios publicados después | Pueden tardar varias horas | Las ediciones posteriores también se propagan despacio, y eso sorprende a quien vio llegar la primera rapidísimo. |
| Actualización de un tester ya instalado | Por lo general en pocos minutos una vez entregada | Rápido, pero solo después de que la versión haya llegado de verdad a esa cuenta. |
| Nombre de la app y ficha en la primera publicación | La información temporal puede mantenerse hasta 48 horas | Una versión que funciona puede seguir mostrando información de ficha provisional. No es un fallo. |
Desplaza la tabla en horizontal para ver todas las columnas
La idea editorial que conviene llevarse: segundos, minutos, unas horas y hasta 48 horas son ciertas todas a la vez, porque describen piezas distintas del mismo proceso. Cualquier artículo que las aplaste en un solo número va a engañar a alguien justo en el momento en que necesitaba precisión. Verificado
¿Una versión interna espera a la revisión de Google?
Aquí la redacción importa, porque las dos fuentes de Google no están formuladas igual. La página de producto de Google para la prueba interna la vende como una forma de distribuir versiones sin tener que esperar a las revisiones de apps. El centro de ayuda de Play Console es más suave: dice que las pruebas internas pueden no estar sujetas a las revisiones habituales de políticas y seguridad de Play.
“sin necesidad de esperar a las revisiones de apps”
Así que lo exacto es decir que la prueba interna normalmente te deja distribuir sin esperar al flujo estándar de revisión de apps, y lo inexacto es decir que las versiones internas no se revisan nunca. Google no ha prometido una exención categórica de toda revisión, y escribir que sí lo hizo es la forma en que un artículo se vuelve falso la primera vez que retienen la versión interna de alguien. Verificado, con matiz de redacción
Por qué una app que funciona puede parecer rota el primer día. En la primera publicación, los testers internos pueden recibir la app de inmediato, pero el nombre temporal de la app y la información de la ficha pueden mantenerse hasta 48 horas. Si tus testers cuentan que la app se instala bien pero muestra el nombre equivocado o una ficha vacía, eso es un comportamiento conocido de la primera publicación con un plazo documentado, no un error de configuración que haya que perseguir.
¿La prueba interna cuenta para los 12 testers?
Respuesta corta
No. A fecha de 12 de agosto de 2026, Google exige a los desarrolladores afectados una prueba cerrada con un mínimo de 12 testers que hayan aceptado participar de forma continua durante los últimos 14 días. Esa misma página de políticas de Google describe la prueba interna como opcional. Una prueba interna puede durar un año y no aportar nada al acceso a producción.
Este es el malentendido con más consecuencias de todo el tema, y se está difundiendo activamente. Al menos un artículo de 2026 muy compartido describe el requisito obligatorio como algo que se cumple en el canal de pruebas internas. La propia página de requisitos de Google dice lo contrario, con palabras que no dejan margen de interpretación.
“debe ejecutar una prueba cerrada” · “un mínimo de 12 testers” · “14 días de forma continua”
La frase que hay que recordar
La prueba interna es QA útil. No desbloquea el acceso a producción. Si vas camino de la solicitud de acceso a producción, el tiempo que pases en el canal interno es tiempo dedicado a otra cosa. Útil, pero fuera del reloj. Verificado
La regla de decisión, en una línea
Usa la prueba interna para QA privado rápido con gente de confianza. Usa la prueba cerrada cuando necesites la prueba obligatoria previa a producción. Esa es toda la regla, y es a propósito lo único que este artículo dice sobre la comparación: el desglose completo de los tres canales de pruebas (segmento de pruebas, en la consola en español latinoamericano) está en prueba interna vs cerrada vs abierta, que está hecho para esa pregunta.
| Pregunta | Prueba interna | Prueba cerrada |
|---|---|---|
| Para qué conviene usarla | QA privado rápido con testers de confianza | Una prueba controlada más amplia, y el canal obligatorio previo a producción para las cuentas afectadas |
| Límite de testers que importa aquí | Hasta 100 testers | Otro conjunto de límites. Míralo en el artículo de los canales. |
| ¿Cumple el requisito de acceso a producción? | No | Sí, con condiciones. Un canal cerrado por sí solo no lo resuelve: tiene que ser la prueba que califica de la cuenta afectada, con al menos 12 testers que hayan aceptado participar de forma continua durante 14 días |
| ¿Una misma persona puede estar en las dos a la vez? | No. Primero tiene que salir de la interna y después aceptar participar en la cerrada | |
Desplaza la tabla en horizontal para ver todas las columnas
A quién se le aplica el requisito en realidad
El requisito tiene un alcance concreto, y ahí es donde vive casi toda la confusión. La página de Google lo documenta para las cuentas personales de desarrollador que califican y que se crearon después del 13 de noviembre de 2023. Google anunció la política el 9 de noviembre de 2023, y por eso vas a ver las dos fechas citadas como punto de partida.
Con las cuentas de organización, cuidado con cómo lo cuentas. La página de requisitos de Google acota la regla a las cuentas personales; no contiene ninguna frase que diga que las cuentas de organización están exentas. La forma defendible de decirlo es que el requisito está documentado para las cuentas personales de desarrollador que califican y que la página citada no se lo impone a las cuentas de organización. Alcance inferido
Si has leído que necesitas 20 testers, ese número es historia. Google bajó el mínimo de 20 a 12 el 11 de diciembre de 2024. Algunos artículos de 2026 todavía fechan ese cambio en 2025, y los hilos de foro antiguos siguen diciendo 20. El número actual es 12, y el contexto está en por qué Google pasó de 20 testers a 12. Verificado
Participar 14 días no es lo mismo que usar la app 14 días
El umbral numérico está escrito en términos de testers (verificadores, en la documentación oficial de Google en español) que hayan aceptado participar de forma continua, no en términos de uso diario. Esa es la parte medible. Aparte, Google evalúa lo que le cuentas sobre tu prueba cuando solicitas el acceso a producción, y puede exigir más pruebas si el número de testers o la participación son insuficientes. Las páginas de la competencia colapsan esas dos cosas una y otra vez en una regla inventada sobre minutos de uso diario.
Así que el umbral es la continuidad de la participación, y la implicación se evalúa encima de eso y no en su lugar. Lo que eso significa en la práctica para una prueba en marcha está en la regla de los 14 días continuos y en el requisito de 12 testers explicado. Verificado
¿Por qué no funciona mi enlace de prueba interna?
Respuesta corta
Empieza por estas cinco causas, en este orden: la app todavía no está en Published, el tester no está en una lista seleccionada para este canal, el tester nunca completó el paso de aceptar participar, el tester tiene la sesión iniciada con otra cuenta de Google, o el enlace simplemente sigue propagándose. Solo cuando las cinco están limpias tiene sentido tratar el enlace en sí como roto.
Este es el fallo que llena los hilos de la comunidad sobre pruebas internas, y el peor documentado de todos. Los desarrolladores llegan a él habiendo hecho todo lo que Play Console les pidió, y por eso la experiencia desconcierta tanto: no hay código de error, no hay diagnóstico, y la página informa tan tranquila de que la app no está disponible para tu cuenta, como si el problema fuera la cuenta y no un síntoma. Los reportes van desde una pregunta de Stack Overflow de 2018 hasta hilos de la comunidad de desarrolladores de Google de julio de 2026, en inglés y en portugués, describiendo el mismo puñado de causas.
Lo útil es dejar de pensar en él como un enlace roto y empezar a pensarlo como un circuito. La regla de entrega de Google es una serie de condiciones, y un solo contacto abierto detiene todo lo que viene después. Cuatro estados cubren las causas que se repiten en esos reportes: no está en la lista de testers, está en la lista pero no aceptó participar, aceptó participar pero usa la cuenta de Google equivocada y está bien configurado y todavía se está propagando. El último no es un fallo en absoluto, y por eso se pierde tantísimo tiempo con él.
Encuentra la compuerta abierta
Pon cada interruptor de abajo en lo que hayas confirmado de verdad, no en lo que supones. Las compuertas están ordenadas por lo barato que resulta verificarlas, así que la primera que siga abierta es lo que conviene arreglar a continuación.
Simulador de compuertas de acceso
Herramienta 03
Pon cada compuerta en lo que de verdad se cumple y mira cuál está frenando la entrega
Cinco compuertas abiertas
Activa cada compuerta solo cuando hayas confirmado que de verdad se cumple. La primera que siga abierta es lo que hay que arreglar.
“Esta app no está disponible para tu cuenta”
El acceso del tester va atado a una identidad, no a un dispositivo ni a un enlace. Google exige que la cuenta esté incluida en la configuración de testers y que haya aceptado participar en ese programa de prueba. Si falta cualquiera de las dos mitades, Play Store no tiene forma de distinguir a esa persona de un desconocido que encontró tu URL.
El motivo de que esto aparezca tanto en la práctica es de lo más mundano: los teléfonos y los navegadores suelen tener varias cuentas de Google iniciadas, y la que abre un enlace no siempre es la que invitaste. Hilos de la comunidad de desarrolladores de Google de marzo de 2026 describen testers que no consiguen cambiar a la identidad correcta porque el selector de cuentas se comporta de forma distinta a la que esperan, y hilos en portugués de mediados de 2025 reportan el mismo patrón con una respuesta que apunta directamente a hacer coincidir la cuenta seleccionada en Google Play. Reportado por la comunidad
Lo que conviene que el tester revise, en este orden. Qué cuenta está activa en el navegador que abre el enlace de la prueba. Qué cuenta está activa en la propia app de Play Store, que es un ajuste aparte y el que de verdad manda en la instalación. Si esa dirección coincide con la que añadiste, carácter por carácter. Usa la dirección principal de la cuenta de Google que aparece en los ajustes de esa persona, y evita alias o variantes con signo más salvo que esa dirección exacta sea la que está en tu lista de testers de Play Console. Cambiar la cuenta de Play Store, o abrir el enlace en un perfil de navegador donde solo esté iniciada la sesión del tester, es la solución práctica que reporta la gente. Ese paso del perfil del navegador es una solución de la comunidad y no una recomendación documentada por Google, así que tómalo como algo que probar, no como una regla.
No hay ningún enlace de la prueba que copiar
Antes que nada, revisa el estado de la app. Google muestra el enlace de la prueba solo cuando el estado de la app es Published. En Draft o en Pending publication el enlace no está oculto ni retrasado: todavía no existe. Esta es la solución más limpia de todo el bloque de diagnóstico, porque la condición es binaria y se ve en tu propia consola. Verificado
Está publicada pero nadie la encuentra en la búsqueda de Play
Es el comportamiento esperado, no un fallo. Google afirma que una prueba interna o cerrada anterior a la prueba abierta o a producción no se puede descubrir mediante la búsqueda de Play Store. A los testers a los que les digas "busca la app en Play" les va a fallar siempre, por muy correcta que sea tu configuración, y con razón te van a decir que la app no existe.
Envía el enlace directo. Di explícitamente en el mensaje que buscar no va a funcionar, porque es lo primero que intenta cualquiera. Verificado
Algunos testers siguen en la versión antigua
Recorre tres causas en orden. Primera, la propagación: los cambios publicados después pueden tardar varias horas en llegar a los testers, así que una actualización reciente puede sencillamente no haber llegado. Segunda, los version codes: un usuario recibe el version code compatible más alto de cualquier canal para el que sea elegible. Como todo el mundo es elegible para producción, se le puede entregar un version code de producción más alto en lugar de una versión de prueba más baja, lo que produce esa situación confusa en la que tu versión interna más nueva es real, es correcta y aun así no es la que tiene el tester. Tercera, la elegibilidad de canal: una cuenta que ha aceptado participar en la prueba interna no es elegible para recibir versiones cerradas ni abiertas, así que si moviste el trabajo a otro canal, esa cuenta está mirando el equivocado. Verificado
Todo cuadra y sigue fallando
Ahora, y solo ahora, vale la pena probar los remedios de la comunidad: reiniciar el dispositivo, reiniciar Play Store, borrar la caché o los datos de Play Store, o abrir el enlace en un perfil de navegador limpio. Vienen de hilos de la comunidad de desarrolladores de Google y no de las políticas de Google, y se reportan como cosas que a alguien le funcionaron, no como comportamiento documentado. Ponerlos primero es la forma en que los desarrolladores pierden días, porque no pueden arreglar un problema de configuración y disfrazan de éxito un retraso de propagación. Reportado por la comunidad
También hay un caso límite genuino. Un hilo de la comunidad de febrero de 2026 describe un enlace de prueba interna que no funcionó nunca, y otro de mayo de 2026 reporta un error HTTP 500 en la página para aceptar participar. No hay causa raíz establecida para ninguno de los dos, e inventar una explicación técnica sería peor que admitirlo. Si tu configuración es verificablemente correcta, los plazos de propagación ya pasaron y el fallo es persistente o devuelve un error de servidor, ese es un punto razonable para escalar por el soporte de Play Console en lugar de seguir cambiando ajustes. Causa sin verificar
Del síntoma a la solución, con el grado de evidencia
| Síntoma | Causa más defendible | Solución | Evidencia |
|---|---|---|---|
| No veo ningún enlace de la prueba | La app sigue en Draft o en Pending publication |
Lleva la prueba a Published y vuelve a mirar la página Testers | Verificado |
| Esta app no está disponible para tu cuenta | Identidad de Google equivocada, no está en la lista configurada, o nunca aceptó participar | Confirma la cuenta invitada exacta, confirma que la lista está seleccionada y después completa la participación con esa cuenta | Verificado Comunidad |
| Añadí su correo y sigue sin funcionar | Estar en la lista es solo la mitad de la elegibilidad | Haz que el tester abra el enlace y se una explícitamente a la prueba | Verificado |
| Añadí testers y nunca les llegó la invitación | El flujo documentado de Google no envía la invitación por ti | Copia el enlace para testers y envíalo tú | Verificado |
| Está publicada, pero no la encuentro en la búsqueda de Play | Es lo esperable en canales internos y cerrados anteriores a lo público | Usa la URL directa de Play Store y el enlace de la prueba, nunca la búsqueda | Verificado |
| Funcionó con una cuenta pero con otra no | Cuenta o perfil de navegador equivocados, muy reportado | Abre el enlace con la sesión iniciada en la cuenta exacta del tester; si hace falta, usa un perfil de navegador o de Play que coincida | Comunidad |
| Acabo de publicar y el enlace no funciona | La propagación normal sigue en curso | Dale las pocas horas de retraso que Google declara para el primer enlace antes de escalar | Verificado |
| Publiqué una actualización y el tester ve la versión antigua | Propagación, precedencia de version code o elegibilidad de canal | Espera a que pase la propagación, revisa el version code y confirma que la cuenta sigue siendo elegible para este canal | Verificado |
| Mi tester interno no ve mi versión cerrada | La cuenta sigue participando en la prueba interna | Que salga primero de la interna y después acepte participar en la cerrada | Verificado |
| La app no está disponible en el país del tester | La segmentación por país no debería bloquear a un tester interno en circunstancias normales | Revisa identidad, lista y participación antes de tocar la distribución por países | Verificado |
| Excluí este dispositivo en Play Console | Las reglas de exclusión de dispositivos no se aplican a los testers internos | No diagnostiques a partir del ajuste de exclusión. La compatibilidad de dispositivo de siempre sí puede importar | Verificado |
| Sigue sin aparecer después de revisar cuenta y configuración | La caché o el estado local de Play Store pueden estar desactualizados | Reinicia el dispositivo o Play Store; borrar la caché o los datos de Play es un paso secundario | Comunidad |
| La página para aceptar participar devuelve HTTP 500 | Posiblemente un fallo del lado de Play. No hay causa raíz establecida | Verifica antes estado, lista, cuenta y propagación. Si persiste, usa el soporte de Play Console | Sin verificar |
| El perfil de pagos no coincide | No se puede verificar como un fallo de acceso a la prueba interna. La evidencia encontrada pertenece a otros flujos de Play | No cambies perfiles de pagos para arreglar un enlace de prueba interna | Sin verificar |
Desplaza la tabla en horizontal para ver todas las columnas
Límites y reglas que casi todos entienden mal
Respuesta corta
100 testers, cualquier país, sin reglas de exclusión de dispositivos, instalaciones gratuitas de una app de pago pero no compras gratuitas dentro de la app, sin efecto en tu valoración pública, sin visibilidad en la búsqueda de Play y sin requisitos previos de ficha. Los dos que despistan a la gente son las compras dentro de la app y la visibilidad en la búsqueda.
| Elemento | Valor vigente a fecha de 12 de agosto de 2026 |
|---|---|
| Máximo de testers internos | 100 por app |
| ¿Se puede empezar antes de terminar de configurar la app? | Sí, con un app bundle válido |
| Gestión de testers documentada en la ayuda de la consola | Lista de correos |
| ¿Hace falta una cuenta de Google? | Sí. La ayuda vigente especifica una cuenta de Gmail o de Google Workspace |
| Restricciones por país para los testers internos | Ninguna, en principio. Los testers pueden estar en cualquier lugar, incluso donde otras versiones no están disponibles |
| Reglas de exclusión de dispositivos de Play | No se aplican a los testers internos |
| Descarga de una app de pago | Gratis para el tester interno |
| Compras dentro de la app | Se cobran con normalidad salvo que el tester sea además tester de licencias |
| Efecto en la valoración pública | Los comentarios de la prueba no afectan a la valoración pública de la app |
| Se puede encontrar en la búsqueda de Play antes de la prueba abierta o de producción | No |
| ¿Una misma cuenta puede recibir la interna y la cerrada a la vez? | No. Primero tiene que salir de la interna |
| Cuenta para el requisito obligatorio de 12/14 | No. El requisito exige de forma expresa una prueba cerrada |
Desplaza la tabla en horizontal para ver todas las columnas
Prueba interna frente a internal app sharing
Son dos funciones distintas con nombres confusamente parecidos, y elegir la equivocada te cuesta una tarde. La prueba interna es el canal formal que describe todo este artículo: una versión, una lista gestionada de hasta 100 testers, la aceptación de participar y actualizaciones entregadas a través de Google Play. Internal app sharing (uso compartido interno de apps) es una herramienta de intercambio rápido que toma un APK o un app bundle ya subido y te devuelve un enlace de descarga para repartir. Tiene sus propios controles de acceso, solo que son otros: la página de Google sobre ella te deja limitar las descargas a listas de correos o abrir el enlace a cualquiera al que se lo mandes, y en ambos casos el tester primero tiene que activar internal app sharing dentro de su app de Play Store.
Canal de pruebas internas
- Una versión real en un canal real, con historial de versiones
- Hasta 100 testers, gestionados por lista de correos
- Los testers aceptan participar y después instalan y se actualizan solos desde Play
- Los version codes se comportan con normalidad: cada subida necesita uno nuevo
- La versión se puede promover después a cerrada, abierta o producción
Internal app sharing
- Subes un APK o un app bundle y obtienes un enlace para compartir
- Sin versión de canal y sin página para aceptar participar en un programa de prueba. Eliges entre dejar que descargue cualquiera con el enlace o limitarlo a listas de correos autorizadas
- Los testers tienen que activar internal app sharing en su propia app de Play Store antes de poder descargar
- Cada enlace admite un máximo de 100 descargas y caduca 60 días después de la fecha de subida
- Los version codes se pueden reutilizar, que es la razón principal para usarlo
- Se aceptan compilaciones depurables, y Google vuelve a firmar lo que subes con un certificado de internal app sharing
- Los artefactos subidos por esta vía no se pueden seleccionar después para una versión de prueba ni de producción
La regla práctica: usa internal app sharing para pasarle una versión a un compañero en los próximos diez minutos, y usa el canal de pruebas internas cuando quieras el historial de versiones, la lista de testers y una versión que puedas promover más adelante. La caducidad de 60 días es el detalle que atrapa a la gente, porque un enlace que funcionaba en un reporte de error de hace dos meses simplemente está muerto, no mal configurado. Ninguna de las dos funciones cuenta para la prueba cerrada de 12 testers. Verificado
La trampa de las compras dentro de la app
No copies la afirmación habitual de que durante la prueba interna todo es gratis. La regla de Google separa la app de lo que se vende dentro de ella. Una app de pago sí es gratuita de instalar para un tester interno. Las compras dentro de la app siguen cobrándose salvo que la cuenta de ese tester esté configurada además como tester de licencias.
Esta distinción vale dinero de verdad en una prueba con suscripciones, y al menos un artículo comparativo bien posicionado ahora mismo afirma justo lo contrario. Si tus testers están a punto de recorrer un flujo de compra, configura antes el testing de licencias o cuenta con cargos reales. Verificado
Dos cosas que no son tu problema
Buena parte de los consejos genéricos sobre pruebas internas que hay por internet te dice que arregles cosas que no pueden ser la causa, lo que te hace perder tiempo y a veces rompe una configuración que funcionaba.
Lo que se suele culpar
- "Tu tester está en el extranjero, añade su país a la lista de distribución"
- "Excluiste ese modelo de dispositivo en Play Console"
- "Tu perfil de pagos no coincide con su región"
Lo que Google dice en realidad
- Los testers internos se pueden añadir desde cualquier lugar, incluso donde la versión de producción, abierta o cerrada no está disponible
- Las reglas de exclusión de dispositivos de Play no se aplican a los testers internos. La compatibilidad de dispositivo de siempre sí puede aplicarse
- No hay ninguna fuente primaria que relacione los perfiles de pagos con el acceso a la prueba interna. Las referencias pertenecen a otros flujos de Play
Afirmaciones revisadas, con veredicto
Cada fila de abajo es una afirmación que circula por ahí sobre la prueba interna. La columna del veredicto dice lo que respaldan las fuentes primarias, no lo que suena razonable.
-
Falso
“La prueba interna cuenta como la prueba de 12 testers.” La página de requisitos de Google exige de forma expresa una prueba cerrada. Este es el error más dañino de todo el tema, porque le cuesta a la gente los 14 días enteros.
-
Desactualizado
“Todavía necesitas 20 testers.” Es historia desde el 11 de diciembre de 2024. El mínimo actual es 12.
-
Falso
“Los testers internos tienen todas las compras gratis.” Solo la app de pago en sí es gratis. Las compras dentro de la app se cobran salvo que esté configurado el testing de licencias.
-
Falso
“Si tu tester está en el extranjero, añade su país.” Google exime expresamente a la prueba interna de esa limitación de distribución.
-
Engañoso
“Tu enlace está roto si no funciona de inmediato.” El propio Google admite unas horas para un primer enlace y varias horas para los cambios posteriores.
-
Engañoso
“Los testers reciben el enlace por correo automáticamente.” El flujo documentado de Google es que el desarrollador copia el enlace para compartir y lo distribuye. No cuentes con que Play Console invite a los testers por ti.
-
Parcial
“Puedes usar un Grupo de Google para la prueba interna.” La ayuda vigente de la consola documenta listas de correos para la prueba interna y Grupos de Google para la cerrada. El recurso testers de la API de publicación admite grupos de forma más amplia, pero eso no establece cómo se comporta la consola en 2026 para este canal. Usa el método documentado de lista de correos y no planifiques contando con un grupo.
-
Parcial
“Google permite exactamente un canal interno.” La API de publicación expone el canal interno estándar como un canal único y conocido, y la ayuda documenta canales cerrados adicionales con nombre sin publicar ningún número para el interno. Di "el canal de pruebas internas estándar" en lugar de afirmar que hay un límite duro.
-
Cierto
“Puedes hacer una prueba interna antes de terminar la ficha de la tienda.” Google dice que basta con un app bundle válido para distribuir internamente antes de terminar de configurar la app.
-
Cierto
“Los comentarios de los testers de una prueba no van a dañar mi valoración pública.” Google afirma que los comentarios de los usuarios de prueba no afectan a la valoración pública de la app.
Terminar una prueba interna
Pausa el canal. Los testers se quedan con la copia que ya instalaron, pero dejan de recibir actualizaciones de prueba por ahí. Conviene saberlo antes de dar por hecho que pausar un canal borra la app del teléfono de alguien, porque no lo hace. Verificado
¿Cómo pasas una versión a prueba cerrada?
Respuesta corta
Abre el canal cerrado, crea una versión y usa Add from library para seleccionar la versión que ya subiste para la prueba interna. No hace falta recompilar ni volver a subir el mismo bundle. Después configura los testers de la prueba cerrada, revisa y lanza.
Este es el paso al que llega la mayoría después de una prueba interna exitosa, y es donde de verdad arranca el reloj del acceso a producción. La instrucción de abajo evita a propósito el guion botón por botón, porque las variantes de Play Console difieren y una ruta de clics memorizada es lo primero que se rompe.
-
01
Abre el canal de destino Ve a Test and release › Testing › Closed testing y gestiona el canal cerrado que quieras usar.
-
02
Crea una versión en ese canal Una versión cerrada es una versión propia, aunque lleve el artefacto que ya probaste.
-
03
Reutiliza el artefacto probado con Add from library Selecciona la versión que subiste durante la prueba interna en lugar de volver a subir el bundle. Esta es la parte documentada en la ayuda vigente de Google sobre versiones (respuesta 9859348). Verificado
-
04
Configura los testers de la prueba cerrada Usa los controles de testers propios del canal cerrado. Para la prueba cerrada, la ayuda vigente admite listas de correos o Grupos de Google, y esa es una diferencia real respecto al canal interno.
-
05
Revisa y lanza Después comparte el enlace de la prueba cerrada igual que compartiste el de la interna. Se aplican las mismas dos condiciones: estar en la lista y haber aceptado participar.
Sobre el atajo “Promote release”. Algunas versiones de Play Console y buena parte de las guías de la comunidad describen cómo promover una versión directamente de interna a cerrada. Es muy posible que lo tengas en tu consola. Lo que no hay es una secuencia de interna a cerrada documentada como estable en la ayuda principal vigente de Google, y por eso este artículo enseña la ruta por la biblioteca: si el atajo está ahí, úsalo, pero no te pongas a buscar un botón que tu consola quizá no tenga. Variante de interfaz reportada por la comunidad
¿Puedo quedarme con los mismos testers?
Sí como personas, no como participaciones simultáneas, y esa distinción rompe más pruebas cerradas que cualquier otra cosa en esta etapa.
Una cuenta que ha aceptado participar en la prueba interna no es elegible para recibir versiones de prueba abierta ni cerrada. La instrucción de Google es que el tester primero salga de la interna y después acepte participar en la cerrada. Así que tu grupo de QA interno, montado con tanto cuidado, sí puede convertirse en tu grupo de prueba cerrada, pero cada uno de ellos tiene que abandonar activamente el canal interno antes de poder ver nada en el cerrado.
Cómo se ve esto cuando sale mal
Promueves la versión, añades a la misma gente de confianza al canal cerrado, envías el enlace nuevo y te dicen que no ha cambiado nada o que la app no está disponible. La versión cerrada está perfecta. Sus cuentas siguen participando en la prueba interna, así que son elegibles para el canal equivocado. Mándales primero el paso para salir y después el enlace de la prueba cerrada. Verificado
| Paso | El flujo más seguro hoy |
|---|---|
| Abre el destino | Test and release › Testing › Closed testing |
| Crea la versión | Gestiona el canal cerrado y crea una versión en él |
| Reutiliza el artefacto | Elige Add from library y selecciona la versión que ya subiste |
| Configura los testers | Controles de testers del canal cerrado. Aquí se admiten listas de correos y también Grupos de Google |
| Reutilizar a la gente de interna | Añádelos y haz que cada cuenta salga de la interna antes de aceptar participar en la cerrada |
| Lanza | Revisa y lanza con los controles vigentes de la consola |
| No dependas de | Un atajo Promote release concreto. Existe en algunas variantes, pero no está documentado como ruta estable |
Desplaza la tabla en horizontal para ver todas las columnas
A partir de aquí la mecánica es otro tema: reclutar gente que se mantenga participando 14 días continuos, conseguir que se contabilicen bien y superar el cuestionario de acceso a producción. Todo eso está en cómo invitar testers a la prueba cerrada, por qué Play Console muestra 0 testers participando y el cuestionario de acceso a producción.
Dónde encaja PrimeTestLab
Respuesta corta
Aquí no. La prueba interna es un trabajo que puedes terminar esta misma tarde con el paso a paso de arriba, y pagarle a alguien por hacerlo sería raro. El paso que frena a la gente es justo el que la prueba interna no cubre: una prueba cerrada con al menos 12 testers que se mantengan participando 14 días continuos y que además usen la app mientras están ahí.
Vale la pena ser preciso con el traspaso, porque los dos canales fallan por motivos completamente distintos. La prueba interna falla por configuración: un enlace que todavía no existía, una cuenta que nunca aceptó participar, un plazo de propagación que alguien no esperó. Todo eso se arregla leyendo con atención, que es para lo que sirven los dos primeros tercios de este artículo.
La prueba cerrada falla por las personas. La condición numérica que Google publica es de al menos 12 testers participando en la prueba cerrada durante los últimos 14 días de forma continua, lo que en la práctica significa doce seres humanos que se unen y que en la segunda semana siguen ahí. Aparte de ese conteo, te interesa que esos testers instalen y usen la app en serio, porque Google pregunta por la participación, el uso de las funciones y los comentarios cuando revisa la solicitud de acceso a producción. Ninguna de las dos mitades es un problema de documentación, y por mucho que domines la consola no se arreglan. La mayoría de los desarrolladores descubre esto justo al terminar la prueba interna y darse cuenta de que el requisito no se ha movido ni un milímetro.
Hacer la prueba cerrada por tu cuenta o delegarla
| Requisito de la prueba cerrada, o factor práctico | Por tu cuenta | Gestionada |
|---|---|---|
| 12 testers como mínimo | Reclutar a 12 personas con cuenta de Google que de verdad lleguen hasta el final. Los amigos y la familia se caen por el camino. | 12 testers puestos por nosotros, ya filtrados e instruidos |
| Participando 14 días continuos | Vigilar que los 12 testers sigan participando y perseguir a quien deje de hacerlo. La condición que Google publica es la participación continua; desinstalar la app no está documentado como algo que por sí solo la termine. | El grupo se mantiene los 14 días completos y con seguimiento |
| Testers auténticos en dispositivos reales Buena práctica de testing, no una de las condiciones numéricas de Google |
El hardware que casualmente tengan tus contactos | Dispositivos reales, de Android 7 a 17 |
| Tiempo hasta empezar | Lo que tarde el reclutamiento. Suele ser la parte más lenta de todo el lanzamiento. | La prueba arranca en 4-6 horas |
| Costo | Gratis en dinero, caro en calendario y en seguimiento | Desde $19.99 por 12 testers |
| Si la prueba no sale adelante | Volver a empezar y perder otros 14 días | Repetición gratis o reembolso completo |
Desplaza la tabla en horizontal para ver todas las columnas
Starter
12 testers
$19.99
El mínimo exacto que pide Google
Professional
20 testers
$29.99
Un grupo más amplio para una prueba más ancha
Enterprise
25 testers
$27.99
Margen de sobra, por si alguien se cae
Sí, ahora mismo 25 testers cuestan menos que 20. Es una promoción, no una errata: Enterprise es el plan con el descuento más fuerte de los tres en este momento, lo que además le da el costo por tester más bajo, unos $1.12 frente a $1.50 en Professional. Los dos planes ejecutan la misma prueba cerrada; la promoción es la única razón de que el orden se invierta, y la página de precios manda si la cifra se movió desde que esto se escribió.
En 7,400+ apps de 120+ países mantenemos una tasa de éxito de 99.9% en el requisito de la prueba cerrada. Lo que no te vamos a decir es que la aprobación esté garantizada. Google revisa la solicitud de acceso a producción con sus propios criterios y puede pedir más pruebas, y quien te prometa un resultado concreto te está describiendo algo que no controla. Lo que sí nos comprometemos a cumplir es la parte que sí controlamos: si la prueba no sale adelante, tienes una repetición gratis o un reembolso completo.
Haz la prueba interna igualmente
Delegues o no la prueba cerrada, usa la prueba interna para lo que está pensada. Caza los fallos de instalación, el cierre inesperado al primer arranque y el flujo de inicio de sesión roto con un puñado de personas con las que puedas hablar directamente. Llegar a una prueba cerrada de 14 días con una app que no arranca es el único error que el calendario no puede absorber.
Preguntas frecuentes sobre la prueba interna
¿Cuántos testers puedo añadir a la prueba interna de Google Play?
Google Play permite hasta 100 testers internos por app. Las instrucciones de configuración vigentes de Google gestionan ese público mediante listas de correos de testers, que se crean en la pestaña Testers del canal de pruebas internas.
¿La prueba interna es lo mismo que internal app sharing?
No, son dos funciones distintas. La prueba interna es un canal formal de Play Console: creas una versión, gestionas una lista de hasta 100 testers y distribuyes las actualizaciones a través de Google Play. Internal app sharing (uso compartido interno de apps) es una herramienta de intercambio rápido que genera un enlace de descarga para un APK o un app bundle ya subido, permite reutilizar los version codes y acepta compilaciones depurables. No tiene versión de canal ni página para aceptar participar en un programa de prueba, pero sí tiene sus propios controles de acceso: puedes limitar las descargas a listas de correos autorizadas o dejar que descargue cualquiera que tenga el enlace, los testers primero tienen que activar internal app sharing en su app de Play Store, y cada enlace admite un máximo de 100 descargas y caduca 60 días después de la fecha de subida. Los artefactos subidos por internal app sharing no se pueden incluir después en una versión de prueba ni de producción, así que las dos funciones no son intercambiables.
¿Qué permisos de Play Console necesito para montar una prueba interna?
Los propietarios y los administradores de la cuenta normalmente ya tienen todo lo que hace falta. Un usuario delegado necesita permiso para lanzar apps a los canales de prueba si quiere crear y lanzar la versión, y gestionar la configuración del canal y las listas de testers puede exigir el permiso aparte para administrar canales de prueba y editar listas de testers. Si el botón Create new release no aparece o está en gris, revisa tu nivel de acceso antes de volver a revisar la compilación.
¿La prueba interna cuenta para los 12 testers durante 14 días?
No. A fecha del 12 de agosto de 2026, Google exige de forma explícita a las cuentas personales de desarrollador nuevas afectadas 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. Esa misma página de políticas de Google describe la prueba interna como opcional, así que una prueba interna no te acerca ni un día al acceso a producción.
Añadí testers. ¿Por qué no recibieron ninguna invitación?
Porque añadir una dirección de correo no es una invitación. Las instrucciones vigentes de Google le dicen al desarrollador que configure la lista de testers y después copie y comparta el enlace de la prueba, así que no cuentes con que Play Console invite a los testers por ti. Cada tester sigue teniendo que completar por su cuenta el paso de aceptar participar.
¿Por qué mi enlace de prueba interna dice que la app no está disponible para mi cuenta?
Lo primero es verificar cuál es exactamente la cuenta de Google. Google exige que la cuenta esté incluida en la configuración de testers del canal y que además haya aceptado participar en ese programa de prueba. Los reportes de la comunidad muestran una y otra vez que el fallo aparece cuando el navegador o la app de Play Store tiene iniciada la sesión con una cuenta de Google distinta de la que añadiste, algo muy habitual en dispositivos con varias cuentas.
¿Por qué la app se instala en el dispositivo de un tester y en el de otro no?
Revisa la compatibilidad de siempre, no solo el acceso de la cuenta. Las reglas de exclusión de dispositivos de Play no se aplican a los testers internos, pero el bundle sigue teniendo que ser compatible con la versión de Android, la arquitectura, el factor de forma y los requisitos de funciones declarados de ese dispositivo. Revisa también los version codes: un usuario recibe el version code compatible más alto de cualquier canal para el que sea elegible, y como todo el mundo es elegible para producción, se le puede entregar una versión de producción más alta en lugar de tu versión interna más baja.
¿Por qué no encuentro mi app en prueba interna buscándola en Google Play?
Puede ser lo normal. Google dice que una prueba interna o cerrada anterior a la prueba abierta o a producción no se puede descubrir mediante la búsqueda de Play, así que los testers no la encontrarán por su nombre. Comparte el enlace directo de Play Store y el enlace de la prueba en lugar de pedirle a la gente que busque.
¿Google revisa las versiones de prueba interna antes de que lleguen a los testers?
Google promociona la prueba interna como una forma de distribuir sin esperar a la revisión de apps, y dice que las versiones suelen estar disponibles muy rápido. Su centro de ayuda detallado usa una redacción más suave: dice que las pruebas internas pueden no estar sujetas a las revisiones habituales de políticas y seguridad. Trata la prueba interna como un canal que normalmente se salta la espera, no como un canal que por definición no se revisa nunca.
¿Cuánto debo esperar si el enlace de prueba interna no funciona?
Google dice en una página que las versiones internas suelen estar disponibles en segundos y en otra que en minutos, pero también que el primer enlace de una prueba puede tardar unas horas después de que publiques una prueba por primera vez, y que los cambios posteriores pueden tardar varias horas. Una versión ya puede existir en el sistema de distribución de Google mientras el enlace que ve el tester todavía se está propagando, así que no diagnostiques un enlace recién creado como roto al primer intento.
¿Puedo usar a las mismas personas en la prueba interna y después en la cerrada?
Sí como personas, no como participaciones simultáneas. Google dice que una cuenta que ha aceptado participar en la prueba interna no es elegible para recibir versiones de prueba abierta ni cerrada, y que el tester primero tiene que salir de la prueba interna y después aceptar participar en la cerrada. Saltarse ese paso es un motivo habitual de que un desarrollador crea que su versión cerrada está rota.
¿Los testers internos tienen que pagar por mi app o por las compras dentro de la app?
Una app de pago sí es gratuita de instalar para los testers internos. Las compras dentro de la app son otra cosa: a los testers se les cobra con normalidad salvo que sus cuentas estén configuradas además como testers de licencias. Varios artículos de la competencia afirman que los testers internos nunca pagan por nada, y eso es falso.
¿Cómo paso mi versión de prueba interna a prueba cerrada?
La ruta más estable en la documentación vigente de Google es abrir el canal de prueba cerrada, crear una versión y usar Add from library para seleccionar la versión que ya subiste para la prueba interna. Algunas variantes de Play Console y algunas respuestas antiguas de la comunidad muestran un atajo Promote release, pero esa secuencia concreta de botones de interna a cerrada no está documentada en la ayuda principal vigente de Google, así que la ruta por la biblioteca es la instrucción más segura.
La prueba interna funcionó bien. ¿Por qué sigo necesitando 12 testers reales?
Porque los dos canales responden preguntas distintas. La prueba interna te sirve para confirmar que la app se instala, arranca y funciona con las cuentas y los dispositivos de esa prueba. El requisito de acceso a producción es una prueba cerrada aparte, con al menos 12 testers que hayan aceptado participar de forma continua durante 14 días, y Google además evalúa lo que le cuentes sobre la participación de tus testers. PrimeTestLab aporta testers reales que aceptan participar, con dispositivos reales de Android 7 a 17, para esa prueba cerrada, desde $19.99 por 12 testers.
¿PrimeTestLab puede encargarse de la prueba cerrada que la interna no cubre?
Sí. Esa prueba cerrada es el único paso que una cuenta personal de Play nueva no se puede saltar, y es justo lo que hacemos. La prueba arranca en 4-6 horas, mantenemos una tasa de éxito de 99.9% en 7,400+ apps de 120+ países, y todos los planes van respaldados por una repetición gratis o un reembolso completo. No podemos prometerte la aprobación de Google, porque nadie fuera de Google puede.
Conclusión
En resumen
La prueba interna vive en Test and release › Testing › Internal testing, admite hasta 100 testers y se puede ejecutar antes de terminar la ficha de tu app. Arma la lista de correos, añádela al canal junto con una dirección para comentarios, lanza una versión a partir de un bundle válido y después copia el enlace de la prueba y envíalo tú mismo, porque el flujo de Google deja la distribución en tus manos. Un tester no recibe nada hasta que se cumplen las dos condiciones: estar en una lista seleccionada y haber aceptado participar con la cuenta con la que realmente tiene la sesión iniciada. Cuando un enlace falla, revisa el estado Published, la lista, la participación, la cuenta activa y por último la propagación antes de tocar nada más, y dale a un primer enlace las pocas horas que Google dice que puede necesitar. Nada de esto cuenta para el acceso a producción. Ese paso es una prueba cerrada aparte con 12 testers que hayan aceptado participar de forma continua durante 14 días, y es la única parte del proceso que una cuenta personal nueva no puede atajar. Esa prueba cerrada es la que ejecuta PrimeTestLab. Ver planes y precios →
Documentación oficial de Google
Cada dato de esta página se contrastó con estas fuentes el 12 de agosto de 2026. La navegación y las etiquetas de los botones de Play Console cambian sin que haya ningún cambio de política detrás, así que si un nombre de menú no coincide con tu consola, hazle caso a tu consola y toma las reglas, no la ruta de clics, como la parte duradera.