Internal Testing: qué es, cómo funciona y cómo configurar el track

¿Qué es Internal Testing?

Internal Testing es un track de pruebas en Google Play Console y TestFlight diseñado para distribuir builds entre los miembros del equipo de desarrollo. A diferencia de las pruebas beta abiertas, el acceso a Internal Testing está limitado a una lista de direcciones de correo electrónico aprobadas por el propietario de la cuenta de desarrollador.

La principal ventaja es el tiempo mínimo de entrega del build a los evaluadores. En Google Play, Internal Testing no requiere pasar por moderación — el build aparece para los participantes en 5–15 minutos tras la subida. En App Store a través de TestFlight, el build también se entrega sin revisión previa de la App, pero está sujeto a una verificación automática de requisitos básicos de seguridad.

En qué se diferencia Internal Testing de otros tracks

Google Play tiene tres tracks de prueba: Internal Testing, Closed Beta (Open Beta) y Producción. Internal Testing es el más rápido y limitado en número de participantes (hasta 100 personas). Closed Beta admite hasta 10 000 participantes y requiere configurar una página de prueba. Producción es la etapa final con moderación completa.

Cuándo usar Internal Testing

Internal Testing se utiliza para la verificación inicial de builds antes de pasarlos a los tracks beta. Los desarrolladores suben builds diarios para el equipo de QA, verifican la integración de nuevos SDK, prueban la compatibilidad con diferentes versiones del SO e identifican errores de regresión antes de que el build sea visto por evaluadores externos.

Internal Testing en Google Play

En Google Play Console, Internal Testing es un track separado disponible en la sección Release → Testing. Para añadir un evaluador, basta con indicar su dirección de correo electrónico — el participante recibe una invitación y un enlace para unirse a través de Google Play. Los builds se suben a través de la misma interfaz que las versiones de producción.

Proceso de publicación en el track Interno

El desarrollador sube un App Bundle o APK en la sección Internal Testing de Google Play Console. El sistema verifica los requisitos básicos: firma, versión del código y compatibilidad con la API. Tras 5–15 minutos de procesamiento, el build está disponible para los evaluadores. El estado se sigue en la consola: Borrador, En revisión, Listo para probar.

// Fastlane — publicación en el track de Internal Testing
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

Gestión de evaluadores

La incorporación de participantes se realiza a través de la sección Testers en Google Play Console. Se admite la carga grupal mediante archivo CSV. Cada evaluador recibe un correo electrónico con una invitación e instrucciones de instalación. Para revocar el acceso, basta con eliminar al participante del grupo — la aplicación instalada sigue funcionando, pero no llegan nuevas actualizaciones.

Internal Testing en App Store a través de TestFlight

En el ecosistema de Apple, el rol de Internal Testing lo desempeña TestFlight, una plataforma para distribuir versiones beta. TestFlight admite hasta 100 evaluadores internos, que se añaden por correo electrónico a través de App Store Connect. Para publicar un build no es necesario pasar una revisión completa de la App, pero el build se verifica automáticamente para cumplir los requisitos mínimos.

Características de TestFlight Internal Testing

A diferencia de Google Play, donde Internal Testing no requiere moderación alguna, Apple realiza una revisión básica automática. La verificación tarda entre 30 y 60 minutos e incluye el escaneo del código binario en busca de API maliciosas y el cumplimiento de los requisitos básicos. Tras una verificación exitosa, el build está disponible para los evaluadores en un plazo de 24 horas. El build tiene una validez de 90 días.

Configuración de Internal Testing en App Store Connect

En App Store Connect, Internal Testing se configura en la sección TestFlight → Internal Testing. El propietario de la cuenta añade evaluadores por correo electrónico y asigna roles. Tras subir un build mediante Xcode o Transporter, el sistema notifica a los participantes sobre la disponibilidad de una nueva versión. Los evaluadores instalan la aplicación a través de la aplicación TestFlight en su dispositivo.

Cómo configurar un track de Internal Testing

La configuración de Internal Testing para ambas plataformas lleva de 10 a 30 minutos. A continuación se presentan instrucciones paso a paso para Google Play y App Store. El proceso no requiere cambios en el código de la aplicación — basta con una configuración única de la consola de desarrollador.

Integración con sistemas CI/CD

Ambas tiendas admiten la publicación en Internal Testing a través de API. Para la automatización se utilizan Gradle Play Publisher (Google Play) y Fastlane (ambas plataformas). El pipeline de CI/CD puede subir builds al track Interno tras cada ejecución exitosa de pruebas unitarias y pruebas de UI.

Configuración de cuentas de prueba

Para aplicaciones con autenticación, es necesario preparar cuentas de prueba y entregarlas al equipo de QA. Las cuentas deben tener acceso al entorno de prueba (staging/development) y no afectar a los datos de producción. Se recomienda crear una configuración de prueba separada de Firebase para el track Interno.

Flujo de trabajo de QA con Internal Testing

Internal Testing se integra en el pipeline de QA después de pasar las comprobaciones automáticas en CI. El desarrollador o ingeniero DevOps sube el build al track Interno, tras lo cual los ingenieros de QA reciben una notificación e instalan la actualización en los dispositivos de prueba a través de la tienda de aplicaciones.

Frecuencia óptima de publicación

Se recomienda publicar builds en Internal Testing a diario o después de cada cambio significativo en la base de código. El equipo de QA prueba los escenarios críticos: autenticación, flujo principal de usuario, integración con API y operaciones con almacenamiento local. Las pruebas de regresión se realizan en cada tercer o cuarto build.

Herramientas para recopilar comentarios

Para recopilar informes de errores, utilice la integración con sistemas de seguimiento: Jira, YouTrack, Trello o GitHub Issues. Los evaluadores envían capturas de pantalla, registros y pasos de reproducción. TestFlight admite de forma nativa la recopilación de capturas de pantalla y registros del dispositivo al agitarlo — los datos se envían al desarrollador a través de App Store Connect.

Integración con pipeline CI/CD

Para publicar builds automáticamente en el track de Internal Testing, configure un pipeline CI/CD. Tras superar las pruebas unitarias y las pruebas de UI, el script sube el build al track Interno y envía una notificación al equipo de QA. Fastlane proporciona la acción lista para usar upload_to_play_store con el parámetro track: internal. Para iOS, use Fastlane Pilot para subir a TestFlight.

Limitaciones y límites de Internal Testing

Internal Testing tiene límites estrictos en cuanto al número de participantes: hasta 100 personas en Google Play y hasta 100 evaluadores internos en TestFlight. Google Play además limita el número de grupos — máximo 1 grupo para el track Interno. App Store no limita el número de builds, pero cada build tiene un período de validez de 90 días.

Diferencias de límites entre plataformas

Google Play no limita el número de builds subidos al track Interno, pero tras 90 días de inactividad, el track puede suspenderse automáticamente. TestFlight tiene límites más estrictos: hasta 30 builds activos simultáneamente, hasta 10 000 evaluadores externos (no Internos). Para eliminar las restricciones, es necesario participar en el programa Apple Developer Enterprise.

Migración de Interno a Open Beta

Tras estabilizar el build en el track Interno, se traslada a Closed u Open Beta para pruebas con una audiencia externa. Google Play permite copiar la configuración del track y transferir el build sin necesidad de volver a subirlo. TestFlight requiere crear un track externo separado con nuevos grupos de evaluadores.

Seguridad del track de Internal Testing

Los builds en el track Interno están protegidos contra el acceso externo: solo los participantes autorizados a través de Google Play Console o App Store Connect pueden descargar la aplicación. Incluso si alguien conoce el enlace de la aplicación, un usuario no autorizado no podrá instalarla. Esto garantiza la confidencialidad de las nuevas funciones y protege la propiedad intelectual durante la fase de desarrollo.