Teste de aplicação web (web application testing) é a verificação sistemática de aplicações que rodam no navegador — painéis SaaS, sistemas de e-commerce, ferramentas online — em oito dimensões: lógica funcional, validação de formulários, compatibilidade entre navegadores, responsividade, desempenho, segurança e acessibilidade. Este artigo traz um checklist pronto para copiar, com mais de 40 verificações, para aceite antes do lançamento, regressão de versões e smoke test de novas builds.
Teste de app web ≠ teste de site
| Dimensão | Teste de site | Teste de app web |
|---|---|---|
| Objeto típico | Site institucional, landing pages, blog | Sistemas SaaS, painéis administrativos, editores online |
| Profundidade de interação | Navegação e envio de formulários | Sessões autenticadas, fluxos de estado complexos, permissões, concorrência |
| Foco dos testes | Conteúdo, SEO, visual, rotas de conversão | Lógica de negócio, correção dos dados, tratamento de erros |
| Complexidade de estado | Baixa (praticamente sem estado) | Alta (sessões, cache, múltiplos papéis) |
Se o seu alvo é um site institucional, este checklist é pesado demais — use o Website QA Checklist. Este artigo é para "aplicações" com login e lógica de negócio.
Preparação antes de testar
- Defina o escopo do teste e a versão (registre o hash do commit ou o número da build)
- Prepare uma matriz de ambientes: pelo menos 1 ambiente de staging + um ambiente de pré-checagem em produção
- Prepare uma matriz de contas: usuário comum / administrador / deslogado, pelo menos 1 conta de cada
- Prepare os dados de teste: valores normais + valores de contorno (strings longas, caracteres especiais, valores vazios, arquivos grandes)
- Defina a ferramenta e o padrão de registro (modelo de bug: test case template)
O checklist de teste de aplicação web
A. Testes funcionais (fluxos de negócio principais)
- Percorra de ponta a ponta o fluxo cadastro → verificação de e-mail → login
- Recupere uma senha esquecida e faça login com a nova senha
- Percorra uma vez o caminho feliz de cada fluxo principal (comprar, criar, salvar)
- Teste os ramos de exceção de cada fluxo: cancelamento no meio, envio duplicado, recuperação após queda de conexão
- Verifique o isolamento de permissões: usuário comum não acessa funções de administrador (digitando a URL direto)
- Confira a consistência dos dados: listas, detalhes e contadores atualizam em sincronia após cada ação
- Garanta que páginas protegidas ficam inacessíveis após logout (o botão voltar não contorna a autenticação)
B. Validação de formulários e entradas
- Mostre uma mensagem clara e bloqueie o envio quando campos obrigatórios estiverem vazios
- Valide formatos: e-mail, telefone, data, faixas numéricas
- Teste valores de contorno: comprimento máximo, valor mínimo, 0, negativos, entradas muito longas (1000+ caracteres)
- Confirme que caracteres especiais e scripts (
<script>, emojis, trechos de SQL) são tratados com segurança - Impeça envios duplicados: um clique duplo rápido cria exatamente um registro
- Teste upload de arquivos: restrição de tipo, arquivos enormes, arquivos de 0 byte, uploads interrompidos
- Verifique se o estado do formulário faz sentido após voltar/avançar no navegador
C. Compatibilidade entre navegadores
- Chrome (versão mais recente)
- Firefox (versão mais recente)
- Safari (macOS + iOS)
- Edge (versão mais recente)
- Fique de olho nas diferenças comuns: seletores de data, downloads, comportamento de rolagem, layout CSS
D. Responsividade e mobile
- Percorra os breakpoints: larguras de 1920 / 1366 / 768 / 375
- Opere navegação, modais e tabelas no celular (sem estouro de rolagem horizontal)
- Garanta alvos de toque grandes o bastante e alternativas ao hover em telas de toque
- Alterne entre retrato e paisagem (se aplicável)
- Verifique se os campos continuam visíveis quando o teclado virtual abre
E. API e tratamento de erros
- Abra os painéis Console e Network do DevTools, percorra os fluxos principais e confirme que não há erros em vermelho
- Mostre uma mensagem amigável (não tela branca nem travamento) quando uma requisição falha (sem internet/500)
- Exiba estado de carregamento em requisições lentas; aplique debounce ou cancele requisições duplicadas
- Oriente o usuário claramente quando a sessão expira (redirecione ao login em vez de falhar em silêncio)
- Mantenha o console livre de exceções não tratadas (Uncaught Error)
F. Desempenho
- Atinga as metas de carregamento inicial (recomendado < 3s, LCP < 2.5s)
- Evite travamentos em listas grandes / páginas com muitos dados (teste com volumes reais)
- Comprima as imagens e use lazy loading
- Procure sinais de vazamento de memória (app visivelmente mais lenta após uso prolongado)
G. Fundamentos de segurança
- Bloqueie acesso por URL ou API a recursos protegidos sem login ou sem permissão
- Transmita todos os dados sensíveis em HTTPS em todo o site
- Nunca exiba senhas em texto puro
- Não deixe tokens sensíveis nas URLs (ou os mascara e faça expirar)
- Não exponha stack traces nem detalhes técnicos ao usuário final nas mensagens de erro
H. Acessibilidade e detalhes
- Conclua as ações principais só com o teclado (ordem do Tab, Enter para enviar)
- Adicione texto alt às imagens e associe labels aos controles de formulário
- Mantenha o contraste de cor em conformidade com WCAG AA (4.5:1) ou superior
- Desenhe os estados vazio, de carregamento e de erro (nunca uma tela em branco)
Como registrar e acompanhar os resultados
| Prática | O que significa |
|---|---|
| Anexar evidência a cada defeito | Anote um screenshot marcando o ponto de reprodução; grave a tela em problemas de interação |
| Capturar o contexto técnico automaticamente | Use uma ferramenta que registre erros de Console/Network (ex.: BugCapturer) em vez de copiar à mão |
| Arquivar de forma estruturada | Exporte a lista de defeitos para Excel (ID/módulo/passos/esperado/obtido/severidade/status) |
| Tornar os resultados compartilháveis | Gere um link de compartilhamento em vez de enviar arquivos quando outros times precisam validar |
O modo diagnóstico do BugCapturer resolve os três itens do meio de uma vez: ao tirar screenshot ou gravar a tela, ele captura automaticamente os erros de Console e Network, exporta um Excel de 12 colunas com um clique e gera links de compartilhamento sem instalação para desenvolvedores ou clientes. Os detalhes estão na página do recurso de diagnóstico; a estrutura completa do relatório está em How to Export Bug Reports to Excel.
Para a validação final antes do lançamento, organize uma rodada de teste de aceitação do usuário conforme o UAT Complete Guide, usando este checklist como roteiro de execução.
FAQ
Quanto tempo leva o teste de uma aplicação web?
Depende do escopo: smoke test de uma versão nova, 0,5–1 dia; regressão completa, 2–5 dias; lançamentos grandes costumam reservar 1–2 semanas (incluindo a verificação das correções). Percorrer os 8 grupos deste checklist leva cerca de 1–2 dias-pessoa.
Como dividir testes manuais e automatizados?
Regra prática: cubra A/B/C/D manualmente primeiro (principalmente no primeiro lançamento) e, depois de estabilizar, automatize os caminhos de regressão frequentes (login, fluxos principais). O grupo E (checagem de Console/Network) pode ser coletado por ferramentas; segurança (G) merece complemento com scanners profissionais e auditoria de código.
Qual a relação entre este checklist e o plano de testes?
O checklist responde "o que testar"; o Test Plan Template responde "quem testa, em qual ambiente, quando e com quais critérios de aprovação". Defina o plano primeiro e execute o checklist depois: os dois documentos funcionam juntos.
Como usar este checklist sem um time de QA?
Divida: desenvolvimento auto-testa A/B/E (o técnico), produto valida A/D (negócio e experiência) e, antes do lançamento, faça um bug bash de 2 horas com todo mundo (organização no Bug Bash Guide). Registre tudo com um modelo que inclua screenshots e informações de diagnóstico para reduzir o custo de comunicação.
Conclusão
A chave do teste de aplicação web não é "testar com muita força", e sim cobrir todas as dimensões + deixar cada resultado rastreável: avance pelas oito dimensões — funcional, formulários, compatibilidade, responsividade, erros, desempenho, segurança, acessibilidade — e arquive cada achado como "screenshot anotado + diagnóstico de Console/Network + registro estruturado". Você pode copiar este checklist direto para o seu plano de testes como roteiro de execução.
Leitura adicional: Website QA Checklist · Test Plan Template · UAT Complete Guide