Um checklist móvel ajuda a manter riscos importantes visíveis entre dezenas de telas e dispositivos antes de uma versão. Ele conecta cada verificação a uma ação específica e a um resultado observável. “Verificar a rede” é amplo demais; “desconectar após enviar um pedido e verificar que a nova tentativa não cria um segundo pedido” pode revelar um defeito.
Use este material como ponto de partida para adaptação. Um aplicativo bancário, um reprodutor de mídia e um rastreador de hábitos precisam de profundidade e foco diferentes. Um bom checklist se desenvolve a partir do produto, de dados analíticos, de mudanças da versão e de incidentes anteriores.
Defina o escopo da execução
Antes dos testes, registre a versão e o número do build, o ambiente da API, o método de instalação, as feature flags e as contas de teste. Crie uma matriz curta de dispositivos: uma versão importante do sistema operacional, a configuração mínima suportada, um tamanho de tela popular e um dispositivo com recursos limitados. Baseie a seleção nos usuários e nos riscos e identifique explicitamente as omissões.
Separe os testes smoke da regressão ampliada. O smoke estabelece se um build pode ser usado para continuar o trabalho e se os fluxos essenciais passam. Ele não substitui verificações de migração de dados ou testes após várias horas de uso.
Instalação, atualizações e primeira abertura
Verifique uma instalação limpa e uma atualização a partir de uma versão anterior suportada. Antes de atualizar, crie dados realistas no aplicativo: um rascunho, configurações e objetos offline. Após a atualização, eles devem ser preservados ou migrados conforme os requisitos.
Na primeira abertura, verifique a apresentação inicial, a seleção de idioma, o consentimento obrigatório e o acesso à tela principal quando permissões opcionais forem negadas. Após desinstalar e reinstalar, verifique a restauração dos dados conforme as regras da plataforma e do produto; uma conta que ainda existe no servidor não significa, por si só, que a desinstalação falhou.
Fluxos críticos do usuário
Identifique algumas ações que levam as pessoas ao produto: fazer login, pesquisar, realizar um pedido, enviar uma mensagem ou consultar um ingresso. Para cada uma, verifique um resultado bem-sucedido e pelo menos um estado de falha.
- →A ação realmente altera os dados do servidor, e um novo login exibe o estado salvo.
- →Uma lista vazia explica a próxima etapa, e os erros permitem continuar.
- →Toques duplos e envios repetidos não criam duplicatas proibidas.
- →O teclado, textos longos e painéis do sistema não ocultam uma ação necessária.
Verificar o resultado importa mais do que a quantidade de telas abertas. Um toast exibido corretamente não comprova que a requisição foi salva.
Rede e estados offline
Verifique a abertura sem rede, a perda de conexão durante leituras e gravações, respostas lentas, reconexão e mudança de Wi-Fi para dados móveis. Esclareça o comportamento esperado de operações locais enfileiradas e as regras de resolução de conflitos.
Para uma operação com efeitos colaterais, determine o que acontece se o servidor concluir a requisição, mas o cliente nunca receber a resposta. A tela não deve informar sucesso não verificado nem obrigar o usuário a repetir a ação indefinidamente. Após a reconexão, compare os estados local e do servidor e verifique duplicatas.
Ciclo de vida e interrupções do sistema
Coloque o aplicativo em segundo plano com um formulário aberto, reabra, bloqueie o dispositivo e retorne após a expiração da sessão. Teste a recriação de tela e o encerramento do processo separadamente da ida comum ao segundo plano: as condições de recuperação são diferentes.
Os requisitos podem exigir a preservação de rascunhos e a ocultação de dados sensíveis. O sistema não deve perder uma operação confirmada nem continuá-la com permissões desatualizadas. Verifique também uma chamada recebida ou diálogo do sistema durante gravação de áudio, pagamento ou envio de arquivo, se o produto suportar esse cenário.
Permissões, notificações e navegação externa
Verifique a concessão, a recusa e a revogação posterior das permissões usadas pelo aplicativo. Ele deve responder claramente quando o acesso à câmera, à localização ou às notificações estiver indisponível. Não é necessário adicionar permissões não usadas ao checklist apenas para torná-lo completo.
Para notificações push, verifique primeiro plano, segundo plano e abertura pela notificação. Para deep links, teste aplicativo instalado, sessão expirada, objeto indisponível e nova abertura do mesmo link. Uma notificação não deve mostrar dados de outro usuário após troca de conta, e a navegação não deve contornar verificações de acesso.
Dados, segurança e compatibilidade
Use duas contas de teste para verificar troca de usuário, logout e acesso a telas privadas abertas anteriormente. Confirme que caches, busca e notificações push não expõem mais dados do usuário anterior. Logs de diagnóstico e relatórios não devem conter tokens reais ou segredos dos usuários.
Verifique localidades, fusos horários e formatos de data suportados nos cenários relevantes. A passagem da meia-noite é especialmente útil para reservas, agendas e limites diários. Repita os cenários de maior risco em outros dispositivos, considerando a mudança específica da versão.
Acessibilidade, velocidade e estabilidade
Siga o fluxo principal usando TalkBack ou VoiceOver, texto ampliado e as configurações de sistema acordadas. Avalie o alcance dos botões, a ordem do foco e as mensagens de erro. Scanners automatizados complementam os testes manuais.
Para desempenho, compare a abertura a frio e a operação principal com uma versão de referência aceita no mesmo ambiente. Registre o método de medição e várias repetições. Verifique congelamentos, encerramentos inesperados, crescimento de memória após ações repetidas e atividade em segundo plano; uma impressão subjetiva de “parece rápido” é insuficiente.
Exemplo prático: teste smoke de um aplicativo de entregas
Suponha que a equipe defina cinco verificações obrigatórias para um novo build: atualização, login, carrinho, confirmação de pedido e abertura de pedido por notificação. No dispositivo principal, atualize a versão anterior com um endereço salvo, faça login, adicione um item, realize um pedido de teste e abra sua notificação.
Resultado esperado: o endereço é preservado, o valor coincide em todas as etapas, exatamente um pedido é criado, a notificação abre esse pedido e não há encerramento inesperado. Repita separadamente a confirmação com perda da resposta seguida de recuperação da rede. Em um segundo dispositivo, verifique login e conclusão do pedido. Essa execução tem limites claros; a quantidade de itens aprovados não a transforma em uma regressão completa.
Como relatar os resultados
Para cada item, use Aprovado, Reprovado, Bloqueado ou Não executado, acrescentando o ambiente e um link para o defeito. Bloqueado significa que não foi possível testar; não é aprovação. Liste os problemas bloqueantes e os riscos não cobertos no relatório, como uma atualização ainda não verificada na versão mínima do sistema operacional.
Um checklist é útil quando apoia uma decisão sobre o build. Atualize-o após incidentes e mudanças do produto, remova duplicatas e automatize verificações estáveis e repetíveis. Cada item deve explicar exatamente o que observar e por que importa.
Leitura adicional
- →Android Developers: diretrizes de qualidade básica de aplicativos
- →Android Developers: teste a acessibilidade do seu aplicativo
Transforme o checklist em uma matriz de funcionalidade × plataforma × estado
Escolha dispositivos a partir da faixa de sistemas suportados, do uso real do produto quando disponível e de riscos como pressão de memória, telas pequenas e recursos de hardware. Sem dados analíticos do produto, uma proposta de três dispositivos é uma hipótese baseada em risco, não cobertura de mercado medida: uma configuração Android mais antiga ainda suportada, uma configuração Android atual de outro fabricante e uma configuração iPhone suportada. Acrescente outras variantes de sistema e tela do iPhone quando a faixa suportada ou o risco da funcionalidade justificar.
Funcionalidade Plataforma/estado Ação Observação esperada Evidência
Formulário em rascunho Android segundo plano/retorno Inserir texto, trocar de aplicativo, retornar Estado segue a regra de salvamento acordada; sem envio duplicado Build + vídeo
Formulário em rascunho iOS inativo/segundo plano/retorno Interromper edição, retornar Estado segue a regra de salvamento acordada Build + vídeo
Câmera Cada plataforma; permissão negada Acionar recurso e negar solicitação Alternativa utilizável; explicação clara; sem encerramento inesperado Estado da permissão + vídeo
Lista salva Cada plataforma; offline/reconexão Carregar, desconectar, atualizar, reconectar Cache e nova tentativa seguem os requisitos Trace de rede + interface
Deep link Cada plataforma; abertura a frio/quente Abrir link com e sem sessão Destino correto ou fluxo seguro de login Link + estado da sessão
Atualização Cada caminho de atualização suportado Instalar novo build sobre estado antigo preparado Dados necessários preservados e migrados Build antigo/novo + comparação dos dadosNão presuma que callbacks de atividades Android e transições de cenas iOS sejam intercambiáveis. Atividades Android podem ser recriadas; o comportamento de primeiro/segundo plano do iOS segue o ciclo de vida da cena ou do aplicativo. Registre o sistema real, a ação de ciclo de vida e a recuperação observada. Teste a recusa de permissão separadamente da revogação nas configurações; as opções exatas dependem da versão do sistema e do tipo de permissão.
Em cada linha, registre Aprovado/Reprovado/Bloqueado/Não executado, dispositivo e sistema exatos, build do aplicativo, estado inicial e link de evidência sanitizada. Uma execução apenas em simulador não comprova o comportamento de uma câmera real, entrega de notificações, transição de rede ou pressão de memória do dispositivo. Selecione verificações em dispositivos reais conforme o risco da funcionalidade, em vez de afirmar cobertura de todas as configurações.
Continuar aprendendo
Permissões, interrupções e notificações
Ciclo de vida de atividades Android