Checklist de QA Visual: O Que Verificar Antes de Cada Lançamento

Lançar uma release sem QA visual é uma aposta. Os testes funcionais confirmam que as funcionalidades funcionam, mas não confirmam que a interface tem o aspeto correto. Um botão pode passar todos os testes de integração e ainda assim sobrepor-se a um campo de formulário no Safari mobile. Um cabeçalho pode renderizar perfeitamente em inglês e quebrar o seu contentor quando traduzido para alemão.

Este checklist abrange as verificações visuais que toda equipa web deve executar antes de um lançamento ir para produção. Utilize-o tal como está ou adapte-o ao seu stack e audiência específicos.

Por que um checklist visual é importante

Os bugs visuais são particularmente prejudiciais porque são imediatamente visíveis para os utilizadores. Um elemento desalinhado ou um layout quebrado corroem a confiança de formas que uma resposta lenta da API não consegue. No entanto, o QA visual é frequentemente a parte mais improvisada do processo de lançamento — feito de forma inconsistente, por pessoas diferentes, sem critérios partilhados.

Um checklist escrito resolve isto ao tornar o QA visual repetível e mensurável. Todos na equipa sabem o que significa "visualmente verificado", e nenhuma categoria de verificações é ignorada porque alguém se esqueceu.

Layout e espaçamento

Problemas de layout são as regressões visuais mais comuns. Verifique-os sistematicamente:

A estrutura da página está intacta — cabeçalho, conteúdo principal, barra lateral (se presente) e rodapé renderizam na ordem correta com o espaçamento esperado.
Layouts de grid e flexbox fazem wrap corretamente — verifique em larguras de desktop, tablet e mobile. Procure por quebras de coluna inesperadas ou elementos a transbordar dos seus contentores.
O espaçamento entre secções é consistente — margens e paddings correspondem à especificação do design. Atenção a secções demasiado próximas ou demasiado distantes.
Sem elementos sobrepostos — verifique que elementos com posição absoluta (tooltips, dropdowns, modais) não sobrepõem conteúdo nem se estendem para além do viewport.
Elementos sticky e fixed comportam-se corretamente — cabeçalhos sticky e rodapés fixed devem manter a posição durante o scroll sem cobrir o conteúdo atrás deles.

Para verificação automatizada de layout em diferentes breakpoints, consulte o nosso guia sobre fluxos de trabalho de testes cross-browser.

Tipografia e conteúdo

Problemas de renderização de texto são subtis mas afetam a legibilidade e o profissionalismo:

Os cabeçalhos seguem a hierarquia correta — os tamanhos e pesos de H1, H2, H3 correspondem ao design system.
O texto do corpo é legível — tamanho da fonte, altura da linha e contraste cumprem os padrões de acessibilidade. Teste com conteúdo real, não com texto placeholder.
Sem truncamento ou overflow de texto — cabeçalhos longos, strings traduzidas e conteúdo dinâmico cabem nos seus contentores. Verifique especialmente com locales mais longos, como o alemão.
Os links são visualmente distinguíveis — sublinhado, cor ou outro estilo torna os links identificáveis sem depender apenas da cor.
Blocos de código e texto pré-formatado renderizam corretamente — as fontes monospace carregam, o syntax highlighting funciona e o scroll horizontal aparece para linhas longas.
As listas renderizam com os marcadores corretos — listas ordenadas mostram números, listas não ordenadas mostram bullets e a indentação é visualmente clara.

Comportamento responsivo

Bugs responsivos representam uma proporção desproporcional dos problemas visuais reportados pelos utilizadores:

Layout mobile (375px de largura) — verifique a página completa na largura típica de mobile. A navegação colapsa para hamburger, as imagens escalam e o conteúdo empilha-se verticalmente.
Layout tablet (768px de largura) — é aqui que a maioria dos bugs responsivos se esconde. Layouts de duas colunas devem transicionar de forma limpa e os alvos de toque devem ter tamanho adequado.
Layout desktop (1440px de largura) — a experiência principal de desktop. Layouts multi-coluna exibem-se corretamente e as larguras máximas de conteúdo são respeitadas.
Desktop largo (1920px+ de largura) — o conteúdo não deve esticar para preencher ecrãs ultra-largos. Verifique que as larguras máximas e o centramento funcionam corretamente.
Mudanças de orientação — em mobile e tablet, alternar entre retrato e paisagem não deve quebrar o layout.
Comportamento de zoom — o zoom do navegador a 150% e 200% não deve causar sobreposição ou conteúdo oculto.

Renderização cross-browser

Diferentes motores de navegador interpretam CSS de forma diferente. Verifique pelo menos estas combinações:

Chrome desktop — a sua renderização de referência. A maioria dos utilizadores verá esta versão.
Firefox desktop — deteta problemas específicos do Gecko com flexbox gap, métricas de fonte e propriedades customizadas.
Safari desktop — o WebKit tem comportamento único para backdrop-filter, position-sticky e flex-wrap.
Safari mobile (iOS) — todos os navegadores iOS usam WebKit. O tratamento do viewport, safe-area insets e o comportamento de scroll diferem do desktop.
Chrome mobile (Android) — verifique alvos de toque, comportamento do viewport meta e estilos específicos de mobile.

Não precisa de verificar todos os navegadores para todas as páginas. Priorize com base nos dados de tráfego: cubra as combinações que representam 90% da sua audiência. Consulte o nosso guia de testes de regressão visual para mais informações sobre como construir uma matriz de navegadores.

Estados interativos

Elementos interativos têm múltiplos estados visuais. Cada um precisa de verificação:

Botões — os estados default, hover, focus, active, disabled e loading renderizam todos corretamente e são visualmente distintos.
Campos de formulário — estados vazio, focado, preenchido, erro e disabled. Verifique que as mensagens de erro aparecem na posição correta e não deslocam o layout.
Navegação — indicador de página ativa, efeitos hover nos links, menus dropdown a abrir e fechar na posição correta.
Modais e diálogos — abrem suavemente, centram-se corretamente em todos os tamanhos de ecrã e exibem um backdrop visível. O botão de fechar é acessível.
Tooltips e popovers — aparecem na posição correta relativamente ao seu gatilho. Não são cortados por contentores com overflow-hidden ou pela borda do viewport.
Estados de carregamento — skeleton screens, spinners e barras de progresso exibem-se corretamente durante a obtenção de dados.

Imagens e media

Media visual requer o seu próprio conjunto de verificações:

As imagens carregam e exibem-se — sem ícones de imagem quebrada. Todas as imagens têm texto alt apropriado para acessibilidade.
As imagens têm o tamanho correto — sem distorção ou corte inesperado. As proporções são mantidas.
Imagens responsivas servem tamanhos apropriados — dispositivos móveis não descarregam imagens de tamanho desktop.
Embeds de vídeo funcionam — os botões de reprodução exibem-se, as proporções estão corretas e os embeds não transbordam dos seus contentores.
Os ícones renderizam corretamente — ícones SVG exibem-se no tamanho e cor corretos. Fontes de ícones carregam sem mostrar caracteres de fallback.

Acessibilidade e cor

O QA visual e a acessibilidade sobrepõem-se significativamente:

O contraste de cor cumpre o WCAG AA — texto e elementos interativos têm contraste suficiente contra os seus fundos. Verifique tanto o tema claro como o escuro, se aplicável.
Os indicadores de foco são visíveis — a navegação por teclado deve mostrar um anel de foco claro em todos os elementos interativos.
O modo escuro renderiza corretamente — se a sua aplicação suporta modo escuro, verifique que todos os componentes, imagens e texto são legíveis em ambos os temas.
Nenhuma informação é transmitida apenas pela cor — estados de erro, indicadores de estado e campos obrigatórios utilizam ícones ou texto além da cor.

Verificações visuais relacionadas com desempenho

Problemas de desempenho podem manifestar-se como problemas visuais:

Sem deslocamento de layout durante o carregamento — o conteúdo não salta à medida que fontes, imagens ou scripts carregam. Isto é medido pelo Cumulative Layout Shift (CLS).
As web fonts carregam antes da pintura — sem flash de texto sem estilo (FOUT) ou texto invisível (FOIT) durante o carregamento da página.
O conteúdo above-the-fold renderiza rapidamente — a parte visível da página deve aparecer dentro de 1–2 segundos numa boa conexão.

Fluxo de trabalho de verificação pré-lançamento

Utilize este fluxo de trabalho para executar o checklist de forma consistente:

Implante em staging — verifique contra um ambiente que espelhe a produção o mais fielmente possível.
Execute testes de screenshot automatizados — capture baselines em toda a sua matriz de navegadores e dispositivos. Consulte o nosso guia de automação CI/CD para instruções de configuração.
Reveja as diffs automatizadas — classifique cada diff como intencional, regressão ou ruído.
Execute verificações manuais pontuais — os testes automatizados cobrem a renderização estática. Verifique manualmente estados interativos, animações e casos extremos.
Documente os resultados — registe quais verificações passaram, quais falharam e o que foi corrigido. Isto cria um registo de auditoria para futuros lançamentos.
Aprove ou bloqueie — se todas as verificações passarem, aprove o lançamento. Se bugs visuais críticos permanecerem, bloqueie até serem resolvidos.

Adaptar o checklist à sua equipa

Este checklist é abrangente por design. Para a sua equipa, personalize-o com base em:

O seu stack — se não suporta modo escuro, remova essas verificações. Se utiliza um design system, adicione verificações ao nível dos componentes.
A sua audiência — se 95% do seu tráfego vem do Chrome, reduza o âmbito cross-browser e aumente os testes mobile.
A sua tolerância ao risco — aplicações críticas para a receita precisam de verificações mais rigorosas. Ferramentas internas podem utilizar um processo mais leve.

O essencial é a consistência. Um checklist mais curto que é executado em cada lançamento é mais valioso do que um abrangente que é ignorado sob pressão de prazos.

Continue com o ScanU

Os testes de screenshot automatizados lidam com as partes mais demoradas deste checklist: verificação de layout, renderização cross-browser e verificações de breakpoints responsivos. O ScanU captura screenshots em diferentes navegadores e dispositivos para que a sua equipa possa concentrar-se nos estados interativos e casos extremos. Explore as opções de planos em Pricing, saiba mais sobre a plataforma em Features e veja respostas a perguntas comuns no FAQ.