Neste guia
Um emulador é uma boa primeira passada. É rápido e gratuito, e você pode rodá-lo na mesma janela do editor. Mas ele é um modelo de celular, e os detalhes que um modelo deixa de fora são justamente os que os usuários reais encontram. Isto vale para todo app, não importa como foi feito. Pesa um pouco mais quando você não escreveu cada linha, porque tem menos noção de onde ele pode ser frágil.
O que um celular real mostra
- Velocidade e aquecimento. Uma tela fluida no seu computador pode travar em um celular mais antigo ou mais barato. Role listas longas, abra a tela mais pesada e use o app por dez minutos.
- Permissões. Câmera, localização, notificações, armazenamento: toque em "Permitir", depois em "Não permitir", e depois desative a permissão nas configurações do sistema. O app se explica e continua funcionando?
- O teclado. Ele cobre o campo de entrada? Aparece o tipo de teclado certo para e-mail ou números? O que acontece quando você o fecha com o gesto de voltar?
- Interrupções. Uma ligação, uma notificação, troca de app, rotação da tela, o tempo limite da tela de bloqueio. Volte ao app: sua entrada ainda está lá?
- Conexões reais. Sinal fraco, troca de Wi-Fi para dados móveis, modo avião. Veja testar o comportamento offline.
- Toque e tamanho. Os botões são fáceis de acertar com o polegar? O texto cabe em uma tela pequena e com as fontes grandes do sistema?
- Instalação e atualização. Instale o build de lançamento do zero e depois atualize sobre uma versão antiga. Os dados sobrevivem?
Nada disso pode ser verificado de forma convincente em um computador.
Um plano curto de dispositivos
Você não precisa de uma gaveta cheia de celulares. Cubra diferenças, não quantidade. Esta tabela não tem dados de participação de mercado de propósito; escolha entre o que você consegue acessar.
| Vaga | Por quê | Onde conseguir |
|---|---|---|
| Seu próprio celular | Uso diário, hábitos reais | Você já tem |
| Um celular mais antigo ou mais barato | Mostra limites de velocidade e memória | Um amigo, familiar, um usado |
| Um celular com tamanho de tela diferente | Problemas de layout | Mesmo caso |
| Uma versão diferente do sistema operacional | Comportamento e caixas de permissão mudam entre versões | Mesmo caso, ou um testador |
| Uma pessoa que não é desenvolvedora | Encontra os passos que você deixou de ver | Peça |
Quais modelos e versões priorizar está coberto em em quais dispositivos Android você deve testar de fato.
Quando você não consegue os dispositivos
Peça a testadores. Feedback privado e estruturado de pessoas em seus próprios celulares lhe dá dispositivos que você não possui, e o relatório inclui modelo e versão do sistema. Peça isso explicitamente no seu briefing de teste.
No Google Play, o requisito de teste fechado já coloca seu app diante de celulares de outras pessoas. Veja os requisitos do teste fechado (DE) e o que conta como 14 dias (DE). Use esses dias para feedback real, não só como contador.
Uma passada de 30 minutos
- Instale o build de lançamento em um celular real.
- Primeira abertura, cadastro e fluxo principal, do início ao fim.
- Negue cada permissão uma vez e conceda uma vez.
- Interrompa o app de três formas: ligação ou notificação, troca de app, rotação.
- Ative o modo avião no meio de um fluxo.
- Anote cada problema com passos, resultado esperado, resultado real e aparelho. Depois use o modelo de prompt se você corrigir com um assistente.
Onde o AppReviewX entra
O AppReviewX oferece feedback privado e estruturado de outros desenvolvedores em seus próprios celulares. Cada feedback que você escrever rende um crédito, os créditos compram feedback para o seu app, e contas novas começam com 0 créditos. Para Android há grupos de teste com 12 testadores durante 14 dias seguidos, para o requisito do Google Play.
Relacionados: hub de vibe coding, como testar antes do lançamento, checklist de lançamento.