Checklist honesto antes de ampliar um teste interno Android

Um teste interno Android não precisa esperar o produto perfeito. Mas também não pode começar com autoengano.

A pergunta certa não é “está tudo pronto?”. A pergunta certa é:

O que já foi validado em uma build instalada pela Play Store, e o que ainda é uma pendência conhecida?

Essa diferença evita duas decisões ruins:

• Adiar teste por medo de pendências não bloqueantes.
• Chamar testadores quando ainda existe erro básico de configuração.

1. Confirme que a instalação veio da Play Store

Antes de validar qualquer SDK, confirme a origem do app:

adb shell dumpsys package com.sunstoneapps.dailysudoku | rg 'versionCode|versionName|installerPackageName'

O resultado esperado:

versionCode=4
versionName=0.1.0
installerPackageName=com.android.vending

Se installerPackageName não for com.android.vending, você está validando outra coisa. APK local, bundletool e sideload são úteis, mas não substituem o caminho da Play Store.

2. Confirme observabilidade antes de procurar bugs

Sentry precisa estar ligado antes de você pedir para outras pessoas testarem.

Procure no log:

[crash-reporting] initialize

E confira:

enabled=true
hasDsn=true
environment=production
[email protected]+4
dist=4

Se o app crashar durante teste e o Sentry não estiver pronto, você perde o dado caro: o erro real em ambiente real.

3. Confirme source maps, não só evento

Um evento no Sentry sem source map legível ainda é meio cego.

O checklist mínimo:

• Release criado.
• Dist correto.
• Source maps enviados.
• Runtime anunciando o mesmo release/dist.
• Um erro controlado ou real aparece com stack trace útil.

No nosso caso, um erro real antigo foi útil:

RevenueCat API key is missing.

Ele confirmou que o Sentry recebia evento runtime com stack/source maps. Depois, a build corrigida confirmou que o erro parou de aparecer.

4. Confirme Firebase no projeto certo

Firebase pode falhar de um jeito silencioso: eventos chegam, mas no projeto errado.

Por isso, valide o gmp_app_id:

1:832961368149:android:043d6431c9c975f7fbc4dc

E procure eventos mínimos:

app_opened
shop_viewed
session_start

Não precisa mapear o funil inteiro para iniciar teste interno. Precisa saber que o app instalado pela Play está falando com o projeto correto.

Há uma armadilha que vale registrar: às vezes quem está quebrado é o DebugView, não o app.

Na passada de julho da build 0.1.0+9, o emulador Android apareceu no DebugView. Dois aparelhos físicos da família Xiaomi não apareceram: um Redmi Note 7 por USB e um POCO X6 por ADB Wi-Fi. Parecia um problema real até os logs do SDK contarem outra história. Nos dois aparelhos, o logcat mostrou Faster debug mode event logging enabled, enviou app_opened, shop_viewed e ad_query(_aq) com _dbg=1, usou o gmp_app_id esperado e recebeu resposta 204 nos uploads para GOOGLE_ANALYTICS. O GA Realtime também mostrou usuários ativos vindos do app.

Isso não torna o DebugView inútil. Só significa que ele não pode ser o único gate em toda skin Android. Quando um aparelho físico não aparecer, registre gmp_app_id, app_instance_id, nomes dos eventos, _dbg=1 e upload 204 antes de chamar a instrumentação de quebrada. Se Realtime ou BigQuery confirmarem tráfego, a pergunta de release deixa de ser “analytics está morto?” e passa a ser “o DebugView está instável nesta família de devices hoje?”.

5. Separe anúncios quebrados de inventário ausente

Em AdMob real, no-fill pode ser só falta de inventário. Não transforme isso automaticamente em diagnóstico de crash.

Um primeiro sinal útil é:

ad_query(_aq)

Ele mostra que houve consulta ao SDK de anúncios. Ainda falta validar visualmente:

• Banner não corta layout.
• Interstitial não trava fluxo.
• UMP não bloqueia início do app.
• Recusa de consentimento não quebra navegação.

Mas ad_query(_aq) já prova que o app chegou ao SDK real.

6. Separe configuração de SDK de configuração comercial

RevenueCat é um bom exemplo.

Erro bloqueante de SDK:

RevenueCat API key is missing.

Esse erro significa que o app nem tinha a chave pública correta.

Depois de corrigir a chave, o erro mudou para:

ConfigurationError: there are no Play Store products registered in the RevenueCat dashboard for your offerings

Esse segundo erro é diferente. Ele mostra que o SDK está configurado, mas ainda faltam produtos e offerings.

Isso não deve ser escondido, mas também não é a mesma categoria de problema.

7. Escreva o status em linguagem operacional

Um checklist bom não diz apenas “pendente”. Ele diz o próximo passo concreto.

Ruim:

IAP pendente.

Melhor:

RevenueCat SDK validado com chave Android. Falta cadastrar produtos Play Billing,
configurar offering default e vincular service account do Google Play para validação
de transações.

Esse tipo de registro economiza tempo quando você volta ao projeto dias depois e já não lembra qual parte era real.

8. O que estava validado no nosso caso

Na build 0.1.0+4, instalada pela Play Store:

• versionCode=4.
• installerPackageName=com.android.vending.
• Sentry [email protected]+4, dist 4.
• Firebase no projeto oficial.
• Eventos app_opened, shop_viewed.
• Evento de ads ad_query(_aq).
• Erro RevenueCat API key is missing. ausente.
• Produtos Play Billing e offering default cadastrados.
• Service account do Google Play validada no RevenueCat.
• Compra de teste de produto único aparecendo no Play Console como Processado.
• Sentry sem novo erro depois da compra bem-sucedida.

Pendências conhecidas:

• Inspeção visual completa de ads/UMP em device real.
• Restore e caminhos negativos de compra em uma matriz maior de device/conta.

9. Valide a compra onde ela realmente acontece

Ver preço na loja do app não prova que a compra está pronta. Prova que o produto foi carregado pelo billing client.

O sinal mais forte vem de três lugares:

• Play Console mostra o pedido em Gerenciamento de pedidos.
• RevenueCat mostra Valid credentials para permissões de assinaturas, produtos in-app e monetização.
• Sentry não recebe novo erro de compra depois do teste bem-sucedido.

Em uma compra de teste, é normal a receita estimada ficar BRL 0,00. O que importa para o smoke é o pedido aparecer como Processado, com o produto correto e sem regressão nova em observabilidade.

10. Quando ampliar o teste

Eu ampliaria o teste interno quando:

• Cold start não crasha.
• Observabilidade está correta.
• Analytics mínimo funciona.
• Ads não bloqueiam o fluxo principal.
• Loja não promete compra funcional se produtos ainda não existem.
• Pendências conhecidas estão escritas.

Não é necessário resolver tudo para chamar mais testadores. É necessário não confundir “sabemos que falta” com “descobrimos quebrando na mão do testador”.

11. Antes de sair do teste interno para produção

A faixa de produção acrescenta uma pergunta: o app está pronto para gente fora da lista de testers, ou o console apenas está deixando você clicar no próximo botão?

Na nossa passada de julho, a build interna já tinha sido instalada pela Play em um Redmi Note 7 real. O pacote reportava versionCode=9, versionName=0.1.0 e installerPackageName=com.android.vending. O app abriu sem crash, o Sentry anunciou [email protected]+9, o Firebase App Measurement fez upload de eventos, a UMP gravou o modo de consentimento, o RevenueCat carregou offerings reais em BRL e o banner AdMob retornou no-fill sem travar o jogo.

Isso foi suficiente para enviar a primeira produção para revisão, mas não para fingir que o trabalho acabou. Mantivemos as pendências visíveis: confirmar Sentry no console externo e rodar uma compra ou restore real com conta tester autorizada quando o caminho da loja estiver disponível de novo. Para Firebase, o follow-up ficou mais específico: o DebugView funcionou no emulador, enquanto os Xiaomi físicos precisaram de validação por logs do SDK mais GA Realtime ou BigQuery.

Um detalhe do Play Console pesou mais do que parecia: a produção não tinha disponibilidade por país. A revisão da release mostrou erro real até a faixa receber países e regiões. Depois de selecionar 177 países/regiões, incluindo “Resto do mundo”, o erro bloqueante desapareceu. O aviso restante era apenas a ausência de arquivo de desofuscação do App Bundle, útil para diagnóstico, mas não bloqueante para essa build.

A lição é direta: trate a revisão de produção do Play como mais uma superfície de validação. Ela confere disponibilidade de faixa, notas da versão, estado do artefato e gates de política que uma build local não consegue enxergar.

Rode o checklist como ciclo, não como evento

Teste interno funciona melhor quando é repetido na mesma ordem. Um smoke test único pode pegar um crash, mas um ciclo semanal pega deriva: mudanças de configuração na loja, problemas de conta tester, atraso de metadados de billing, comportamento de consentimento e regressões específicas de device.

O ciclo precisa ser curto o suficiente para acontecer de verdade. Instale a build de release atual, abra em estado limpo, confira onboarding, rode um fluxo central, exercite billing ou ads se fizerem parte do release e registre o resultado. O valor está na comparação com a semana anterior, não no tamanho do checklist.

O que registrar

Uma nota útil de teste interno deve incluir:

• versão e version code da build;
• modelo do aparelho e versão Android;
• conta Play usada no teste;
• origem da instalação e se foi instalação limpa;
• observações de billing, ads, consentimento e crash reporting;
• screenshots ou logs apenas quando explicarem um problema.

Isso evita que o checklist vire diário. A nota deve ajudar a próxima pessoa responsável pelo release a responder se o comportamento mudou e onde olhar primeiro.

Mantenha manual e automático honestos

Automação é valiosa, mas não deve fingir que cobre a Play Store. Um teste de browser ou componente valida lógica do app rapidamente. Uma instalação real pela faixa interna valida assinatura, entrega pela loja, elegibilidade de billing, comportamento do SDK de consentimento e integração com o device.

As duas camadas importam. Use testes automatizados para pegar regressões antes de buildar. Use teste interno para verificar se o artefato de release se comporta corretamente no ecossistema onde usuários vão recebê-lo.

Mantenha o checklist pequeno o bastante para sobreviver

O melhor checklist é aquele que o time ainda roda quando está cansado. Se leva uma hora, será pulado sob pressão. Divida em núcleo obrigatório e checks profundos opcionais. O núcleo deve provar instalação, abertura, um fluxo monetizado ou dependente da loja e um fluxo com estado salvo. Checks profundos podem alternar por semana.

Isso torna o processo sustentável. Um checklist curto que roda em todo release pega mais regressões que um checklist perfeito que só roda antes de marcos grandes.

Essa é a diferença entre checklist e cerimônia: o checklist entrega uma decisão, não uma apresentação.

Conclusão

Um teste interno bom não é uma simulação de lançamento perfeito. É um ambiente controlado para encontrar problemas com instrumentação suficiente para agir.

O checklist honesto evita transformar testers em logs humanos. Ele deixa claro o que já foi provado pela build instalada pela Play Store e o que ainda precisa ser configurado antes de uma beta maior.