Internal Testing: o que é, como funciona e como configurar o track

O que é Internal Testing?

Internal Testing é um track de testes no Google Play Console e TestFlight projetado para distribuir builds entre os membros da equipe de desenvolvimento. Ao contrário dos testes beta abertos, o acesso ao Internal Testing é limitado a uma lista de endereços de e-mail aprovados pelo proprietário da conta de desenvolvedor.

A principal vantagem é o tempo mínimo de entrega do build aos testadores. No Google Play, o Internal Testing não requer moderação — o build aparece para os participantes em 5–15 minutos após o upload. Na App Store através do TestFlight, o build também é entregue sem revisão prévia do App, mas está sujeito a uma verificação automática de requisitos básicos de segurança.

Como o Internal Testing difere de outros tracks

O Google Play tem três tracks de teste: Internal Testing, Closed Beta (Open Beta) e Produção. Internal Testing é o mais rápido e limitado em número de participantes (até 100 pessoas). O Closed Beta permite até 10.000 participantes e requer a configuração de uma página de teste. A Produção é a etapa final com moderação completa.

Quando usar o Internal Testing

O Internal Testing é usado para verificação inicial de builds antes de passar para os tracks beta. Os desenvolvedores enviam builds diários para a equipe de QA, verificam a integração de novos SDKs, testam a compatibilidade com diferentes versões do SO e identificam erros de regressão antes que o build seja visto por testadores externos.

Internal Testing no Google Play

No Google Play Console, o Internal Testing é um track separado disponível na seção Release → Testing. Para adicionar um testador, basta inserir o endereço de e-mail — o participante recebe um convite e um link para participar através do Google Play. Os builds são enviados através da mesma interface das versões de produção.

Processo de publicação no track Interno

O desenvolvedor envia um App Bundle ou APK na seção Internal Testing do Google Play Console. O sistema verifica os requisitos básicos: assinatura, versão do código e compatibilidade com API. Após 5–15 minutos de processamento, o build fica disponível para os testadores. O status é acompanhado no console: Rascunho, Em revisão, Pronto para testar.

// Fastlane — publicação no 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

Gerenciamento de testadores

A adição de participantes é feita através da seção Testers no Google Play Console. O upload em grupo via arquivo CSV é suportado. Cada testador recebe um e-mail com um convite e instruções de instalação. Para revogar o acesso, basta remover o participante do grupo — o aplicativo instalado continua funcionando, mas novas atualizações não chegam.

Internal Testing na App Store através do TestFlight

No ecossistema Apple, o papel do Internal Testing é desempenhado pelo TestFlight — uma plataforma para distribuir versões beta. O TestFlight suporta até 100 testadores internos, que são adicionados por e-mail através do App Store Connect. Publicar um build não requer uma revisão completa do App, mas o build é verificado automaticamente quanto aos requisitos mínimos.

Características do TestFlight Internal Testing

Ao contrário do Google Play, onde o Internal Testing não requer moderação, a Apple realiza uma revisão básica automática. A verificação leva de 30 a 60 minutos e inclui a digitalização do código binário em busca de APIs maliciosas e conformidade com requisitos básicos. Após uma verificação bem-sucedida, o build fica disponível para os testadores em 24 horas. O build é válido por 90 dias.

Configuração do Internal Testing no App Store Connect

No App Store Connect, o Internal Testing é configurado na seção TestFlight → Internal Testing. O proprietário da conta adiciona testadores por e-mail e atribui funções. Após o upload de um build via Xcode ou Transporter, o sistema notifica os participantes sobre a disponibilidade de uma nova versão. Os testadores instalam o aplicativo através do aplicativo TestFlight no dispositivo.

Como configurar um track de Internal Testing

A configuração do Internal Testing para ambas as plataformas leva de 10 a 30 minutos. Abaixo estão instruções passo a passo para Google Play e App Store. O processo não requer alterações no código do aplicativo — basta uma configuração única do console do desenvolvedor.

Integração com sistemas CI/CD

Ambas as lojas suportam a publicação no Internal Testing através de API. Para automação, são usados Gradle Play Publisher (Google Play) e Fastlane (ambas as plataformas). O pipeline CI/CD pode enviar builds para o track Interno após cada execução bem-sucedida de testes unitários e testes de UI.

Configuração de contas de teste

Para aplicativos com autenticação, é necessário preparar contas de teste e fornecê-las à equipe de QA. As contas devem ter acesso ao ambiente de teste (staging/development) e não afetar os dados de produção. Recomenda-se criar uma configuração de teste separada do Firebase para o track Interno.

Fluxo de trabalho de QA com Internal Testing

O Internal Testing é integrado ao pipeline de QA após passar pelas verificações automáticas no CI. O desenvolvedor ou engenheiro DevOps envia o build para o track Interno, após o que os engenheiros de QA recebem uma notificação e instalam a atualização nos dispositivos de teste através da loja de aplicativos.

Frequência ideal de publicação

Recomenda-se publicar builds no Internal Testing diariamente ou após cada alteração significativa na base de código. A equipe de QA testa cenários críticos: autenticação, fluxo principal do usuário, integração com API e operações de armazenamento local. Os testes de regressão são realizados a cada terceiro ou quarto build.

Ferramentas para coleta de feedback

Para coletar relatórios de bugs, use a integração com sistemas de rastreamento: Jira, YouTrack, Trello ou GitHub Issues. Os testadores enviam capturas de tela, logs e etapas de reprodução. O TestFlight tem suporte integrado para coletar capturas de tela e logs do dispositivo ao agitar — os dados são enviados ao desenvolvedor através do App Store Connect.

Integração com pipeline CI/CD

Para publicar builds automaticamente no track de Internal Testing, configure um pipeline CI/CD. Após passar nos testes unitários e testes de UI, o script envia o build para o track Interno e envia uma notificação para a equipe de QA. O Fastlane fornece a ação upload_to_play_store pronta para uso com o parâmetro track: internal. Para iOS, use o Fastlane Pilot para enviar ao TestFlight.

Limitações e limites do Internal Testing

Internal Testing tem limites rigorosos quanto ao número de participantes: até 100 pessoas no Google Play e até 100 testadores internos no TestFlight. O Google Play também limita o número de grupos — máximo de 1 grupo para o track Interno. A App Store não limita o número de builds, mas cada build tem um período de validade de 90 dias.

Diferenças de limites entre plataformas

O Google Play não limita o número de builds enviados ao track Interno, mas após 90 dias de inatividade, o track pode ser suspenso automaticamente. TestFlight tem limites mais rigorosos: até 30 builds ativos simultaneamente, até 10.000 testadores externos (não Internos). Para remover as restrições, é necessária participação no programa Apple Developer Enterprise.

Migração de Interno para Open Beta

Após estabilizar o build no track Interno, ele é movido para Closed ou Open Beta para testes com um público externo. O Google Play permite copiar as configurações do track e transferir o build sem reenviá-lo. O TestFlight requer a criação de um track externo separado com novos grupos de testadores.

Segurança do track de Internal Testing

Os builds no track Interno são protegidos contra acesso externo: apenas participantes autorizados através do Google Play Console ou App Store Connect podem baixar o aplicativo. Mesmo que alguém conheça o link do aplicativo, um usuário não autorizado não poderá instalar o build. Isso garante a confidencialidade das novas funcionalidades e protege a propriedade intelectual durante a fase de desenvolvimento.