Checklist de testes de sites

Um checklist de testes de sites apoia a verificação sistemática; ele não promete encontrar todos os defeitos. Seu valor está em a equipe entender o escopo, os resultados esperados e o risco restante. Uma única lista não atende igualmente bem a um site de notícias, portal bancário e painel administrativo interno.

Adapte os itens ao produto e à versão antes da execução. Uma mudança no formulário de pedidos exige outra profundidade de teste em relação à correção de um texto no rodapé. As verificações abaixo oferecem uma base: selecione as aplicáveis e acrescente riscos específicos da mudança.

Prepare o contexto dos testes

Registre o build, o ambiente, as áreas alteradas, os papéis, os dados de teste e os navegadores suportados. Identifique o fluxo crítico: qual resultado leva os usuários ao site e qual falha seria especialmente custosa?

Cada item precisa de um resultado e de evidências. Use os status “aprovado”, “defeito”, “bloqueado”, “não testado” e “não aplicável”, com explicações. Um teste pulado não pode contar como aprovado. Prepare um ambiente e dados seguros para pagamentos, e-mails e exclusões de teste.

Verifique o carregamento e a navegação

→Abra a página inicial e as páginas principais diretamente pela URL: o conteúdo correto carrega e os recursos necessários funcionam.
→Atualize uma página interna: servidor e cliente preservam a rota correta sem erro inesperado.
→Navegue para trás e para frente: a interface restaura um estado consistente e não repete uma ação acidentalmente.
→Abra um endereço inexistente: uma página de erro clara oferece um caminho para continuar, e a resposta HTTP corresponde à finalidade do recurso.
→Verifique menus, links internos e navegação para serviços externos: não há caminhos sem saída, domínios incorretos ou ciclos de redirecionamento.

Considere sessões novas e existentes. Um site recém-aberto e uma aba antiga podem receber versões diferentes de recursos e estado.

Verifique o cenário principal de negócio

Siga todo o fluxo da entrada ao resultado e depois confirme se ele foi realmente salvo. Uma mensagem de “sucesso” sozinha não confirma uma alteração de dados.

Para uma loja, isso significa encontrar um produto, usar o carrinho, finalizar a compra e consultar o pedido. Para uma base de conhecimento, significa encontrar e ler um artigo, seguir conteúdos relacionados e obter uma URL correta para compartilhar. Use papéis e dados realistas: um administrador pode contornar restrições que usuários comuns encontram.

Verifique formulários e dados

→Valores vazios, comuns e nos limites são tratados conforme o contrato; os erros ajudam o usuário a corrigir a entrada.
→O botão e Enter acionam um envio consistente, e cliques repetidos não duplicam uma operação.
→Após uma rejeição do servidor, os valores válidos permanecem e há um caminho claro para tentar novamente.
→Textos longos, caracteres cirílicos, diferentes localidades e formatos de data não corrompem os dados.
→Uploads e downloads atendem aos requisitos de tipo, tamanho, nome de arquivo e acesso.

Compare os dados inseridos, a requisição, a resposta e o estado consultado depois. Essa sequência ajuda a identificar perda de precisão ou normalização despercebida.

Confirme que login, logout, expiração de sessão e nova autenticação seguem a política do produto. Teste uma URL protegida sem login e uma operação com um papel sem a permissão necessária.

Com contas preparadas, verifique o acesso ao objeto de teste de outro usuário pela interface e pela API. Ocultar um botão não substitui o controle de acesso no servidor. Após trocar de usuário, o aplicativo não deve mostrar dados da conta anterior vindos de seu próprio estado ou de um cache usado incorretamente.

Verifique erros, comportamento da rede e recuperação

Reduza a velocidade da rede, interrompa uma requisição, reproduza um erro de servidor previsto e retorne uma resposta vazia. Espere um estado claro, um indicador de carregamento que termine e uma forma definida de continuar.

Um resultado incerto é especialmente importante: o servidor pode ter salvo um pedido sem que o cliente recebesse a resposta. Uma nova tentativa não deve criar silenciosamente um segundo pedido. Verifique a consistência no servidor e a proteção prevista contra duplicação. Use Console e Network para diagnóstico, mas avalie o resultado pelo comportamento do produto e pelos dados.

Verifique apresentação e acessibilidade

Selecione navegadores e tamanhos a partir da matriz de suporte. Conclua a ação crítica em uma janela estreita, com conteúdo longo e zoom ampliado. Painéis fixos e teclado não devem cobrir ações necessárias.

Siga o fluxo usando o teclado; verifique foco visível, rótulos dos campos, erros compreensíveis e nomes acessíveis dos botões. Use um leitor de tela quando necessário. Verificações automatizadas oferecem sinais adicionais, mas não comprovam que todos os processos são acessíveis.

Verifique a visibilidade pública e as configurações da versão

Em um site público, verifique título, descrição, canonical, regras de robots, sitemap e redirecionamentos esperados. Em um serviço privado, restrições corretas de acesso são mais importantes. Evite aplicar requisitos de indexação de busca a áreas privadas de conta.

Verifique a configuração de produção: domínios de API, links, recursos e ausência de stubs de teste ou segredos de diagnóstico. Após a implantação, faça um teste smoke curto com dados autorizados. Restrinja testes de carga e destrutivos ao ambiente designado e ao escopo previamente acordado.

Exemplo prático: uma versão do checkout

Suponha que o formulário de endereço e o cálculo de entrega tenham mudado. Priorize a conclusão da compra, os limites do endereço, a troca do método de entrega e a nova tentativa após timeout.

1.Crie um pedido de teste com um endereço comum. Espere um registro com endereço, valor e método de entrega corretos.
2.Insira um endereço longo em um telefone e corrija um erro. As mensagens e o botão devem permanecer acessíveis com o teclado aberto.
3.Altere o endereço antes de o cálculo terminar. A seleção mais recente deve prevalecer, em vez de uma resposta atrasada.
4.Repita a confirmação após uma falha de resposta simulada. Espere um status consistente, sem duplicação.
5.Verifique a consulta do pedido com outro papel de teste. As regras de acesso devem ser aplicadas.

Selecione os itens restantes conforme as dependências afetadas e o histórico de defeitos, em vez de apenas tentar concluir toda a lista.

Concluindo a execução

No relatório, vincule os defeitos aos itens do checklist e indique ambientes cobertos, bloqueios e áreas não testadas. Diferencie “não foram encontrados defeitos conhecidos” de “não há risco”: testes não podem provar a segunda afirmação.

Erros comuns incluem usar a mesma profundidade em todas as versões, omitir resultados esperados e marcar verificações bloqueadas como aprovadas. Um bom checklist apoia uma decisão de lançamento baseada em evidências e limitações declaradas.

Leitura adicional

Uma planilha de lançamento web baseada em evidências

Use uma tarefa concreta, como enviar um formulário de contato fictício. Combine as regras dos campos, o comportamento de sucesso e os navegadores suportados antes dos testes. As linhas a seguir especificam observações; são uma planilha compacta de lançamento, não uma auditoria completa de segurança ou acessibilidade. Registre os resultados reais separadamente das expectativas.

plain text

Área	Ação	Observação esperada	Evidências a coletar
Função	Enviar um formulário válido	Um envio aceito e confirmação clara	ID de requisição + interface
Validação	Enviar sem e-mail obrigatório	Erro específico; sem sucesso; requisição inválida tratada conforme contrato	Interface + log de requisições
Teclado	Concluir tarefa com Tab/Shift+Tab/Enter	Foco visível; controles acessíveis; sem armadilha de teclado	Vídeo
Rótulos	Inspecionar nomes acessíveis das entradas	Nome descreve a finalidade; erro associado ao campo	Árvore de acessibilidade
Responsividade	Usar viewports estreitos/largos acordados	Sem controles cortados; conteúdo utilizável	Viewport + captura de tela
SEO	Consultar HTML da página pública	Idioma, título, canonical e política de indexação corretos	Cabeçalhos + trecho HTML
Rede	Interromper antes/depois do envio	Sem falso sucesso; recuperação segura sem envio duplicado	Trace de rede
Dados	Consultar envio aceito	Valores persistidos correspondem à entrada e à política de acesso	Evidência sanitizada do registro

O exemplo de observação é hipotético: se o botão mostra “Enviado” enquanto a requisição retorna erro de servidor, registre o status, o horário e o estado da interface; não afirme que a mensagem foi armazenada. Da mesma forma, um timeout não prova que o servidor rejeitou a gravação. Confirme o resultado antes de tentar novamente.

As ferramentas do QA Hub podem ajudar com evidências específicas: o analisador de URL explica parâmetros de consulta, o formatador JSON torna a estrutura da resposta legível, o comparador JSON compara cargas esperadas e reais, e a referência de códigos HTTP oferece consulta. Elas não decidem se um requisito do produto foi atendido. Conclua com falhas conhecidas, escopo não testado, responsáveis e uma decisão sobre o risco do lançamento.