Não: nunca reseta
Uma atualização comum mantém o tempo de participação dos seus testadores correndoO Google não publica nenhuma regra de que criar uma nova versão reinicia o teste fechado. O requisito trata de cada testador continuar participando por 14 dias contínuos, com pelo menos 12 testadores assim quando você fizer a solicitação. O versionCode e o número de builds que você envia não fazem parte dele.
Testadores saindo do teste, de modo que menos de 12 tenham 14 dias sem interrupção.
Um testador que sai do teste e volta começa os próprios 14 dias de novo, e um substituto começa do primeiro dia. Se isso deixar menos de 12 testadores com 14 dias sem interrupção, sua solicitação espera. A atualização não é a causa.
Resposta rápida
Não. Atualizar o mesmo app na faixa de teste fechado (closed testing) em andamento não reinicia, por si só, o tempo de participação dos seus testadores. Para contas pessoais de desenvolvedor criadas após 13 de novembro de 2023, o app precisa de pelo menos 12 testadores que tenham, cada um, continuado participando nos últimos 14 dias consecutivos quando você solicitar o acesso de produção. Um testador que sai do teste começa os próprios 14 dias de novo. O Google recomenda agir com base no feedback, mas não publica um número obrigatório de versões. Se os testadores não conseguem ver um novo build, verifique a publicação, a qualificação para o lançamento e a atualização no dispositivo.
É um dos medos mais comuns no teste fechado: você está no meio da janela de 14 dias, encontra um bug e trava, com medo de que enviar a correção apague o progresso e force as duas semanas do zero. Não vai. O requisito de 14 dias observa seus testadores, não seus builds. Este guia separa o que interrompe a janela do teste fechado do que não interrompe, oferece duas ferramentas interativas para você testar qualquer ação e explica o que verificar quando os testadores não conseguem ver um novo build. A última verificação nas páginas de ajuda do Google foi em 16 de outubro de 2026.
Neste guia
Atualizar o app reseta o relógio de 14 dias do teste fechado?
Não. Esse é o medo mais comum entre desenvolvedores na janela de teste, e a resposta tranquiliza: enviar um novo App Bundle para a faixa de teste fechado existente não reinicia, por si só, o tempo de participação dos seus testadores.
O requisito de 14 dias está ligado aos seus testadores, não ao seu build. O Google mede por testador: quando você solicita o acesso de produção, pelo menos 12 testadores precisam, cada um, ter participado nos últimos 14 dias de forma contínua. O número de versão do app, quantas vezes você envia um AAB novo e o que muda nas notas da versão não fazem parte desse requisito.
Essa mesma pergunta aparece de novo e de novo na Google Play Developer Community. A Central de Ajuda do Play Console define o requisito só em termos de testadores participantes e tempo, nunca em termos de envios de build. Um Product Expert do Google deu a resposta prática diretamente numa resposta aceita da comunidade em janeiro de 2024: uma atualização durante o teste pode precisar de análise, mas não reinicia os 14 dias. Essa é a leitura de um especialista sobre a política, não uma frase da própria política.
Em dúvida sobre uma ação específica? Use o verificador abaixo: escolha o que você vai fazer e ele diz se isso afeta os 14 dias dos seus testadores.
Qual ação te preocupa?
Com base no requisito publicado da Play Console do Google (testadores inscritos × dias consecutivos) e na experiência amplamente relatada por desenvolvedores. Os dois riscos marcados pela comunidade estão identificados como tal.
O que realmente reseta o timer de 14 dias?
A janela contínua de 14 dias se entende melhor como checagem de consistência, não como contagem passiva de calendário. O Google quer ver que você manteve pelo menos 12 testadores inscritos sem interrupção. Há apenas dois gatilhos confirmados que quebram essa continuidade:
Contagem de inscritos cai abaixo de 12
Se um testador sai e você cai para 11 testadores qualificados, não pode solicitar até que um décimo segundo testador tenha 14 dias sem interrupção, e um substituto começa do primeiro dia. É por isso que rodar com exatamente 12 é arriscado.
Testadores saem formalmente do teste
Um testador sai do teste abrindo o link web do teste e escolhendo sair. Isso é diferente de desinstalar. Os 14 dias daquele testador param, e voltar faz a contagem começar de novo. Isso só atrasa sua solicitação se deixar menos de 12 testadores qualificados.
Enviar um build novo não está nessa lista. Nem corrigir um typo na ficha da loja, um testador enviar feedback, nem o app crashar no dispositivo de um testador: esse último é o ponto inteiro do teste. O simulador abaixo deixa a diferença clara: aperte o botão de update à vontade e nada se mexe; perca testadores abaixo de 12 e a sequência desaba.
O que NÃO reseta o relógio
Enviar um AAB novo na mesma faixa
Editar notas da versão ou ficha da loja
Um testador enviar feedback
O app crashar no dispositivo de um testador
Subir o versionCode ou o nome da versão
Um testador desinstalar sem sair do teste
Como envio um update para um teste fechado?
Enviar um update é o mesmo fluxo da sua primeira versão, com uma diferença importante: você cria a nova versão na mesma faixa de teste fechado em que seus testadores já estão inscritos. Você não inicia um teste novo: adiciona um build ao teste que já está rodando, e é exatamente por isso que o relógio de 14 dias continua. Aqui estão os dois passos na Play Console.
Criar uma nova versão na faixa fechada Testar e lançar > Teste > Teste fechado > Gerenciar faixa
Abra a faixa de teste fechado que você já está rodando, clique em Criar nova versão e envie o App Bundle (AAB) atualizado. Mantenha o mesmo nome de pacote e a mesma configuração de assinatura, e dê ao build um versionCode maior: mudar só o versionName não é uma atualização. Adicione notas curtas da versão descrevendo o que mudou e salve. Fique na mesma faixa; é isso que mantém os 14 dias dos seus testadores correndo.
Revisar e lançar o update Review release > Start roll-out
Siga por Avançar e Revisar versão, depois inicie o lançamento na faixa fechada. Em seguida abra a Visão geral da publicação: se houver alterações esperando, escolha Enviar alterações para revisão e, se a publicação gerenciada estiver ativada, publique você mesmo as alterações aprovadas. Uma atualização enviada pode aparecer como Em análise antes de chegar aos testadores, e o Google observa que uma mudança publicada pode levar várias horas para chegar a eles. Testadores atuais normalmente atualizam no próprio lugar, sem reinstalar e sem aceitar participar de novo.
Isso não reinicia o tempo de participação dos seus testadores. Como você lança na mesma faixa fechada em que os testadores já estão participando, os 14 dias deles seguem correndo por baixo do novo build. Você está adicionando um build, não iniciando um teste novo. Se os testadores ainda não conseguem ver o novo build, siga as verificações da próxima seção.
Por que os testadores não estão recebendo o novo build?
Primeiro verifique se o build pretendido foi publicado na faixa do testador, depois verifique a conta do testador e a versão instalada e só então o celular. Esta é uma ordem de verificação, não um ranking das causas mais comuns. Você termina quando um testador qualificado instalou o build pretendido e testou de novo a mudança; uma nova data na página da loja não basta.
Minha atualização ainda está em análise
Uma atualização enviada pode precisar de análise antes que esse build chegue aos testadores. Abra a Visão geral da publicação no Play Console e aja conforme o que ela mostra:
- Alterações ainda não enviadas: revise a lista e escolha Enviar alterações para revisão.
- Em análise: confirme que é o app, a faixa e a versão certos e siga qualquer mensagem no Console. Não envie outro build só para atualizar o status; o Google conta o tempo de análise a partir da última alteração enviada.
- Alterações prontas para publicar: a publicação gerenciada está ativada, então publique você mesmo as alterações aprovadas.
Uma versão aguardando análise e seus testadores continuando no teste são estados separados. O Google não documenta que a análise de uma atualização comum pause ou reinicie o tempo de participação dos seus testadores.
Só alguns testadores conseguem atualizar
Uma atualização publicada chega apenas aos testadores para os quais foi lançada e que estão qualificados para recebê-la. Verifique estes pontos em ordem:
- Lançamento gradual: atualizações em faixas de teste, incluindo o teste fechado, podem usar uma porcentagem de lançamento, e ela não aumenta sozinha. Em Teste fechado > Versões, abra Gerenciar lançamento para ver a porcentagem e se o lançamento está interrompido.
- Conta: o endereço na sua lista ou no seu Grupo do Google, a conta que aceitou participar e a conta conectada na Play Store precisam ser a mesma.
- Teste interno: um testador que ainda participa do seu teste interno não fica qualificado para builds do teste fechado até sair do teste interno e entrar no fechado. Isso é um reparo de inscrição, não um passo rotineiro de atualização.
- Código da versão: o Google Play instala o versionCode compatível mais alto para o qual o testador está qualificado. Mudar só o versionName não é uma atualização.
- Dispositivo: o build precisa ser compatível com o dispositivo do testador, e suas configurações de distribuição precisam incluí-lo.
A versão está disponível, mas o celular ainda tem o build antigo
Use o caminho de atualização da própria Play Store antes de mexer na inscrição do testador:
- Abra a página do app no Google Play pelo seu link do teste e toque em Atualizar se aparecer, ou vá ao seu perfil > Gerenciar apps e dispositivo > Atualizações disponíveis.
- Verifique a atualização automática: ela pode estar desativada, limitada ao Wi-Fi ou desativada só para este app.
- Verifique a conexão e o espaço livre de armazenamento, depois feche e abra de novo a Play Store.
- Só então limpe o cache da Play Store (informações do app > Armazenamento e cache > Limpar cache). Limpar o cache não publica uma versão que ainda está em análise.
Não peça que os testadores saiam do teste e entrem de novo para receber uma atualização. Sair quebra os 14 dias sem interrupção daquele testador. Desinstalar o app, limpar os dados do Google Play Services ou redefinir o celular também não faz parte de uma atualização normal.
Qual a diferença entre testadores convidados e inscritos?
Essa distinção derruba mais publicadores de primeira viagem do que qualquer outra, e é a chave para entender por que builds não importam para o relógio. O sistema do Google move os testadores por um funil, e só os estágios finais pesam.
Convidado
Você adicionou um e-mail à lista de testadores ou a um Google Group. Nada mais aconteceu ainda.
Inscrito
A pessoa abriu o link de convite, entrou com a conta Google e aceitou participar do teste. É o status que o relógio de 14 dias mede.
Instalado e ativo
Baixou o app e continua usando. Isso não muda a contagem bruta, mas é o que o Google pesa no engajamento na hora do acesso de produção.
Como a documentação do Google deixa claro, adicionar um e-mail não basta. Cada testador precisa abrir o link de convite, autenticar e se tornar testador de forma explícita antes de contar. É também por isso que uma atualização comum do app não reinicia seu progresso: seus testadores continuam participando, então os dias deles seguem contando nos novos builds. Para o passo a passo completo, veja nosso guia sobre como convidar testadores corretamente.
Dica de quem gerencia milhares de testes: organize seus testadores por um Grupo do Google em vez de uma lista estática de e-mails. O Google documenta que enviar um CSV substitui a lista anterior de testadores, então um Grupo evita apagar sem querer testadores ativos enquanto você ajusta a lista. Mas um Grupo não é garantia: a participação no Grupo continua controlando o acesso, então remover alguém do Grupo ou vincular outro Grupo muda quem está qualificado.
Qual é a redação exata do requisito do Google?
A página oficial de ajuda da Play Console, "App testing requirements for new personal developer accounts", declara com precisão:
"If you have a newly created personal developer account, you must run a closed test for your app with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously."
Google Play Console Help · answer 14151465E, em separado, no momento em que você solicita o acesso de produção:
"At least 12 testers must be opted-in to your closed test when you apply for production access. They must have been opted-in for the last 14 days continuously."
Google Play Console Help · answer 14151465O Google também deixa claro, nas próprias palavras, que os dias precisam ser consecutivos: não conta testadores que aceitaram participar, testaram por menos de 14 dias e depois saíram, e mesmo que voltem a aceitar, os 14 dias precisam ser consecutivos para contar. Essa cláusula sozinha mata o mito de que "14 dias são cumulativos", e, com a mesma importância, não diz nada sobre seus builds.
Três fatos para fixar
Enviar updates durante o teste é bom ou ruim?
É aqui que a ansiedade do desenvolvedor vira oportunidade. Enviar updates durante o teste fechado é amplamente visto como sinal positivo de engajamento. Vale separar o que o Google diz oficialmente do que a comunidade de desenvolvedores concluiu, porque as duas coisas se sobrepõem sem ser idênticas:
Continue iterando e corrigindo
A ajuda da Play Console incentiva a iteração contínua: continue usando o teste fechado enquanto corrige problemas e bugs relatados por usuários, e atualizar o app no teste fechado antes de ir para produção é "uma ótima forma de minimizar avaliações e notas de baixa qualidade".
Quando você solicita o acesso de produção, o formulário pede que descreva o engajamento recebido e o que fez com o feedback dos testadores.
Ativo vence congelado
Quem está na prática vai além: um app congelado na versão 1.0 por 14 dias sem nenhuma atividade parece um teste só para cumprir tabela, enquanto um que envia correções em resposta ao feedback parece desenvolvimento de verdade. Alguns desenvolvedores enviam duas ou três atualizações pequenas para mostrar que respondem ao feedback, mas o Google não publica nenhuma cota desse tipo (veja a seção sobre número de versões abaixo).
Isso é opinião da comunidade e inferência razoável, não uma regra publicada do Google. O Google não definiu nenhum requisito numérico do tipo "envie X atualizações".
O recado: atualizar é seguro e incentivado, e a história de engajamento que você constrói com isso pode ajudar a responder o formulário de produção. O único risco real vem do que você envia, não do ato de enviar, o que leva à única ressalva de verdade.
Preciso de duas ou três versões durante o teste fechado?
As orientações publicadas pelo Google sobre o teste fechado não definem um número mínimo de versões. Elas recomendam agir com base no feedback dos testadores e corrigir os problemas que o teste encontra, e a solicitação de acesso de produção pede que você descreva as mudanças que fez. Uma contagem de envios não faz parte do requisito.
- Manter pelo menos 12 testadores participando por 14 dias sem interrupção (requisito publicado)
Proteja a participação sem interrupção de cada testador desde o primeiro dia. - Agir com base no feedback e corrigir os problemas que o teste encontra (orientação do Google)
Mantenha um registro curto do feedback, da correção e do novo teste. - Lançar duas ou três versões aconteça o que acontecer (folclore da comunidade, sem cota publicada)
Não fabrique mudanças e não espere que um número de versões garanta a aprovação.
De onde vem esse conselho: a versão explícita mais antiga que localizamos é o palpite de um desenvolvedor, numa discussão de outubro de 2024, de que duas ou três atualizações poderiam mostrar ao Google um trabalho guiado pelo feedback. Ele foi repetido em tópicos da comunidade em poucas semanas e depois apareceu em guias como se fosse uma recomendação do Google. A fonte original é desconhecida, e desenvolvedores relatam rejeições tanto com quanto sem várias atualizações, então um número de versões não prova nada sozinho.
Se o teste encontrar um problema real, corrija, envie o build e peça que os testadores testem de novo. Se não encontrar, diga isso com honestidade quando responder ao formulário de acesso de produção. Enviar builds cosméticos enquanto uma atualização está em análise também pode empurrar seu app para trás na fila de análise, porque o Google conta o tempo de análise a partir da última alteração enviada.
Um update ruim pode resetar o relógio de forma indireta?
Sim, e essa é a ressalva que importa. Embora o ato de atualizar nunca resete o timer diretamente, as consequências de um update quebrado podem. Siga a cadeia:
Então a regra é simples: atualize à vontade, mas valide a estabilidade básica de cada build antes de enviar para a faixa fechada. E nunca rode com exatamente 12 testadores, porque uma única saída por um build ruim pode te derrubar. Um buffer de testadores acima de 12 absorve esse risco.
Leia a cadeia com atenção: a atualização não reinicia o tempo de participação de ninguém. O atraso vem de perder testadores qualificados; o build quebrado é só o que disparou as saídas. Mantenha seus builds estáveis e uma margem de testadores, e o risco indireto fica bem menor.
Os testadores precisam reinstalar ou aceitar participar de novo depois de um update?
Não. Testadores atuais que aceitaram participar e instalaram o app normalmente atualizam pelo Google Play no próprio lugar. Eles não precisam aceitar participar de novo, e você não precisa reenviar o link.
Atualizações normalmente são instaladas por cima
A ajuda da Play Console, em Set up an open, closed, or internal test (answer 9845334), deixa claro: "Once your testers have installed your app, they'll automatically be updated to use the test version within a few minutes." Os testadores seguem inscritos em cada build: sem reinstalar, sem segundo clique para aceitar participar.
Uma ressalva de tempo da mesma página do Google: quando você publica mudanças adicionais, elas "may not be available for testers for several hours" antes do update automático no dispositivo. Mas o status de inscrição dos testadores, que é o que o relógio de 14 dias mede, segue em cada AAB novo. É exatamente por isso que um update de build não reseta o relógio: os testadores nunca saíram.
Exceção importante Novas permissões podem interromper o update silencioso
Um tipo de build não sempre rola em silêncio: um update que adiciona uma permissão perigosa (sensível) nova, como ACCESS_FINE_LOCATION, câmera ou microfone. Dependendo da permissão e do target API level, o Google Play pode mostrar um botão Update que o testador precisa tocar e aprovar à mão em vez de instalar em segundo plano, e quem ignora fica no build antigo. Mesmo quando instala em silêncio, a permissão nova só é concedida em runtime, então um recurso que depende dela pode parecer quebrado até o testador permitir.
Num teste fechado isso é uma armadilha silenciosa: envie no meio do teste uma atualização cheia de permissões e alguns testadores podem continuar no build antigo ou encontrar um recurso bloqueado até concederem a permissão. Uma nova permissão de alto risco também pode exigir uma declaração de permissões no Play Console antes que o build possa sequer ser publicado. O consentimento no celular e a declaração no Console são verificações separadas.
Antes de lançar no meio do teste: compare as permissões do manifesto novo com o build ao vivo. Se o conjunto de permissões mudou, avise os testadores para abrir a Play Store e atualizar manualmente (e conceder o novo prompt), e reserve margem para uma possível revisão de declaração.
Mitos comuns do teste fechado, desmentidos
A maior parte do pânico em torno de atualizar se resume a um punhado de mitos. Aqui estão os cinco que mais roubam o sono de desenvolvedores, com o que é verdade de fato:
Mito 1"Criar uma nova versão reseta o relógio."
Mito 2"Desinstalar é o mesmo que sair do teste."
Mito 3"Os 14 dias são cumulativos."
Mito 4"Exatamente 12 testadores bastam."
Mito 5"Os testadores precisam usar o app todos os dias."
O que reseta o relógio e o que não reseta
Aqui está a pergunta inteira numa tela. Salve, tire print ou envie para quem no time continua perguntando. Tudo ligado ao build é seguro; só o que mexe na contagem de testadores não é.
| Ação | Reseta o relógio de 14 dias? |
|---|---|
| Enviar um AAB novo na mesma faixa fechada | Não |
| Editar notas da versão ou metadados da ficha | Não |
| Um testador enviar feedback | Não |
| O app crashar no dispositivo de um testador | Não |
| Um testador desinstalar (sem sair do teste) | Não* |
| Contagem de inscritos cair abaixo de 12 | Sim |
| Um testador sair formalmente pelo link web | Sim** |
| Enviar build quebrado que gera saídas abaixo de 12 | Indiretamente |
| Pausar a faixa de teste fechado | Risco relatado |
| Sobrescrever a lista e omitir testadores ativos | Risco relatado |
* Não é uma saída do teste, mas um testador sem o app instalado não está testando. ** Só se deixar menos de 12 testadores qualificados. "Sim" aqui significa que a data mais cedo para solicitar se afasta: os testadores que ficaram mantêm os seus dias, mas um substituto começa do primeiro dia. O Google documenta que enviar um CSV substitui a lista anterior e que pausar um teste interrompe as atualizações dele; como os dias são contados depois disso não está documentado, então trate as duas últimas linhas como "não arrisque".
Como o requisito mudou com o tempo
Se você está lendo tutoriais antigos, é por isso que os números não batem. A duração sempre foi 14 dias consecutivos; só a contagem de testadores se moveu.
Antes de novembro de 2023 não havia teste fechado obrigatório para chegar à produção. Você podia publicar sem recrutar testadores.
O Google anunciou o requisito em 9 de novembro de 2023. Contas pessoais criadas após 13 de novembro de 2023 precisavam rodar um teste fechado com 20 testadores participantes por 14 dias contínuos. Contas organizacionais ficavam isentas.
Em 11 de dezembro de 2024 o mínimo caiu de 20 para 12, com a duração de 14 dias inalterada. Contas organizacionais seguem isentas.
Qualquer guia que ainda diga para recrutar 20 testadores está desatualizado. Cobrimos a mudança em detalhe em o que mudou de 20 para 12 testadores.
Mudanças de política de 2026 que você deve conhecer
O teste fechado não existe no vácuo. Alguns prazos de 2026 podem cruzar com seu cronograma de lançamento: nenhum muda como o relógio de 14 dias funciona, mas podem colidir com a janela se você não olhar o calendário:
Prazos de 2026 que cruzam com seu cronograma
Datas conforme a ajuda da Google Play Console (target API level) e o Android Developers Blog (developer verification). O timing da verificação é faseado e pode se expandir em 2026-2027, então confirme nas páginas oficiais antes de planejar em cima delas. Nosso guia de requisitos de publicação 2026 acompanha a lista completa.
Como a PrimeTestLab mantém o relógio rodando
A parte mais difícil do teste fechado não é entender as regras; é manter 12 ou mais pessoas reais inscritas e engajadas por 14 dias seguidos enquanto você itera. É exatamente para isso que a PrimeTestLab existe. Fornecemos testadores em dispositivos reais, que aceitam participar, e guiamos a configuração na Play Console para o relógio começar limpo e seguir enquanto você envia correções. Veja o serviço de teste fechado do Google Play completo. Mantemos taxa de sucesso de 99,9% em mais de 12.100 apps, com teste ao vivo em 4-6 horas.
Você adiciona nossos testadores no Play Console, compartilha a URL do teste, e os 14 dias começam. Daí em diante você pode enviar atualizações quando precisar; os testadores continuam participando enquanto você itera.
Um plano acima do mínimo de 12 testadores dá a você testadores extras que começam no mesmo dia, então uma saída, inclusive uma causada por um build ruim, não deixa você abaixo de 12. A margem só ajuda se esses testadores aceitarem participar cedo: um substituto tardio começa os próprios 14 dias. Os preços são por app, mais 5% de taxa de serviço (mínimo de $1.50) na finalização do pedido.
Perguntas frequentes
Posso atualizar o app no teste fechado sem reiniciar os 14 dias?
Sim. Uma atualização comum do mesmo app na faixa de teste fechado em andamento não reinicia, por si só, o tempo de participação dos testadores. Mantenha seus testadores atuais qualificados e participando. O novo build ainda pode precisar de análise e publicação antes que os testadores consigam instalá-lo, então verifique a entrega separadamente do requisito de teste.
O que é a única coisa que reseta o relógio do teste fechado?
O Google não publica uma lista de reinício que cubra cada ação do Console. O requisito diz respeito à participação contínua de cada testador. Um testador que sai e volta começa os próprios 14 dias de novo, e perder testadores qualificados suficientes pode atrasar sua solicitação. Um novo substituto começa do primeiro dia. Uma atualização comum do build é outro evento.
Qual a diferença entre testadores convidados e inscritos?
Convidado significa que a conta está na sua lista de testadores ou no seu Grupo do Google. Participando significa que o testador abriu o link do teste com essa conta e entrou no teste. Só listar um endereço não conclui a inscrição. Peça que os testadores confirmem a conta e depois instalem, usem o app e enviem um feedback relevante.
Os testadores precisam aceitar participar de novo depois de um update?
Normalmente, não. Testadores atuais qualificados recebem uma atualização comum pelo Google Play sem entrar de novo no mesmo teste. Mantenha a inscrição deles intacta e depois peça que verifiquem a página da loja e o build instalado. A instalação automática depende de a versão estar disponível e das configurações do dispositivo, então não prometa a cada testador a atualização em minutos.
Desinstalar é o mesmo que sair do teste?
Não. Desinstalar remove o app de um celular; sair do teste muda a participação no teste. Nem a contagem de instalações de hoje nem a lista de convites de hoje provam uma inscrição contínua. Um testador que desinstalou também não consegue testar aquela instalação, então confirme que ele ainda está no teste e peça que reinstale e continue testando.
O Google quer que eu envie updates durante o teste?
O Google recomenda agir com base no feedback dos testadores e corrigir problemas, e a solicitação de acesso de produção pergunta o que você mudou depois do teste. Ele não publica um número obrigatório de versões. Envie correções úteis quando precisar, registre o que mudou e teste de novo. Não lance versões cosméticas só para cumprir uma suposta regra de duas ou três atualizações.
De quantos testadores eu realmente preciso no teste fechado?
Para contas pessoais criadas após 13 de novembro de 2023, o mínimo é de 12 testadores que tenham, cada um, continuado participando nos últimos 14 dias consecutivos quando você fizer a solicitação. Recrutar testadores extras cedo dá a você uma margem de segurança. Substitutos adicionados tarde não herdam os dias dos testadores que saíram, e nenhuma quantidade de testadores garante o acesso de produção.
Preciso lançar duas ou três atualizações para ser aprovado?
As orientações publicadas pelo Google não definem essa cota. Elas perguntam sobre o teste, o feedback, as mudanças e a prontidão. Se o teste encontrar um problema real, corrija e registre o novo teste. Se não encontrar, descreva o teste com honestidade. Um número de versões sozinho não prova um teste útil nem garante que o acesso de produção será concedido.
Minha versão está disponível, então por que meu testador ainda está na versão antiga?
Verifique a conta Google do testador, a inscrição dele na faixa, a porcentagem de lançamento e o versionCode. Depois peça que ele abra a página do app no Google Play e procure Atualizar. A atualização automática pode estar desativada ou ser adiada pelas condições do dispositivo. Confirme que o build foi realmente instalado; a data de atualização na página da loja não basta.
"Em análise" pausa meu teste de 14 dias?
Uma atualização em análise está esperando o Google processar aquele build. O Google não documenta que a análise de uma atualização comum pause o tempo de participação já acumulado pelos seus testadores. Verifique se o teste em andamento continua disponível e se a inscrição está intacta. Um novo envio pode atrasar a análise da versão, o que é separado do requisito de teste contínuo.
Os testadores devem sair e entrar de novo para receber a atualização?
Não. Sair e entrar de novo no teste fechado não resolve atualizações e quebra os dias consecutivos de participação daquele testador. Primeiro verifique a publicação, a conta do testador, o lançamento e o versionCode, depois tente o caminho normal de atualização da Play Store. Repare uma inscrição realmente errada à parte, sabendo o que isso faz com os 14 dias daquele testador.
Conclusão
Resumo
Atualizar o app durante o teste fechado de 14 dias é seguro, normal e incentivado. O Google mede a participação sem interrupção de cada testador, então uma atualização comum na mesma faixa fechada não reinicia os 14 dias dos seus testadores. Os riscos reais são perder testadores qualificados, testadores saírem formalmente do teste ou enviar um build tão quebrado que os testadores desistem. Envie correções reais, aja com base no feedback e proteja a contagem de testadores com uma margem recrutada cedo. Se você quer ajuda para manter 12 ou mais testadores participando, a PrimeTestLab fornece de 12 a 25 testadores reais a partir de $19.99 mais 5% de taxa de serviço (mínimo de $1.50), com o teste ao vivo em 4-6 horas. Se o acesso de produção não for concedido após o teste completo, você escolhe entre um novo teste grátis ou o reembolso total. Ver planos de preços →