Como Solicitar Novamente Depois que o Google Play Diz “More Testing Required”

A tabela rola para os lados em telas estreitas

Essa tabela precisa ser condicional porque a orientação pública do Google é menos específica do que as mensagens de decisão que os desenvolvedores realmente recebem; tirar a média das duas em uma resposta única e confiante produz uma página errada para metade dos leitores. Cada afirmação abaixo está rotulada como orientação oficial, texto de decisão reproduzido, experiência da comunidade ou inferência operacional, e tudo isso está atualizado em 17 de agosto de 2026.

As causas da recusa estão deliberadamente fora do escopo aqui: este artigo trata do que fazer depois que a mensagem chega. Para o lado do diagnóstico, veja nosso artigo sobre por que solicitações de acesso de produção são recusadas.

O Que Sua Mensagem de Recusa Realmente Diz

Desenvolvedores no mesmo tópico de fórum se contradizem porque estão descrevendo mensagens genuinamente diferentes. Por isso, este artigo classifica suas evidências em três níveis, em vez de fazer uma média entre elas:

1. Nível 1
   A Central de Ajuda atual do Google

   O único nível que é política oficial, e o menos específico, porque é escrito para todos os desenvolvedores ao mesmo tempo.

2. Nível 2
   Uma mensagem de recusa reproduzida pelo desenvolvedor que a recebeu

   Diretamente acionável para aquele app, mas não é texto de política, e o Google comprovadamente já mudou o texto ao longo do tempo.

3. Nível 3
   Relatos de fóruns e da comunidade

   Útil para mostrar que algo é possível, nunca para provar que é obrigatório.

Aqui está tudo o que o Nível 1 diz sobre a sua situação. A brevidade é o ponto principal.

... may be required to continue testing your app.

O trecho que o Google publica sobre o que pode acontecer quando um pedido de acesso de produção não é aprovado. Ajuda do Google Play Console, resposta 14151465, acessada em 17 de agosto de 2026. Ver a página de origem

Essa passagem pública não menciona redefinição, novo cronômetro, período de espera, ou instrução para reconstruir o grupo de testadores. Esses detalhes aparecem, quando aparecem, apenas no texto de decisões específicas de cada conta ou em relatos da comunidade. Os exemplos que o Google declara sobre por que um app não está pronto são menos testadores do que o exigido, ou testadores que não estavam engajados. Tudo o mais que circula sobre essa recusa é Nível 2 ou Nível 3, e o decodificador abaixo diz a você qual é a sua mensagem.

Google Play Console · e-mail real de decisão Clique para ampliar

Um limite em tudo isso: sua recusa é a instrução mais específica disponível para você, não a única coisa entre você e uma segunda solicitação. O Play Console ainda controla se o botão de solicitar está ativo, e sua conta ainda precisa ter pelo menos 12 testadores com históricos de participação qualificados no dia em que você clicar nele. Siga qualquer duração que sua mensagem mencione, e verifique essas duas coisas de forma independente.

E se você não conseguir encontrar a mensagem da decisão?

Então a posição honesta é que você não sabe qual instrução se aplica a você, e nenhuma página pode fornecer a que está faltando. A variante sem duração não é um padrão seguro: presumi-la quando sua conta na verdade recebeu o outro texto significa solicitar novamente antes que um período informado tenha terminado.

1. Procure no e-mail do dono da conta, incluindo spam e qualquer outro endereço além do que você verifica diariamente, pelo parágrafo que começa com "Before applying again".
2. Verifique as notificações do Play Console e as páginas de status de política ou publicação do app em busca da decisão.
3. Verifique seu histórico de suporte do Play Console, onde um contato anterior sobre a mesma decisão pode citá-la de volta.
4. Mantenha o teste fechado existente em execução enquanto você procura. Nada na busca pela mensagem exige que você pause, esvazie ou reconstrua qualquer coisa.
5. Entre em contato com o suporte do Play Console se a instrução não puder ser recuperada, e peça a eles para confirmar o que foi informado ao seu app. Inferência operacional

Até você ter o texto ou uma confirmação, não presuma uma duração em nenhuma direção: nem mais uma quinzena, nem nenhuma.

O Teste Fechado de 14 Dias Reinicia Depois de uma Recusa?

A palavra "reiniciar" é a fonte do problema: ela é usada para três coisas diferentes, e só a terceira é uma regra publicada.

• Uma redefinição da plataforma. Um evento do lado do Google que apaga o período qualificador de todo mundo no teste. Nenhuma fonte encontrada
• Um período adicional de teste. Uma instrução, entregue na mensagem de recusa, para testar por mais um tempo informado antes de solicitar novamente. Documentado em uma família de mensagens
• Uma sequência individual interrompida. O período de participação contínua de um testador terminando porque ele saiu. Mecânica publicada

Esse terceiro caso se aplica a testadores individuais, não ao teste como um todo. Aqui está o conjunto completo de evidências, classificado.

A tabela rola para os lados em telas estreitas

Essas cinco linhas sustentam uma resposta honesta, e ela é condicional: siga o texto da recusa que você realmente recebeu, e não trate nenhuma recusa como prova de que o Google reiniciou formalmente um cronômetro.

Se o seu e-mail diz mais 14 dias

Então essa é a sua instrução, e o ponto mais seguro para solicitar novamente é depois que esses 14 dias estiverem genuinamente completos. O Google não publica onde esse período deve ser cumprido, então cumpri-lo na faixa qualificadora existente é uma inferência operacional, não uma regra do Google. Aproveite a quinzena, em vez de só esperá-la passar: a mesma mensagem que deu a você o número também pede testadores reais. Inferência operacional

Isso não é evidência de um mecanismo da plataforma como um todo: um desenvolvedor recebeu a instrução de fazer mais 14 dias, e essa é toda a alegação. O desgaste natural ainda pode custar o seu grupo, então verifique quem está atualmente participando antes de presumir que os 12 estão intactos.

Se o seu e-mail só diz para continuar testando

Então nenhuma duração foi informada a você, e a Central de Ajuda do Google não publica nenhum período de espera numérico para preencher essa lacuna. Não invente um. E cuidado com o erro oposto, porque "continue testing" não é uma permissão para solicitar novamente na mesma tarde. Mantenha o teste qualificador em execução e solicite novamente quando duas coisas forem verdadeiras: o Play Console permitir, e você conseguir melhorar de forma material suas respostas de prontidão. Se sua recusa mencionou engajamento ou número de testadores, essas são as coisas a descrever de forma diferente.

Você Deve Manter o Mesmo Teste Fechado ou Criar uma Nova Faixa?

Essa é a pergunta mais repetida nos tópicos da comunidade por trás deste artigo, e o medo por trás dela é razoável: que escolher errado desperdice mais duas semanas. O que não se sabe é o que o Google faria se você de fato começasse uma nova faixa, porque ele nunca publicou nada sobre isso em nenhum dos dois sentidos. Dada uma recomendação documentada e um silêncio, o caminho de menor risco é o documentado.

Play Console · Test and release · captura de tela real Clique para ampliar

O caminho no Console para verificar qualquer um desses pontos não mudou: Testing Closed testing Manage track Testers

Os mesmos testadores ainda contam?

A regra rígida. Cada testador contado para a elegibilidade precisa de um histórico de participação contínua qualificador, atualmente pelo menos os últimos 14 dias sem interrupção. Isso é publicado, e é medido por pessoa, não como um único cronômetro global para o teste.

Play Console · Closed testing · Testers tab Clique para ampliar

A incerteza. O Google não publica nenhuma regra dizendo que um desenvolvedor recusado precisa substituir seus testadores. Um comentarista do r/androiddev descreve aprovação na quarta tentativa sem adicionar nenhum testador novo, o que contraria apresentar a substituição como obrigatória. É um relato isolado e não pode provar que os mesmos testadores sempre funcionam, mas é mais evidência do que existe do outro lado, onde não há nenhuma.

Você deve pedir aos testadores para sair e entrar de novo?

Não. Esse é o erro mais concreto que este artigo pode evitar, e ele é popular justamente porque parece que você está fazendo alguma coisa.

Sair encerra o período contínuo daquela pessoa. Não existe uma redefinição documentada que sair e entrar de novo acione, então a tática destrói um histórico de qualificação real em troca de nada, e faz isso com todo testador que cooperar ao mesmo tempo. Um desenvolvedor que faz isso com o grupo inteiro transforma um grupo que estava qualificado ontem em um grupo que só se qualifica em duas semanas.

O mesmo raciocínio se aplica à versão mais suave dessa ideia, que é remover os testadores que parecem inativos para a lista "começar limpa". Se você ficar abaixo de 12 depois disso, você piorou o problema de elegibilidade em vez de melhorá-lo, e nosso artigo sobre o que fazer quando menos de 12 testadores ainda se qualificam cobre para onde ir a partir daí. Se você precisa reconstruir o grupo em vez de reparar, nosso artigo sobre formas de recrutar 12 testadores confiáveis é o complemento prático.

O Que Deve Mudar Antes de Você Solicitar Novamente?

Note o que falta nessa lista: uma causa para a sua recusa. O Google não publica um modelo de pontuação, e nenhuma página pode dizer a você qual resposta pesou na decisão. O que ela pode dizer é quais temas o revisor realmente está observando, o que é um uso melhor de uma quinzena do que ficar adivinhando. Para a pergunta mais ampla de por que os apps falham nessa etapa, nosso artigo sobre por que o teste fechado é recusado cobre as causas; esta seção permanece focada na recuperação.

Mantenha pelo menos 12 testadores participando continuamente

Este é o único piso rígido em todo o processo, e vale a pena lê-lo nas próprias palavras do Google, e não na paráfrase de qualquer pessoa.

Se você tem uma conta pessoal de desenvolvedor recém-criada, você precisa realizar um teste fechado para o seu app com no mínimo 12 testadores participando continuamente pelos últimos 14 dias.

Ajuda do Google Play Console, resposta 14151465. Aplica-se a contas pessoais de desenvolvedor criadas após 13 de novembro de 2023. O Google reduziu a exigência de 20 para 12 testadores em 11 de dezembro de 2024. Ver página de origem

Três coisas nessa frase são interpretadas erradamente com frequência. É um mínimo, não uma meta, e nada publicado diz que um número maior tem um desempenho melhor. É contínuo, medido por testador, então uma pessoa saindo quebra apenas a própria qualificação dela, não a de todo mundo. E especifica um teste fechado, e é por isso que o teste interno não satisfaz essa exigência, não importa quantas das suas 100 vagas você preencha. Se você está avaliando as faixas, nosso artigo sobre teste interno versus fechado versus aberto explica para que serve cada um.

Se o seu grupo caiu abaixo do piso mínimo desde a recusa, isso é a primeira coisa a corrigir, e isso exige tempo de calendário: um testador substituto precisa dos seus próprios 14 dias contínuos antes de contar. Recrutar no décimo dia de um plano pensado para o décimo quarto dia é como as pessoas acabam sendo recusadas duas vezes.

Dê aos testadores coisas específicas para testar

A recomendação do Google é concreta: dê aos testadores instruções claras, diga a eles que tipo de feedback você quer, e incentive-os a usar o máximo possível dos recursos do app. Isso é uma orientação bem diferente de "por favor, mantenha instalado", que é o que a maioria dos grupos de 12 testadores realmente recebe como pedido.

É também a recomendação com a maior diferença entre o que o Google diz e o que a internet diz. O que o formulário de acesso de produção realmente pergunta é se os testadores usaram os recursos do app, e se esse uso se pareceu com a forma como você espera que usuários reais se comportem. São perguntas respondíveis sobre cobertura, não sobre frequência.

• Nomeie os recursos. Dois ou três que importam mais, pelo nome, para que uma resposta sobre cobertura mais tarde seja uma descrição, e não apenas uma alegação.
• Nomeie os fluxos. Cadastrar-se, criar algo, editar, compartilhar ou exportar, voltar no dia seguinte e encontrar tudo ainda lá.
• Diga o que você quer receber de volta. Onde eles travaram, o que esperavam que acontecesse, o que eles não usariam de novo.
• Distribua os dispositivos que você já tem. Dispositivos reais representativos são recomendados; nenhum número mínimo de modelos de dispositivo é publicado.

Registre o feedback e faça melhorias justificadas

O Google recomenda responder ao feedback dos testadores e corrigir os bugs que o teste revela, e diz que fazer isso pode melhorar a probabilidade de uma solicitação de acesso de produção bem-sucedida. Essa é uma evidência muito mais forte do que qualquer receita da comunidade sobre quantos lançamentos publicar, e é o único ponto em que "fazer mais" é genuinamente respaldado.

Play Console · Ratings and reviews · Testing feedback Clique para ampliar

Na prática, isso toma a forma de um registro. Vão pedir a você para resumir o feedback que recebeu e o que mudou por causa dele, e reconstruir isso de memória uma quinzena depois é onde bons testes acabam produzindo solicitações fracas. Mantenha algo assim, uma linha por item.

Modelo em branco. A tabela rola para os lados em telas estreitas

A linha "não mudar e por quê" importa tanto quanto as correções. Uma resposta de prontidão para produção que diz quais problemas conhecidos permanecem e por que eles não impedem o lançamento é uma resposta mais forte do que uma que sugere que tudo estava perfeito. E o canal pelo qual o feedback chegou é uma escolha sua: e-mail, um site ou fórum, ou o feedback privado que os testadores podem enviar pelo Google Play, que aparece em Monitor and improve Ratings and reviews Testing feedback

Sobre atualizações: publique uma quando o teste justificar. O Google incentiva corrigir o que o teste encontra, e atualizar o build durante um teste fechado não quebra a exigência de testadores, algo que nosso artigo sobre se atualizar seu app reinicia o teste fechado cobre em detalhes. O que não é publicado em lugar nenhum é um número obrigatório de lançamentos, então publicar builds só para atingir uma contagem é esforço gasto em um número que ninguém definiu.

Verifique o relatório de pré-lançamento

O Google direciona os desenvolvedores ao relatório de pré-lançamento para investigar problemas, avisos e erros antes de lançar. Leia-o antes da segunda solicitação, e trate o que ele aponta como trabalho a fazer, não como um diagnóstico: nada publicado diz que um determinado aviso causou uma recusa de acesso de produção, e nada diz que todo aviso precisa ser resolvido primeiro. É uma fonte de problemas reais que você pode corrigir enquanto já está corrigindo outras coisas.

Verifique a conformidade com as políticas, a confiabilidade do app e as credenciais de revisor

A atividade de teste não é tudo o que o Google pede para você confirmar antes de solicitar. A orientação atual dele nomeia quatro áreas de prontidão além do teste fechado, e uma quinzena dedicada apenas ao engajamento dos testadores ainda pode resultar em uma decisão sobre uma dessas outras áreas.

Como Solicitar Novamente o Acesso de Produção

Não existe um fluxo de nova solicitação documentado separadamente, nenhum formulário diferente, e nenhuma fila publicada para segundas tentativas. O que muda é o que você traz para ela.

A tabela rola para os lados em telas estreitas

O que dizer sobre engajamento, feedback e prontidão

Engajamento. O Google pergunta se os testadores usaram os recursos do app e se esse uso se pareceu com o que você espera em produção, então a resposta mais forte é descritiva e específica: quais recursos, pelo nome, e o que os testadores realmente fizeram com eles. Se um uso entusiasmado não é verdade no seu teste, diga o que é verdade. Uma resposta descrevendo um uso modesto, mas genuíno, é defensável; uma que descreve atividade que você não pode comprovar é algo que você vai ter que manter consistente em todas as solicitações posteriores.

Feedback. Resuma os temas em vez de transcrever as mensagens, e nomeie o canal de coleta. E-mail, um site ou fórum, e o feedback privado do Play, todos contam, então não existe um canal errado para ter usado: a única pergunta sem resposta é a de quem não coletou nada.

Mudanças e prontidão. Ligue cada mudança relevante a uma descoberta específica do teste, depois explique por que os problemas que restam não impedem o lançamento. Essas são as duas respostas em que uma quinzena documentada supera visivelmente uma que não foi documentada. Para o tratamento completo de como escrever cada uma, veja nosso artigo sobre respostas do formulário de acesso de produção.

E se o Apply for production continuar desativado?

Um botão Apply for production acinzentado ou ausente costuma significar que uma condição de elegibilidade ou de configuração do app ainda não foi atendida. Atrasos no Console e problemas específicos da conta também são possíveis, então percorra as condições documentadas abaixo antes de concluir que a interface está com defeito.

• A contagem ainda não bateu. A conta pode não ter atualmente 12 testadores com os 14 dias anteriores de participação contínua exigidos, não importa o que o total da lista de convites diga.
• Convidado não é o mesmo que participando. Pessoas que receberam um link e nunca o aceitaram não são testadores para esse fim. Verifique quem está realmente participando, não quem foi convidado.
• Os substitutos ainda estão acumulando tempo. Alguém adicionado depois da recusa começa seus próprios 14 dias contínuos a partir do momento em que passa a participar, então um grupo reforçado pode ter doze pessoas e ainda não ser elegível por mais uma quinzena.
• A configuração do app está incompleta. Pendências na ficha da loja, na classificação de conteúdo, no App access ou nas declarações de política podem bloquear a solicitação, independentemente do número de testadores.
• É o teste fechado que conta. O teste interno não satisfaz essa exigência, não importa quantas vagas dele estejam preenchidas.

Play Console · Dashboard · captura de tela real Clique para ampliar

Se todos esses pontos parecem atendidos no seu próprio Console e o botão ainda não aparece, essa é uma das situações que vale a pena levar ao suporte do Play Console, em vez de simplesmente esperar, porque você já não está resolvendo algo que a documentação pública descreve.

Uma linha sobre o que você está solicitando, já que é fácil perder isso de vista em uma segunda tentativa: a aprovação libera os lançamentos de produção do app, e também libera o teste aberto, então o leitor que queria um beta mais amplo, e não um lançamento na loja, está esperando pela mesma decisão. Tudo depois desse ponto é gestão comum de lançamento, não uma continuação deste processo.

Você Precisa de Aberturas Diárias, Mais Testadores, ou Mais Atualizações?

É aqui que a maior parte do estrago acontece. Um desenvolvedor recusado procura o que deu errado, encontra uma página dizendo que os testadores precisam abrir o app todo dia e que você precisa lançar três versões, e passa a quinzena perseguindo um alvo que o Google nunca definiu, enquanto a coisa que o Google realmente perguntou (se os testadores usaram o app de forma significativa, e o que você fez com o que eles disseram) fica sem resposta. Vale a pena afirmar claramente a posição honesta: a orientação pública do Google sobre acesso de produção não fornece nenhum limite numérico de engajamento nem nenhum modelo de pontuação publicado. As perguntas do formulário são critérios de análise, não uma tabela de pesos, e nenhum painel publicado converte a atividade dos seus testadores em uma nota que você possa consultar. Então a atitude útil não é adivinhar o número, mas saber quais das coisas que disseram a você estão realmente publicadas.

A tabela rola para os lados em telas estreitas

Dois desses merecem mais uma frase, porque são os que custam dinheiro de verdade. Comprar um grupo maior de testadores é uma escolha operacional razoável, já que um grupo de 12 não tem margem se uma pessoa sair, mas ninguém pode honestamente vender isso a você como uma chance maior de aprovação, e relatos da comunidade incluem recusas com mais de 30 testadores e com 19 testadores mais 17 atualizações. E perseguir uma cota de modelos de dispositivo desvia esforço da coisa que o Google realmente pergunta no formulário: nenhum limite numérico de dispositivos é publicado, e testadores representativos em dispositivos reais são uma recomendação, não uma fórmula. Se você quiser o detalhe sobre o que conta como um participante válido de teste fechado, nosso artigo sobre emuladores no teste fechado do Google Play cobre o lado dos dispositivos corretamente.

Quantas Vezes Você Pode Solicitar Novamente?

Isso é praticamente toda a base de evidências públicas, e vale a pena ver o quanto ela é escassa antes que alguém cite um número para você. Desenvolvedores individuais em fóruns públicos relatam aprovação na quarta solicitação sem adicionar novos testadores, uma sexta recusa aproximada apesar de 19 testadores e 17 atualizações, uma segunda recusa com um grupo bem acima do mínimo, e outra segunda recusa depois de uma quinzena inteira extra com os mesmos testadores e correções já publicadas. Eles contam que essas tentativas aconteceram. Eles não conseguem dizer por que cada uma delas terminou como terminou. Relatado pela comunidade

Duas conclusões seguem daí, e só duas. Primeiro, não existe um teto baixo óbvio: solicitações além da segunda e da terceira comprovadamente existem. Segundo, e mais útil, fazer mais do mesmo não é uma estratégia. A maioria desses relatos descreve desenvolvedores que adicionaram testadores, adicionaram atualizações ou adicionaram tempo e mesmo assim foram recusados. Se sua segunda solicitação é a primeira mais uma quinzena, você está reproduzindo a última delas.

Sobre o medo por trás da pergunta: a orientação pública do Google não classifica uma decisão de prontidão de "more testing required" como uma infração de política, e não foi encontrada evidência de que decisões de prontidão repetidas levem, por si só, à suspensão da conta. Um problema de política separado ainda pode existir ao mesmo tempo (a aplicação de políticas é um processo próprio, com seus próprios avisos e suas próprias formas de resolução), então trate qualquer mensagem que mencione uma violação de política como a coisa distinta que ela é, e não como mais uma rodada desta.

Quanto Tempo o Google Leva para Analisar uma Nova Solicitação?

Esta seção existe principalmente para impedir um comportamento: o oitavo dia chega, a estimativa já passou, e o desenvolvedor começa a mudar coisas. Os dois relatos da comunidade abaixo mostram o quanto uma análise pode ficar fora da estimativa sem que nada esteja errado.

Essas duas esperas longas são relatos isolados e provam apenas que esperas longas acontecem. Elas não são uma distribuição, e passar do sétimo dia não é, por si só, um sinal de que algo deu errado. Para o panorama mais amplo entre os tipos de análise, veja nosso artigo sobre tempos de análise do Google Play.

Quando vale a pena contatar o suporte do Play Console?

Não existe uma regra publicada de "contate o suporte depois de X dias", e inventar uma seria o mesmo erro de inventar um período de espera. O que se pode dizer são quais situações a documentação pública para de explicar, que é onde o suporte se torna a única fonte restante de uma resposta:

• A instrução está indisponível ou contraditória. Você não consegue recuperar a mensagem da decisão, ou o que ela diz não corresponde ao que o Console mostra.
• O Console continua bloqueado. Apply for production continua indisponível mesmo que os critérios publicados pareçam atendidos e todos os itens da lista de causas do botão desativado acima estejam corretos.
• A análise está significativamente fora da estimativa, sem nenhuma informação de status disponível em qualquer lugar do Console.
• A mensagem parece ser um processo diferente. Qualquer coisa que mencione uma violação de política ou uma ação técnica de aplicação de regras não é esta decisão, e perguntar sobre isso aqui desperdiça a quinzena.

Fora esses casos, esperar é a ação correta, não a passiva. Reenviar, alterar a faixa ou retirar uma solicitação para enviar de novo são todas mudanças feitas em um processo que você não consegue ver, e nenhuma delas é indicada por nada que o Google publica.

Sua Lista de Verificação para Solicitar Novamente

Os onze passos, em ordem

1. Leia a recusa exata e observe se ela especifica mais 14 dias. Se você não conseguir encontrá-la, recupere-a antes de planejar em torno de uma duração.
2. Mantenha o teste fechado qualificador em execução. Não feche, exclua ou substitua a faixa por causa da recusa, e publique correções justificadas nela quando o teste indicar a necessidade.
3. Mantenha pelo menos 12 testadores qualificadores participando continuamente. Cada um contado precisa do seu próprio período ininterrupto.
4. Não peça aos testadores para sair e entrar de novo. O Google não documenta nenhuma redefinição que reentrar acionaria, e sair interrompe um período contínuo real que você já tem.
5. Dê aos testadores instruções reais de teste no nível de recursos, em vez de pedir que apenas mantenham o app instalado.
6. Registre feedback significativo em um breve registro escrito, seja qual for o canal pelo qual ele chegue.
7. Corrija bugs e problemas de usabilidade justificados, depois valide a correção com o testador que a relatou.
8. Revise o relatório de pré-lançamento em busca de problemas, avisos e erros antes de solicitar novamente.
9. Verifique as áreas de prontidão fora do teste: conformidade com as políticas, público-alvo e classificação de conteúdo, confiabilidade funcional, e credenciais de revisor funcionando em App access.
10. Prepare respostas específicas e sinceras de acesso de produção sobre engajamento, feedback, mudanças e prontidão.
11. Solicite pelo Dashboard quando estiver elegível, e não prometa a ninguém uma decisão em sete dias.

Copiar a lista de verificação

Essa lista é o caso geral. O seu caso tem pelo menos três variáveis que o caso geral não consegue ver: o que sua mensagem dizia, em que ponto seu grupo de testadores realmente está hoje, e quantas vezes você já passou por isso antes. A ferramenta abaixo transforma isso em uma rota ordenada que você pode seguir, e ela mantém suas marcações mesmo se você fechar a aba.

Monte sua própria rota

Uma coisa que a ferramenta nunca vai imprimir, seja qual for a sua resposta, é uma data em que o Google vai aprovar você. Ninguém pode produzir isso, e um relato da comunidade sobre um desenvolvedor aprovado na quarta tentativa convive com outro descrevendo uma sexta recusa. O que a rota pode fazer é garantir que, quando a decisão chegar, ela esteja sendo tomada sobre uma solicitação que você consegue defender, e não sobre uma quinzena que simplesmente passou.

Se percorrer essa rota mostrar que o lado dos testadores é o bloqueio (sua recusa exige explicitamente mais 14 dias, ou seu grupo não tem mais 12 testadores qualificadores), essa é a metade que você pode terceirizar: a PrimeTestLab cuida disso enquanto você melhora o app, o registro de feedback e as respostas da sua nova solicitação. Isso está coberto em como ajudamos, mais abaixo.

Como a PrimeTestLab Ajuda Se Você Precisar de Outro Grupo

Onde uma execução gerenciada faz sentido, a recuperação se divide em duas metades. Uma é julgamento: ler sua recusa, decidir o que mudar, escrever respostas que você consegue defender. Essa metade é sua. A outra é logística: manter 12 pessoas reais participando e usando o app durante toda uma janela de teste. Não é o problema interessante, mas é o que consome o calendário.

A PrimeTestLab fornece 12 testadores reais em dispositivos reais, abrangendo Android 7 a 17, participando e mantidos pelos 14 dias completos, com o teste começando em 4-6 horas. Já fizemos isso em 7.400+ apps, em 120+ países, com uma taxa de conclusão de teste gerenciado de 99,9%: conclusão significando que o teste manteve o número exigido de testadores e um período de participação ininterrupto até a data final.

O que nós não fazemos, e o que este artigo argumentou que ninguém pode fazer, é prometer a decisão: o Google analisa o acesso de produção segundo seus próprios critérios e não publica um modelo de pontuação. Nossa garantia é um novo teste grátis ou reembolso total: condições e prazo para solicitar na nossa política de reembolso e novo teste grátis.

Recrutar outro grupo por conta própria versus uma execução gerenciada

A tabela rola para os lados em telas estreitas

Para ser direto sobre o limite: comprar testadores não responde ao formulário, não escreve seu registro de feedback, nem faz o Google aprovar nada. Tudo acima desta seção foi escrito para que você faça bem essas partes. O que uma execução gerenciada elimina é a parte em que uma janela de teste desmorona pelo mesmo motivo que a primeira desmoronou.

Uma ressalva que vale a pena repetir da tabela de mitos acima: grupos maiores protegem contra desistências, mas o Google não publica nenhum número acima de 12 que aumente mensuravelmente a chance de aprovação, então ninguém, nem nós, deveria vender testadores extras a você como uma chance melhor. Compre a margem pela margem em si. Detalhamento completo na página de preços.

Perguntas Frequentes

Resumo Final

Se sua recusa mencionou mais 14 dias, ou se seu grupo não tem mais 12 testadores qualificadores, esse lado dos testadores é a única parte da recuperação que você pode terceirizar enquanto cuida do resto. Ver planos e preços →