Como Testar a Sua App Antes do Lançamento: Um Plano Prático de Pré-Lançamento

Para testar a sua app antes do lançamento, liste os poucos percursos que um utilizador tem de conseguir concluir, execute cada um como um utilizador totalmente novo num portátil e num telemóvel, e depois tente as formas como podem correr mal: dados vazios, entradas erradas, uma segunda conta, uma ligação lenta. Teste qualquer coisa que envolva dinheiro ou dados privados com cuidado extra, e repita os percursos principais no URL em produção depois de publicar. Termine observando alguém que nunca viu a app tentar usá-la.

Não precisa de uma equipa de QA nem de uma framework de testes para isto. Precisa de uma lista, uma ou duas horas e da disciplina de a percorrer de facto.

Passo 1: Escreva os percursos que importam

Um percurso é uma tarefa, do início ao fim, que um utilizador vem fazer. A maioria das apps tem entre três e seis que realmente importam. Para uma app de marcações:

Registar-se e confirmar a conta
Encontrar uma aula e marcá-la
Cancelar uma marcação
Pagar um passe de aulas
Equipa: ver as marcações de hoje

Se já escreveu histórias de utilizador, os respetivos critérios de aceitação já são os seus casos de teste. Se não, escreva uma linha por percurso com o que é o «sucesso».

Ordene-os por prioridade. Os percursos que geram dinheiro ou que todos os utilizadores percorrem (registo, início de sessão, a ação central) são testados primeiro e com mais atenção.

Passo 2: Teste o caminho feliz como um utilizador novo

O «caminho feliz» é o percurso a correr exatamente como previsto. Teste-o como um estranho o viveria:

Use uma janela de navegação privada, para não ter sessão iniciada nem dados guardados.
Use uma conta nova com um email real a que consiga aceder.
Comece na página inicial ou num link, e não numa página que tenha guardado nos favoritos enquanto construía a app.

Os utilizadores novos não têm dados. Muitos erros só aparecem quando uma lista está vazia, um perfil não tem foto ou ainda não foi comprado nada. A sua própria conta, cheia de dados de teste, esconde-os.

Passo 3: Tente partir a app

Agora repita cada percurso e faça de propósito a coisa errada.

Experimente isto	O que está a verificar
Enviar formulários vazios, ou só com espaços	Os campos obrigatórios são exigidos, com uma mensagem clara
Texto muito longo, emojis, nomes com acentos	O layout aguenta e os dados são guardados corretamente
Formatos errados: letras num campo de telefone, uma data passada	Validação tanto na página como no servidor
Clicar duas vezes no botão de envio	Nenhuma encomenda ou marcação duplicada
Botão de voltar do navegador a meio de um fluxo	Nenhum estado partido nem dados perdidos
Atualizar em cada página	Os dados persistem; nenhuma página em branco nem 404
Terminar sessão e depois carregar em voltar	As páginas privadas não aparecem
Dois separadores a editar a mesma coisa	A última gravação não apaga silenciosamente a primeira

Vale a pena destacar a atualização: se a app funciona quando clica pelos ecrãs, mas uma atualização numa página mais profunda mostra um 404, veja como corrigir erros 404 após publicar.

Passo 4: Teste as permissões com duas contas

Este é o teste mais importante para qualquer app com contas, e o que mais vezes se salta.

Crie dois utilizadores normais, A e B, e (se a sua app os tiver) um administrador.

Como A, crie um registo. Inicie sessão como B. Consegue B vê-lo, editá-lo ou eliminá-lo? Não deveria, a menos que esse seja o desenho.
Como A, copie o URL de um dos seus registos. Inicie sessão como B e abra esse URL diretamente.
Como utilizador normal, abra páginas de administração escrevendo os respetivos URLs.
Termine a sessão por completo e experimente os mesmos URLs.

Se encontrar um problema aqui, não lance antes de o corrigir. A verificação tem de acontecer no servidor, e não apenas escondendo um botão. A nossa lista de verificação de segurança para apps criadas com IA aprofunda o tema.

Passo 5: Teste em dispositivos reais

Abra a app num telemóvel a sério, e não apenas numa janela estreita do navegador.

Consegue tocar em cada botão sem ampliar?
O teclado tapa o campo onde está a escrever?
As tabelas e o conteúdo largo fazem scroll ou quebram linha, em vez de empurrar a página para o lado?
O texto é legível sem fazer pinça?

Teste pelo menos um iPhone (Safari) e um telemóvel Android (Chrome), se conseguir pedir emprestados. O Safari, em particular, tem particularidades próprias com datas, vídeo e elementos de posição fixa.

Passo 6: Teste o dinheiro e o email de ponta a ponta

Tudo o que cobre cartões ou envia emails precisa de uma execução completa.

Pagamentos. Use o modo de teste do seu fornecedor de pagamentos e os números de cartão de teste. Verifique um pagamento bem-sucedido, um cartão recusado e um checkout cancelado. Confirme que a encomenda ou a subscrição aparece na sua app depois do pagamento, e não apenas no painel do fornecedor. Se a sua app depender de webhooks (mensagens que o fornecedor de pagamentos envia ao seu servidor), confirme que chegam à app publicada, e não apenas em desenvolvimento. Depois, antes do lançamento, mude para chaves reais e faça uma pequena compra real que possa reembolsar.

Emails. Registe-se com endereços reais em dois ou três fornecedores diferentes. Verifique que os emails chegam, não caem no spam e que todos os links neles apontam para o domínio em produção, e não para um endereço de pré-visualização.

Passo 7: Verifique a velocidade e os erros

Abra as ferramentas de programador do navegador (botão direito → Inspecionar) e veja o separador Consola em cada página principal. Os erros a vermelho merecem correção, mesmo que nada pareça avariado.
Carregue o site num telemóvel com dados móveis, e não com Wi-Fi. Se o primeiro ecrã demorar vários segundos, comece por verificar o tamanho das imagens.
Execute uma auditoria gratuita como o Lighthouse nas ferramentas de programador do Chrome para uma leitura rápida do desempenho e da acessibilidade.

Passo 8: Teste a app publicada, e não apenas a pré-visualização

Uma pré-visualização e uma app publicada não são o mesmo ambiente. Antes de falar do lançamento a alguém, repita os percursos principais no URL em produção:

Estão definidas todas as variáveis de ambiente e segredos na app publicada?
Está a usar a base de dados certa, com os dados que espera?
Os redirecionamentos de início de sessão e os links de email usam o domínio em produção?
Uma atualização numa página profunda carrega corretamente?

Passo 9: Observe outra pessoa a usar a app

Dê a uma ou duas pessoas um objetivo («marcar uma aula de yoga para sábado»), e não instruções. Observe, não ajude, e escreva onde hesitam. É a forma mais rápida de encontrar textos confusos e botões escondidos. Para uma versão mais ampla disto, veja como fazer um teste beta.

Quando encontrarem um erro, registe-o bem, com os passos, o resultado esperado e o resultado real. O nosso guia sobre como escrever um bom relatório de erro mostra o formato.

Usar a IA para ajudar nos testes

Se constrói com IA, pode pedir-lhe ajuda para planear e executar testes:

Lista os principais percursos de utilizador desta app e, para cada um, os casos limite com mais probabilidade de falhar: estados vazios, entradas inválidas, permissões e atualização. Coloca isto numa lista de verificação que eu possa percorrer.

Inicia sessão com dois utilizadores de teste diferentes e verifica se o utilizador B consegue ver ou alterar algo que o utilizador A criou, incluindo abrindo diretamente os URLs dos registos de A. Indica o que encontrares antes de corrigir fosse o que fosse.

Trate o relatório de testes da própria IA como uma primeira passagem. Continue a percorrer você mesmo os percursos de dinheiro e de permissões.

Testar na Mythex

Na Mythex, o comando /test executa o App Testing: o agente conduz um navegador sobre a sua pré-visualização em tempo real, percorre as páginas, capta capturas de ecrã e comunica os fluxos que falham no chat. Funciona melhor com um percurso específico, como «testar o registo e marcar uma aula». Corrija o que for encontrado com /fix ou com uma mensagem normal, e depois volte a executar /test. O App Testing usa a pré-visualização, por isso verifique você mesmo os percursos principais no URL publicado depois de publicar. Veja App Testing na documentação, e o nosso guia sobre como depurar uma app criada com IA para quando algo falhar.

Erros comuns

Testar apenas como você. A sua conta de administrador, com muitos dados, esconde erros de estados vazios e de permissões.
Testar apenas num portátil. A maioria dos visitantes de muitos sites chega num telemóvel.
Saltar a segunda conta. Os dados que vazam entre utilizadores são o erro mais grave com que uma app pode ser lançada.
Confiar na pré-visualização. A app em produção tem definições diferentes; teste-a também.
Corrigir erros sem voltar a testar o que está perto. Uma correção num formulário pode partir outro que partilha código.

Lista de verificação de pré-lançamento

Percursos principais listados e ordenados por prioridade
Cada percurso passa como utilizador totalmente novo numa janela privada
Entradas vazias, inválidas, longas e duplicadas tratadas
A atualização funciona em todas as páginas
Os utilizadores não conseguem ver nem alterar os dados uns dos outros, nem sequer pelo URL
Páginas de administração bloqueadas para utilizadores normais e para visitantes sem sessão
Funciona num iPhone e num telemóvel Android reais
Pagamentos testados: sucesso, recusa, cancelamento, e a app atualiza-se depois
Os emails chegam, evitam o spam e apontam para o domínio em produção
Sem erros a vermelho na consola nas páginas principais
Percursos principais repetidos no URL publicado
Pelo menos uma pessoa externa a experimentou enquanto observava

Perguntas

Quantos testes precisa uma app pequena antes do lançamento?

Os suficientes para ter confiança de que os percursos principais funcionam para um utilizador totalmente novo num telemóvel e num portátil, de que os utilizadores não conseguem ver os dados uns dos outros e de que tudo o que envolve dinheiro funciona de ponta a ponta. Para a maioria das apps pequenas, são algumas horas focadas, e não semanas.

Preciso de testes automáticos para um MVP?

Não necessariamente. Testar manualmente os percursos centrais apanha a maioria dos erros que bloqueiam o lançamento. Os testes automáticos começam a compensar quando altera a app com frequência e quer saber rapidamente se estragou algo que funcionava antes.

Devo testar na pré-visualização ou na app em produção?

Nas duas. Teste a fundo na pré-visualização e depois repita os percursos principais na app publicada, porque variáveis de ambiente em falta, uma base de dados diferente ou definições de encaminhamento podem fazer a versão em produção comportar-se de forma diferente.

Quem deve testar a minha app para além de mim?

Pelo menos uma pessoa que nunca a tenha visto. Dê-lhe um objetivo, e não instruções, e observe sem ajudar. Quem constrói a app evita, inconscientemente, os caminhos que falham.