Auditoria de uma aplicação móvel: checklist antes de redesenhar

Definir a decisão e o horizonte

Escreva a pergunta principal antes de abrir o repositório. A plataforma aguenta o crescimento? Porque é que os utilizadores abandonam uma reserva? Uma nova equipa consegue publicar sem depender do fornecedor atual? Reparar é mais económico do que reconstruir? Fixe também o horizonte. Uma versão urgente para o próximo mês não exige o mesmo detalhe que um plano de evolução para três anos.

O âmbito deve nomear aplicações, sistemas operativos, mercados, perfis, versões, serviços de backend e integrações. Essa fronteira impede que a auditoria se torne uma pesquisa interminável e permite relacionar cada teste com uma decisão.

Reunir provas, acessos e proprietários

Comece por objetivos, modelo de receita, percursos, avaliações nas lojas, pedidos de suporte, motivos de cancelamento, métricas, relatórios de falhas, histórico de versões e ficheiros de design. Acrescente repositórios, documentação de API, ambiente de teste e serviços externos.

Crie um registo que mostre quem controla App Store Connect, Google Play Console, alojamento, domínios, código, métricas, notificações, pagamentos e certificados. Um acesso em falta pode impedir a publicação e deve ser tratado como risco do produto. O nosso guia de documentação e transição descreve os materiais que uma nova equipa deve receber.

Testar o resultado que a aplicação promete

Peça ao responsável de produto que identifique o utilizador principal e o resultado útil que esse utilizador deve obter na primeira sessão. Depois confronte a promessa com o comportamento atual. Numa plataforma de comércio, o problema pode estar na operação do vendedor; numa aplicação de cursos, no progresso que desaparece; numa reserva, na alteração de horário.

Agrupe pedidos de suporte, entrevistas e avaliações por percurso e consequência. Não use apenas a contagem. Duas cobranças sem encomenda confirmada são mais graves do que dezenas de preferências visuais. Quando não existe prova suficiente, registe a incerteza em vez de inventar uma explicação.

Escolha cinco a oito tarefas críticas. Teste instalação limpa, regresso do utilizador, rede fraca, permissões recusadas, sessão expirada, pagamento interrompido e recuperação após erro, em dispositivos reais. Para cada caso, anote o estado inicial, a ação, o resultado esperado, o resultado observado e a prova.

Confirmar as métricas antes de interpretar o funil

Um evento duplicado aumenta artificialmente a conversão. Um evento de compra enviado antes da confirmação transforma uma tentativa falhada num sucesso. Compare o plano de eventos com o código e percorra inscrição, reserva ou pagamento com uma conta conhecida. Verifique nomes, momento e parâmetros, e reconcilie transações com o backend ou o prestador de pagamentos.

O tráfego de desenvolvimento deve estar separado, as versões identificadas e os conceitos alinhados entre iOS e Android. Se a medição não for fiável, as conclusões sobre o funil são provisórias. O nosso guia de configuração de métricas numa aplicação móvel mostra como preparar uma base coerente.

Avaliar estabilidade, desempenho e acessibilidade

Segmente falhas e bloqueios por versão, sistema, dispositivo, mercado e percurso. O Android Vitals acompanha falhas sentidas pelo utilizador e ANR; a documentação do Android Vitals explica as métricas principais e os problemas por dispositivo. Em produtos Apple, o App Store Connect App Analytics reúne sinais de aquisição, utilização e desempenho.

Meça abertura, autenticação, pesquisa, pagamento, envio e sincronização em redes boas e fracas, incluindo contas com muitos dados. Uma média aceitável pode esconder clientes valiosos que esperam dez segundos em cada ação. Ao analisar falhas, confirme ainda a cobertura da ferramenta. O guia de métricas do Crashlytics distingue utilizadores sem falhas de sessões sem falhas.

Inclua acessibilidade nos mesmos percursos: aumento de texto, contraste, ordem de foco, leitor de ecrã, dimensão das áreas de toque, movimento e mensagens de erro. Uma verificação automática não substitui testes com tecnologias de apoio. A explicação da Accessible.org sobre auditoria móvel ajuda a definir o trabalho manual.

Seguir a ação do telemóvel até à base de dados

A revisão técnica mede risco de alteração, não a popularidade da tecnologia. Observe fronteiras entre módulos, regras duplicadas, dependências antigas, testes, erros, segredos, configuração e capacidade de gerar uma versão numa máquina limpa. Um projeto que só compila no computador de uma pessoa tem um risco operacional evidente.

Escolha dois percursos e siga-os pelo código móvel, API, base de dados e serviços externos. Onde se valida a informação? Como funcionam novas tentativas e pedidos repetidos? O que fica em cache? Como são lançadas e revertidas as migrações? Esta análise pode revelar, por exemplo, que recuperar a rede cria duas encomendas.

Pergunte também que dados são recolhidos, onde ficam, durante quanto tempo e como são exportados ou eliminados. Produtos de saúde, infância, finanças ou localização precisam de especialistas jurídicos e de segurança adequados. A auditoria geral identifica essa necessidade, mas não substitui esses trabalhos.

Demonstrar a publicação e a recuperação

Peça à equipa que crie uma versão assinada, execute testes, publique uma alteração do servidor e explique como reverter. Compare a prática com a documentação. Verifique ambientes, integração contínua, segredos, alertas, funcionalidades controladas e responsabilidades em incidentes.

Confirme direitos sobre código, designs, tipos de letra, imagens e bibliotecas pagas. As contas principais devem pertencer à empresa e conceder acessos individuais por função. Partilhar uma palavra-passe pessoal não resolve uma transição.

Transformar problemas em cinco decisões

Classifique impacto e confiança separadamente. Uma falha de pagamento provável, mas ainda não reproduzida, exige investigação rápida; não prova, por si só, que toda a aplicação deve ser substituída.

Associe uma ação a cada componente:

• Manter: funciona, tem proprietário e suporta o roteiro.
• Reparar: o defeito é limitado e pode ser corrigido diretamente.
• Refatorizar: o comportamento é válido, mas a estrutura interna torna mudanças inseguras.
• Redesenhar: a tecnologia funciona, porém o percurso confunde ou bloqueia pessoas.
• Reconstruir: alterar gradualmente custa mais ou mantém um risco relevante.

Uma reconstrução precisa de razões verificáveis: tecnologia sem suporte, tratamento inseguro de dados, publicação não reproduzível ou custos estruturais de mudança. Código antigo não é prova suficiente. Veja também a diferença entre redesenho e modernização e o guia sobre custo de redesenhar uma aplicação.

O relatório que permite avançar

O documento final deve incluir âmbito, registo de provas, arquitetura atual, percursos testados, confiança nas métricas, base de estabilidade, falhas de propriedade, recomendações ordenadas e plano por etapas. Para cada conclusão importante, indique consequência, prova, recomendação, dependência, responsável e dimensão aproximada.

Separe um plano de estabilização de 30 dias do desenvolvimento posterior. Assim, acessos, falhas ou pagamentos urgentes não desaparecem dentro de um grande projeto visual. Esta divisão também melhora a estimativa: a equipa calcula trabalho observado em vez de adicionar uma margem enorme para o desconhecido.

Na Appfyl, a auditoria serve para preservar o que já tem valor. O resultado pode ser uma versão de correção, um redesenho de alguns percursos ou um backend reforçado. Só indicamos uma reconstrução total quando as provas mostram que mudar por partes seria mais caro ou manteria risco material. Pode descrever o produto no brief de estimativa da Appfyl.

Perguntas frequentes