Checklist de QA de websites: testar antes de lançar

Uma checklist de QA de websites é a lista de testes que um site tem de passar antes do lançamento: conteúdos, links, formulários, dispositivos, velocidade, acessibilidade, bases de pesquisa, consentimento, segurança, análise de tráfego e cópias de segurança. Percorra-a por uma ordem fixa, registe cada falha num só sítio, corrija, volte a testar e lance apenas quando não restar nada que bloqueie. Este guia apresenta a checklist completa por área, um processo de QA numerado, uma tabela dos tipos de teste com quem os faz e quando, e as respostas às perguntas que as empresas mais fazem.

Última atualização: 19 de outubro de 2026.

O que é o QA de um website, e porque importa?

A garantia de qualidade (QA, do inglês quality assurance) é a verificação planeada de um website face ao que deve fazer, antes de os visitantes reais encontrarem as falhas por si. Não é uma volta rápida pela página inicial no portátil do programador. É um conjunto de testes, feitos em dispositivos reais e em browsers reais, com um registo do que falhou e a prova de que foi corrigido.

Importa porque o lançamento é o momento em que um site é julgado por todos ao mesmo tempo: clientes, motores de pesquisa e quem quer saber se os seus formulários lhe chegam. Um formulário de contacto avariado, um banner de cookies que carrega rastreadores antes do consentimento ou uma página que não faz scroll num telemóvel podem custar mais do que toda a fase de testes.

Na Odduel, uma agência de criatividade e tecnologia em Barcelona e São Paulo, o QA faz parte de cada projeto do nosso trabalho de criação de websites, não é um extra no fim. Grande parte da verificação repetitiva (rastreio de links, capturas de ecrã em muitas larguras, verificação da composição em vários idiomas) é feita por scripts, para que as pessoas dediquem o seu tempo ao que exige juízo: lê-se bem, transmite a sensação certa, funciona para quem usa um teclado ou um leitor de ecrã.

Em resumo: o QA é o que transforma um site que funciona num ecrã num site que funciona para todos. Precisa de uma checklist escrita, de dispositivos reais, de um registo de falhas e de uma segunda passagem depois das correções. Comece quando os conteúdos estiverem finais, não na manhã do lançamento. Reserve tempo para as correções que vai encontrar.

Quando devem começar os testes de um website?

Os testes devem começar muito antes da última semana. Algumas verificações pertencem ao design (contraste, tamanho das áreas de toque, ordem dos títulos), outras ao desenvolvimento (formulários, composição responsiva), e a passagem completa pertence ao fim, quando os conteúdos estiverem finais.

Uma regra útil: não se termina o QA com texto provisório. Os títulos reais são mais longos, as fotografias reais são mais pesadas e as páginas legais reais mudam o rodapé. Planeie a passagem completa depois de os conteúdos estarem fechados e reserve espaço para uma ronda completa de correções e novos testes. Se o plano inclui um site de testes, teste lá primeiro e repita as verificações críticas no endereço definitivo logo a seguir ao lançamento, porque servidores, caches e certificados são diferentes.

Se ainda está a escolher como o site vai ser construído, o nosso guia de criação de websites cobre as fases que vêm antes desta.

A checklist de QA de websites, área a área

Cada área abaixo indica o que testar. Marque cada linha como aprovada, falhada ou não aplicável, e registe cada falha com o endereço da página, o dispositivo, o browser e uma captura de ecrã.

Conteúdos e textos

Todas as páginas têm o texto final: sem lorem ipsum, sem “XX”, sem notas de rascunho.
A ortografia e a gramática estão revistas em cada idioma do site.
Nomes, moradas, números de telefone e horários coincidem exatamente com os dos seus outros perfis.
Datas, preços e denominações legais estão atualizados e coerentes entre páginas.
As imagens são as versões finais, bem enquadradas em todas as larguras, com texto alternativo útil.
Os títulos seguem uma ordem lógica: um H1 por página, depois H2, depois H3.
As páginas legais (privacidade, cookies, aviso legal) estão publicadas e ligadas a partir do rodapé.
Nenhuma palavra fica sozinha na última linha de um título nas larguras mais comuns.

Links e navegação

Um rastreador não encontra links internos partidos (nenhum erro 404).
Os links externos abrem a página certa e continuam a funcionar.
O menu principal, o menu do rodapé e o caminho de navegação funcionam em todas as páginas.
Os endereços antigos de um site anterior redirecionam com um 301 para os novos.
Os links de telefone ligam, os de email abrem com o endereço certo e os de mapas abrem o trajeto.
A página 404 existe, tem design e ajuda o visitante a encontrar o caminho de volta.

Formulários

Todos os formulários enviam, e a mensagem chega à caixa de correio certa.
O visitante vê uma confirmação clara, e o email de confirmação, se existir, chega e lê-se bem.
Os campos obrigatórios, as mensagens de erro e a validação funcionam, incluindo com o formulário vazio.
Os erros são anunciados com clareza e o foco passa para o primeiro campo errado.
A proteção contra spam funciona sem bloquear pessoas reais.
A caixa de consentimento, quando é precisa, não vem assinalada e tem link para a política de privacidade.
Os dados dos formulários só são guardados ou reencaminhados onde a sua política de privacidade diz.

Browsers e dispositivos

Versões atuais do Chrome, Safari, Firefox e Edge no computador.
Safari no iPhone e Chrome no Android, em telemóveis reais, não apenas num emulador.
Larguras comuns, dos telemóveis pequenos aos ecrãs largos de computador, na vertical e na horizontal.
Toque: os menus abrem e fecham, nada depende de passar o rato, as áreas de toque são suficientemente grandes.
As animações e os efeitos de scroll comportam-se bem e respeitam a definição do sistema para reduzir o movimento.
O site continua a funcionar, no essencial, quando um script não carrega.

Cinco ecrãs de telemóvel do website da Fab Mater sobre vermelho, com as páginas que um teste de dispositivos percorre uma a uma

Desempenho e Core Web Vitals

Meça as três Core Web Vitals que a Google descreve na sua documentação do Search Central: Largest Contentful Paint (carregamento), Interaction to Next Paint (capacidade de resposta) e Cumulative Layout Shift (estabilidade visual).
Teste as páginas mais pesadas, não apenas a página inicial: um artigo longo, uma galeria, uma página de produto.
As imagens estão em formatos modernos, dimensionadas para o espaço que ocupam e com carregamento diferido abaixo do primeiro ecrã.
Os tipos de letra estão alojados no próprio servidor ou pré-carregados, com uma alternativa que evita saltos nas linhas.
A cache e a compressão estão ativas, e os ficheiros estáticos têm tempos de cache longos.
Nenhum script de terceiros bloqueia a primeira apresentação da página.

O website da Torto Cozinha num portátil sobre a mesa de um restaurante, uma página cuja velocidade de carregamento se mede antes do lançamento

Acessibilidade

Use como meta de trabalho a WCAG 2.2, nível AA, a diretriz atual do W3C.
Todas as páginas se usam apenas com o teclado, com um contorno de foco visível.
O contraste do texto atinge 4,5:1 no texto corrido e 3:1 no texto grande, sobre a cor de fundo real.
As imagens têm texto alternativo que as descreve, e as imagens decorativas têm um alt vazio.
Os campos dos formulários têm etiquetas, e os erros não são indicados apenas pela cor.
Um teste com leitor de ecrã (VoiceOver ou NVDA) nos percursos principais: página inicial, um serviço, o formulário de contacto.
Se vende produtos ou certos serviços a consumidores na UE, verifique se se aplica o Ato Europeu de Acessibilidade: a Diretiva (UE) 2019/882 aplica-se desde 28 de junho de 2025, com isenções para as microempresas que prestam serviços.

Bases de SEO

Cada página tem um título e uma meta description únicos.
Os endereços são curtos, em minúsculas e com hífenes; o nosso guia sobre URLs amigáveis para SEO explica como os escolher.
Cada página tem um link canónico, e as páginas traduzidas têm hreflang.
Existe um sitemap XML e lista apenas as páginas que quer que sejam encontradas.
O robots.txt permite o acesso ao site definitivo, e não ficou nenhum “noindex” do site de testes.
Os dados estruturados (organização, artigos, caminho de navegação) validam sem erros.
A imagem e o título de partilha aparecem corretamente quando se cola um link numa app de mensagens.

Privacidade, consentimento e banner de cookies

Nenhum rastreador de análise ou de publicidade carrega antes de o visitante o aceitar, como exigem o RGPD e as regras de privacidade eletrónica.
Recusar é tão fácil como aceitar, e a escolha fica memorizada.
O visitante pode mudar a sua escolha mais tarde a partir de um link no rodapé.
A política de cookies lista todos os cookies e chaves de armazenamento do browser que o site usa de facto.
Os vídeos incorporados, os mapas e os widgets de chat também esperam pelo consentimento, ou usam um modo que respeita a privacidade.

Segurança

HTTPS em todos os endereços, com o certificado válido e renovado automaticamente.
O HTTP e a versão com www redirecionam para um único endereço preferido.
Os cabeçalhos de segurança estão definidos (HSTS, tipo de conteúdo, proteção contra frames, política de referência).
As áreas de administração usam palavras-passe fortes e autenticação em dois passos; as contas predefinidas foram removidas.
O software, os temas e os plugins estão atualizados, e os que não se usam foram removidos.
Os formulários e as páginas de início de sessão estão limitados contra tentativas repetidas.
Nenhum ficheiro de teste, cópia de segurança ou ficheiro de configuração pode ser descarregado da web.

Análise de tráfego e rastreio

A análise regista as visualizações de páginas e os eventos que importam (formulário enviado, chamada clicada, compra).
O tráfego de teste é filtrado, ou assinalado, para que os números da semana do lançamento fiquem limpos.
O modo de consentimento, quando usado, transmite a escolha do visitante a cada etiqueta.
A Search Console e outras ferramentas para webmasters estão verificadas, e o sitemap foi submetido.

Cópias de segurança e o caminho de volta

Existe uma cópia de segurança completa dos ficheiros e da base de dados antes do lançamento, guardada fora do servidor.
As cópias de segurança automáticas estão agendadas, e um restauro já foi testado de facto.
Sabe como repor a versão anterior em minutos se o lançamento correr mal.
A monitorização da disponibilidade está ativa e os alertas chegam a uma pessoa que pode agir.

Como fazer o controlo de qualidade (QA) de um website, passo a passo?

Uma checklist só funciona dentro de um processo. Esta é a ordem que seguimos.

Feche os conteúdos. Acorde que textos, imagens e páginas legais são finais para esta ronda.
Escreva o plano de testes. Liste as páginas, os percursos, os browsers, os dispositivos e as larguras que vai cobrir, e quem testa o quê.
Corra as verificações automáticas. Rastreio de links, validação de HTML, análise de acessibilidade, medições de desempenho, capturas de ecrã em muitas larguras.
Faça as verificações manuais. Percorra cada percurso principal em dispositivos reais: encontrar um serviço, ler um artigo, enviar um formulário, mudar de idioma.
Registe cada falha num só sítio. Endereço, dispositivo, browser, passos para a reproduzir, captura de ecrã e uma gravidade: bloqueante, grave ou menor.
Corrija e volte a testar. Cada correção é verificada por alguém que não a fez, e a área à volta é testada outra vez.
Faça a revisão de avançar ou não avançar. Lance apenas quando não houver nenhuma falha bloqueante em aberto e as graves estiverem acordadas por escrito.
Lance e teste o site definitivo. Repita as verificações críticas no endereço real na primeira hora: formulários, consentimento, redirecionamentos, HTTPS, análise de tráfego.
Acompanhe a primeira semana. Verifique os registos de erros, o registo de 404, a entrega dos formulários e a Search Console, e corrija o que os visitantes reais revelarem.

Que testes são precisos, e quem os faz?

Nem todos os testes precisam de um especialista, e nem todos podem ser automatizados. A tabela abaixo mostra os principais tipos, quem costuma fazê-los, quando e o tipo de ferramenta usada.

Tipo de teste	Quem o faz	Quando	Ferramentas habituais
Revisão dos conteúdos	Cliente e copywriter	Depois de fechados os conteúdos	Uma checklist, um segundo leitor
Verificação de links e redirecionamentos	Programador	Antes e depois do lançamento	Um rastreador de sites, registos do servidor
Teste de formulários e emails	Programador e cliente	Antes do lançamento, depois no site definitivo	Envios reais para caixas de correio reais
Browsers e dispositivos	Tester de QA ou programador	Passagem final	Telemóveis reais, serviços de teste de browsers
Desempenho	Programador	Durante o desenvolvimento e na passagem final	Lighthouse, PageSpeed Insights, dados de utilizadores reais
Acessibilidade	Designer e programador	Design, desenvolvimento e passagem final	Análise automática, teclado, leitor de ecrã
Bases de SEO	Responsável de SEO ou programador	Passagem final e dia do lançamento	Rastreador, Search Console, teste de dados estruturados
Consentimento e privacidade	Programador e consultor jurídico	Passagem final	Ferramentas de programador do browser, a política de cookies
Segurança	Programador ou administrador do servidor	Antes do lançamento, depois com regularidade	Verificação de cabeçalhos, relatórios de atualizações, limites de acesso
Aceitação pelo utilizador	Cliente	Último passo antes do lançamento	Os percursos reais, uma folha de aprovação

Tipos de teste de um website, quem costuma fazê-los, quando e ferramentas habituais

O padrão a reter: as ferramentas automáticas são rápidas e exaustivas no que se pode medir, e as pessoas são precisas para tudo o que exige juízo. Um analisador diz-lhe que um botão não tem etiqueta; só uma pessoa lhe diz que a etiqueta é confusa.

Quanto tempo demora o QA de um website, e de que depende?

O tempo depende da dimensão do site, do número de modelos de página, do número de idiomas, de quantos formulários e integrações tem e de quantos dispositivos se compromete a cobrir. Um pequeno site institucional com um formulário testa-se bem depressa. Um site multilingue com loja, sistema de reservas e animação à medida precisa de dias de passagens cuidadosas e de pelo menos uma ronda de correções.

O que mais atrasa o QA não são os testes em si, mas os conteúdos que chegam tarde, a falta de um responsável claro pelas correções e a ausência de uma escala de gravidade acordada. Quando todos sabem o que significa “bloqueante”, a decisão de avançar ou não torna-se simples.

Para uma única página de campanha a lista é mais curta, e a lógica do orçamento é outra; o nosso artigo Quanto custa uma landing page em 2027: o que paga e porquê explica como se define o âmbito dessas páginas.

O que costuma correr mal no lançamento?

As mesmas falhas aparecem vezes sem conta, e quase todas são baratas de apanhar a tempo:

Formulários de contacto que enviam para uma caixa de testes, ou cujos emails caem no spam.
Uma definição “desencorajar motores de pesquisa” ou uma etiqueta noindex esquecida do site de testes.
Rastreadores a disparar antes do consentimento, porque uma etiqueta foi acrescentada fora da ferramenta de consentimento.
Endereços antigos sem redirecionamento, pelo que os links de outros sites e dos resultados de pesquisa acabam num 404.
Um menu ou uma janela que não fecha num telemóvel, ou uma página que não faz scroll.
Imagens carregadas no tamanho original da câmara, que tornam o primeiro ecrã lento com dados móveis.
Uma cache que continua a mostrar aos visitantes a folha de estilos antiga depois de uma alteração.

Cada uma destas falhas está na checklist acima. O objetivo de uma lista escrita é que ninguém precise de se lembrar delas sob pressão.

Perguntas frequentes

O que deve incluir uma checklist de QA de websites?

Uma checklist de QA de websites completa cobre conteúdos e textos, links e redirecionamentos, formulários e emails, browsers e dispositivos, desempenho e Core Web Vitals, acessibilidade, bases de SEO, privacidade e banner de cookies, segurança, análise de tráfego e cópias de segurança. Cada linha é marcada como aprovada ou falhada, e cada falha é registada com a página, o dispositivo, o browser e uma captura de ecrã.

Os testes de um website podem ser totalmente automatizados?

Não. A automatização é excelente para rastrear links, medir o desempenho, fazer capturas de ecrã em muitas larguras, validar e analisar a acessibilidade, e deve correr a cada alteração. Mas continua a ser precisa uma pessoa para avaliar se o texto se lê bem, se um percurso faz sentido e se quem usa um leitor de ecrã consegue mesmo preencher um formulário.

Quem deve fazer o QA de um novo website?

Idealmente, várias pessoas. O programador faz as verificações técnicas e automáticas, um tester ou designer verifica os dispositivos e a acessibilidade, e o cliente revê os conteúdos e faz o teste final de aceitação. Quem corrige uma falha não deve ser o único a confirmar que ficou corrigida: um segundo par de olhos apanha o que o primeiro deixou escapar.

O Ato Europeu de Acessibilidade aplica-se ao meu website?

Pode aplicar-se. O Ato Europeu de Acessibilidade aplica-se desde 28 de junho de 2025 a certos produtos e serviços oferecidos a consumidores na UE, incluindo o comércio eletrónico, e as microempresas que prestam serviços estão isentas. Se abrange o seu site depende do que vende e a quem, por isso consulte a diretiva ou peça a opinião de um consultor jurídico.

Qual é a diferença entre QA e testes de aceitação pelo utilizador?

O QA é a verificação técnica e de qualidade completa feita por quem construiu o site, segundo uma checklist escrita. Os testes de aceitação pelo utilizador vêm no fim: o cliente percorre os percursos reais e confirma que o site faz o que foi acordado. O QA encontra as falhas; os testes de aceitação confirmam que o site terminado é o que pediu.

Devo voltar a testar depois do lançamento?

Sim. Repita as verificações críticas no endereço definitivo na primeira hora, porque servidores, caches e certificados diferem do site de testes. Depois, acompanhe os registos de erros, o registo de 404, a entrega dos formulários e a Search Console durante a primeira semana, e mantenha uma verificação regular mais leve depois de cada atualização de plugins, temas ou conteúdos.

Se o seu site está perto do lançamento e quer que seja testado como deve ser, ou se está a planear um novo site e quer o QA integrado no trabalho desde o primeiro design, a nossa equipa de criação de websites pode ajudar: fale connosco sobre o seu projeto e vemos o que o seu lançamento precisa.

Checklist de QA de websites: como testar um website antes do lançamento