Como testar seu app antes do lançamento: um plano prático

Para testar seu app antes do lançamento, liste os poucos caminhos que um usuário precisa conseguir concluir, execute cada um como um usuário totalmente novo, no notebook e no celular, e depois teste as formas como ele pode dar errado: dados vazios, entradas inválidas, uma segunda conta, uma conexão lenta. Teste qualquer coisa que envolva dinheiro ou dados privados com cuidado extra, e repita os caminhos principais na URL ativa depois de publicar. Por fim, observe alguém que nunca viu o app tentar usá-lo.

Você não precisa de uma equipe de QA nem de um framework de testes para isso. Precisa de uma lista, uma ou duas horas e a disciplina de realmente percorrê-la.

Passo 1: Anote os caminhos que importam

Um caminho é uma tarefa, do início ao fim, que um usuário veio fazer. A maioria dos apps tem de três a seis que realmente importam. Para um app de agendamentos:

Criar conta e confirmar o cadastro
Encontrar uma aula e reservá-la
Cancelar uma reserva
Pagar por um pacote de aulas
Equipe: ver as reservas de hoje

Se você escreveu histórias de usuário, os critérios de aceitação delas já são seus casos de teste. Se não, escreva uma linha por caminho com o que significa “sucesso”.

Priorize-os. Os caminhos que geram dinheiro ou que todo usuário percorre (cadastro, login, a ação principal) são testados primeiro e com mais atenção.

Passo 2: Teste o caminho feliz como um novo usuário

O “caminho feliz” é o fluxo acontecendo exatamente como previsto. Teste-o como um desconhecido o viveria:

Use uma janela privada do navegador, para não estar logado e sem dados salvos.
Use uma conta nova com um e-mail real que você consiga conferir.
Comece pela página inicial ou por um link, não por uma página que você salvou nos favoritos enquanto construía.

Usuários novos não têm dados. Muitos bugs só aparecem quando uma lista está vazia, um perfil não tem foto ou ainda nada foi comprado. Sua própria conta, cheia de dados de teste, esconde esses bugs.

Passo 3: Tente quebrar o app

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

Experimente	O que você está verificando
Enviar formulários vazios, ou só com espaços	Campos obrigatórios são exigidos, com uma mensagem clara
Textos muito longos, emojis, nomes com acentos	O layout se mantém e os dados são salvos corretamente
Formatos errados: letras em um campo de telefone, uma data passada	Validação tanto na página quanto no servidor
Clicar duas vezes no botão de enviar	Nenhum pedido ou reserva duplicado
Botão voltar do navegador no meio do fluxo	Nenhum estado quebrado ou dado perdido
Atualizar em todas as páginas	Os dados persistem; nenhuma página em branco ou 404
Sair da conta e depois apertar voltar	Páginas privadas não aparecem
Duas abas editando a mesma coisa	O último salvamento não apaga silenciosamente o primeiro

A atualização de página merece destaque: se o app funciona quando você clica, mas uma atualização em uma página mais profunda mostra um 404, veja como corrigir erros 404 depois de publicar.

Passo 4: Teste as permissões com duas contas

Este é o teste mais importante para qualquer app com contas, e o que mais costuma ser pulado.

Crie dois usuários normais, A e B, e (se o seu app tiver) um administrador.

Como A, crie um registro. Entre como B. B consegue ver, editar ou excluir? Não deveria, a menos que esse seja o desenho.
Como A, copie a URL de um dos seus registros. Entre como B e abra essa URL diretamente.
Como usuário normal, abra páginas de administração digitando as URLs.
Saia totalmente da conta e tente as mesmas URLs.

Se encontrar um problema aqui, não lance até corrigi-lo. A verificação precisa acontecer no servidor, não apenas escondendo um botão. Nossa lista de segurança para apps criados com IA aprofunda o tema.

Passo 5: Teste em dispositivos reais

Abra o app em um celular de verdade, não só em uma janela de navegador estreita.

Você consegue tocar em todos os botões sem dar zoom?
O teclado cobre o campo em que você está digitando?
Tabelas e conteúdos largos rolam ou quebram linha, em vez de empurrar a página para o lado?
O texto é legível sem precisar dar zoom com os dedos?

Teste pelo menos um iPhone (Safari) e um Android (Chrome), se conseguir emprestar. O Safari, em particular, tem comportamentos próprios com datas, vídeos e elementos de posição fixa.

Passo 6: Teste dinheiro e e-mail de ponta a ponta

Tudo que cobra cartões ou envia e-mails precisa de um teste completo.

Pagamentos. Use o modo de teste do seu provedor de pagamento e os números de cartão de teste. Verifique um pagamento bem-sucedido, um cartão recusado e um checkout cancelado. Confirme que o pedido ou a assinatura aparece no seu app depois do pagamento, e não apenas no painel do provedor. Se o seu app depende de webhooks (mensagens que o provedor de pagamento envia ao seu servidor), confira se elas chegam no app publicado, e não só em desenvolvimento. Depois, antes do lançamento, troque para as chaves reais e faça uma compra real pequena que você reembolse.

E-mails. Cadastre-se com endereços reais em dois ou três provedores diferentes. Confira se os e-mails chegam, se não caem no spam e se cada link neles aponta para o domínio real, e não para um endereço de prévia.

Passo 7: Verifique velocidade e erros

Abra as ferramentas de desenvolvedor do navegador (clique com o botão direito → Inspecionar) e veja a aba Console em cada página principal. Erros em vermelho valem a pena ser corrigidos, mesmo que nada pareça quebrado.
Carregue o site no celular usando dados móveis, não Wi-Fi. Se a primeira tela demorar vários segundos, verifique primeiro o tamanho das imagens.
Rode uma auditoria gratuita como o Lighthouse nas ferramentas de desenvolvedor do Chrome para uma leitura rápida de desempenho e acessibilidade.

Passo 8: Teste o app publicado, não só a prévia

Uma prévia e um app publicado não são o mesmo ambiente. Antes de falar do lançamento para alguém, repita os principais caminhos na URL real:

Todas as variáveis de ambiente e segredos estão configurados no app publicado?
Ele está usando o banco de dados certo, com os dados que você espera?
Os redirecionamentos de login e os links de e-mail usam o domínio real?
Uma atualização em uma página profunda carrega corretamente?

Passo 9: Observe outra pessoa usando o app

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

Quando a pessoa encontrar um bug, registre-o direito, com passos, resultado esperado e resultado real. Nosso guia sobre como escrever um bom relatório de bug mostra o formato.

Usando IA para ajudar nos testes

Se você constrói com IA, pode pedir a ela que ajude a planejar e executar os testes:

Liste os principais caminhos de usuário deste app e, para cada um, os casos extremos mais propensos a quebrar: estados vazios, entradas inválidas, permissões e atualização de página. Monte uma checklist que eu possa percorrer.

Entre com dois usuários de teste diferentes e verifique se o usuário B consegue ver ou alterar algo que o usuário A criou, inclusive abrindo diretamente as URLs dos registros de A. Liste o que encontrar antes de corrigir qualquer coisa.

Trate o relatório de testes da própria IA como uma primeira passagem. Ainda assim, percorra você mesmo os caminhos de dinheiro e de permissões.

Testando no Mythex

No Mythex, o comando /test executa o App Testing: o agente controla um navegador sobre a sua prévia ao vivo, clica pelas páginas, captura capturas de tela e informa os fluxos quebrados no chat. Ele funciona melhor com um caminho específico, como “teste o cadastro e a reserva de uma aula”. Corrija o que ele encontrar com /fix ou com uma mensagem normal, e depois rode /test de novo. O App Testing usa a prévia, então confira você mesmo os principais caminhos na URL publicada depois de publicar. Veja App Testing na documentação e nosso guia sobre como depurar um app criado com IA para quando algo falhar.

Erros comuns

Testar apenas como você mesmo. Sua conta de administrador, cheia de dados, esconde bugs de estado vazio e de permissão.
Testar só no notebook. Muitos visitantes de vários sites chegam pelo celular.
Pular a segunda conta. Dados vazando entre usuários é o bug mais grave com que um app pode ser lançado.
Confiar na prévia. O app no ar tem configurações diferentes; teste-o também.
Corrigir bugs sem retestar o que está por perto. Uma correção em um formulário pode quebrar outro que compartilha código.

Checklist antes do lançamento

Principais caminhos listados e priorizados
Cada caminho funciona para um usuário totalmente novo, em janela privada
Entradas vazias, inválidas, longas e duplicadas tratadas
Atualização funciona em todas as páginas
Usuários não conseguem ver nem alterar os dados uns dos outros, nem pela URL
Páginas de administração bloqueadas para usuários normais e visitantes não logados
Funciona em um iPhone e um celular Android reais
Pagamentos testados: sucesso, recusa, cancelamento, e o app é atualizado depois
E-mails chegam, não caem no spam e apontam para o domínio real
Nenhum erro em vermelho no console das páginas principais
Principais caminhos repetidos na URL publicada
Pelo menos uma pessoa de fora testou enquanto você observava

Perguntas

Quanto teste um app pequeno precisa antes do lançamento?

O suficiente para ter confiança de que os principais caminhos funcionam para um usuário totalmente novo, tanto no celular quanto no notebook, de que os usuários não conseguem ver os dados uns dos outros e de que tudo que envolve dinheiro funciona de ponta a ponta. Para a maioria dos apps pequenos, são algumas horas concentradas, não semanas.

Preciso de testes automatizados para um MVP?

Não necessariamente. O teste manual dos caminhos principais pega a maioria dos bugs que impedem o lançamento. Os testes automatizados começam a compensar quando você muda o app com frequência e quer saber rapidamente se quebrou algo que funcionava antes.

Devo testar na prévia ou no app no ar?

Nos dois. Teste a fundo na prévia e depois repita os principais caminhos no app publicado, porque variáveis de ambiente ausentes, um banco de dados diferente ou configurações de rotas podem fazer a versão no ar se comportar de forma diferente.

Quem além de mim deve testar meu app?

Pelo menos uma pessoa que nunca o viu. Dê a ela um objetivo, não instruções, e observe sem ajudar. Quem constrói o app evita, sem perceber, os caminhos que quebram.