Teste visual de migração: processo de verificação sistemática da integridade visual de um site antes e depois de uma migração (mudança de CMS, de framework, de design ou de infraestrutura), que consiste em capturar uma referência visual completa do site antigo e compará-la automaticamente com o novo para detectar qualquer regressão não intencional.
Cada migração de site é uma aposta. Você sabe disso se já viveu uma. Seja uma mudança de CMS, uma transição para um novo framework front-end ou um redesign completo, o momento em que você troca do antigo para o novo é o momento em que os problemas aparecem. E esses problemas não são apenas visuais — bugs de interface que degradam a experiência do usuário podem até impactar o posicionamento SEO através do CLS.
E esses problemas não são os que você espera. Não é a página inicial que quebra — essa todo mundo verifica. É a página de termos de uso enterrada a três níveis de navegação cujo formato desmoronou. É o widget de newsletter cujo botão ficou invisível porque a cor de fundo mudou. É a margem de 24 pixels entre seções que caiu para 0 no mobile porque um reset CSS do novo framework sobrescreveu os estilos antigos.
Segundo uma análise da Semrush, uma migração de site mal executada pode provocar uma queda de 10 a 30% no tráfego orgânico nas semanas seguintes — e parte dessa queda vem diretamente de problemas de interface que degradam a experiência do usuário e aumentam a taxa de rejeição.
O teste visual é o único método confiável para sistematizar a verificação antes/depois de uma migração. E, no entanto, a maioria das equipes ainda o dispensa.
Por que as migrações são o momento de risco máximo
Uma migração não é um deploy clássico. Em um deploy clássico, você modifica uma parte do sistema e o resto permanece no lugar. Em uma migração, tudo se move ao mesmo tempo — ou quase. E é esse "quase" que é perigoso.
O volume de mudanças é ingerenciável manualmente
Tome uma migração de CMS: de WordPress para um headless CMS como Strapi ou Contentful, por exemplo. O conteúdo é migrado, os templates são reescritos, o sistema de rotas muda, os plugins WordPress desaparecem e são substituídos por código customizado ou integrações de terceiros. Cada página do site está potencialmente afetada.
Se o seu site tem 50 páginas, verificar manualmente cada uma no desktop e no mobile leva dias. Se o seu site tem 500 — o que é comum para um site e-commerce ou um site corporativo multilíngue — a verificação manual completa é simplesmente impossível dentro de um cronograma de projeto realista.
O resultado: as equipes verificam as 10 páginas principais e esperam que o resto se mantenha. É uma estratégia baseada na esperança, não no rigor.
As regressões são sutis
Os bugs visuais pós-migração não são erros 500 ou páginas em branco. São degradações sutis que ninguém percebe até que um usuário — ou pior, um cliente — reporte.
Um espaçamento que passa de 16 pixels para 12 pixels. Uma fonte que passa de peso 400 (regular) para 300 (light). Um gradiente CSS que não renderiza mais porque a sintaxe mudou ligeiramente entre o framework antigo e o novo. Um border-radius que desaparece nos cards de produto. Uma sombra que se dissipa porque a propriedade CSS foi sobrescrita por um reset mais agressivo.
Individualmente, cada uma dessas regressões é menor. Coletivamente, dão a impressão de que o site "perdeu qualidade" sem que ninguém consiga apontar um problema específico. É a morte por mil cortes da percepção de qualidade — e uma forma silenciosa de divida técnica visual.
Os testes funcionais não cobrem o visual
Sua suíte de testes funcionais verifica que o botão "Adicionar ao Carrinho" funciona, que o formulário de contato envia, que o redirecionamento 301 funciona corretamente. É necessário. Mas nenhum teste funcional verifica que o botão "Adicionar ao Carrinho" ainda é verde com um border-radius de 8 pixels e uma margem de 16 pixels abaixo do preço.
Os testes funcionais respondem à pergunta "funciona?". O teste visual responde à pergunta "parece com o que deveria?". Durante uma migração, ambas as perguntas são críticas.
Os tipos de migração e seus riscos visuais específicos
Nem todas as migrações criam os mesmos riscos. Aqui estão os cenários mais comuns e as regressões visuais típicas associadas.
O redesign: o risco mais elevado
O redesign é de longe a migração mais arriscada visualmente. Também é a mais comum: segundo uma pesquisa da HubSpot, as empresas redesenham seus sites em média a cada dois ou três anos.
Em um redesign, tudo deve mudar — esse é o objetivo. Mas "tudo muda" não significa "nada precisa ser verificado". O briefing criativo diz "novo header, novo footer, nova paleta de cores". Não diz "o texto dos termos e condições pode perder sua formatação" ou "os artigos antigos do blog podem ter imagens que não se exibem mais corretamente no novo layout".
As regressões típicas de um redesign incluem conteúdo antigo que não se adapta ao novo layout (textos muito longos, imagens na proporção errada), componentes secundários esquecidos no redesign (páginas de erro, emails transacionais, popups, modais), estados interativos que mudam de forma inconsistente (hover, focus, active em botões e links), e breakpoints responsivos que não correspondem mais aos mesmos viewports.
Migração de CMS
Passar de WordPress para Contentful, de Drupal para Strapi, de Magento para Shopify — cada migração de CMS implica reescrever os templates que produzem o HTML e o CSS. O conteúdo permanece teoricamente idêntico, mas o renderizado visual pode mudar de forma inesperada.
Os riscos específicos da migração de CMS são conteúdo rico (WYSIWYG) que perde sua formatação durante a transferência, shortcodes ou widgets específicos do CMS que não são migrados, imagens que mudam de dimensões ou qualidade de compressão, e URLs de recursos (CSS, imagens, fontes) que quebram no novo sistema.
Migração de framework front-end
Passar de jQuery para React, de AngularJS para Vue, de React class components para Next.js App Router — essas migrações mudam fundamentalmente a forma como o HTML é gerado e o CSS é aplicado.
O risco principal é a diferença de renderizado entre o framework antigo e o novo, mesmo com o "mesmo" CSS. Cada framework tem seus próprios mecanismos de scoping CSS, gerenciamento de animações e renderizado condicional. O CSS-in-JS do framework antigo não produz necessariamente o mesmo resultado que os CSS Modules do novo.
Migração de infraestrutura
Mudar de provedor de hosting, passar de um servidor dedicado para um CDN, migrar de AWS para GCP — essas mudanças teoricamente não deveriam alterar nada no renderizado visual. Em teoria.
Na prática, as diferenças de configuração do servidor (compressão de imagens, headers de cache, versões de Node.js para SSR) podem produzir diferenças visuais sutis. Um servidor que comprime imagens JPEG a 80% em vez de 85% produz imagens ligeiramente diferentes. Um renderizado SSR em uma versão diferente de Node.js pode gerar HTML ligeiramente diferente se o código usa funcionalidades dependentes da versão.
O método: teste visual antes/depois da migração
O princípio é simples e poderoso: capturar uma fotografia visual completa do site antigo, depois comparar sistematicamente com o novo. Cada diferença é detectada, analisada e classificada como intencional ou regressão.
Etapa 1: capturar a baseline no site antigo
Antes de tocar em qualquer coisa, capture o estado visual completo do seu site atual. É a sua baseline — sua verdade de referência.
Quais páginas capturar? Idealmente, todas. Na prática, priorize em função do tráfego e da importância de negócio. Comece pelas páginas que geram tráfego orgânico significativo (consulte o Google Analytics 4 ou Search Console), as páginas de conversão (cadastro, compra, solicitação de orçamento), a página inicial e as páginas de navegação principal, e os templates únicos (cada tipo de página: artigo, produto, categoria, landing page).
Em quais viewports? No mínimo desktop (1440px ou 1920px) e mobile (375px ou 393px). Se o seu público em tablet for significativo, adicione um viewport intermediário (768px ou 1024px).
Quando capturar? O mais tarde possível antes da migração, para que a baseline reflita o estado mais recente do site. Mas não no dia da virada — você precisa de tempo para verificar que as capturas estão completas e corretas.
Essa baseline é sua rede de segurança. Trate-a com a mesma seriedade que um backup de banco de dados antes da migração.
Etapa 2: preparar a comparação
Antes de comparar, identifique as mudanças intencionais. Se você está fazendo um redesign, o novo header será diferente do antigo — esse é o objetivo. Documente essas mudanças esperadas para poder distingui-las das regressões durante a comparação.
Crie uma lista das zonas que vão mudar intencionalmente e configure sua ferramenta de teste visual para tratá-las separadamente. O objetivo é concentrar sua atenção nas diferenças não intencionais — as verdadeiras regressões.
Etapa 3: capturar o novo site e comparar
Uma vez que o novo site esteja implantado (em ambiente de staging, não em produção), capture as mesmas páginas nos mesmos viewports e execute a comparação com a baseline.
Cada diferença detectada se enquadra em uma destas categorias.
Mudança intencional: o novo design é diferente, é esperado. Você valida e atualiza a baseline.
Regressão: algo mudou que não deveria. Você cria um ticket e corrige antes de ir para produção.
Zona cinza: uma mudança sutil da qual você não tem certeza se é intencional ou acidental. Você consulta o designer ou o gerente de projeto para esclarecer.
Etapa 4: iterar antes de ir para produção
A primeira comparação vai revelar dezenas, até centenas de diferenças. É normal. O trabalho consiste em classificá-las, corrigir as regressões e relançar a comparação até que as únicas diferenças restantes sejam intencionais.
Esse processo iterativo é exatamente o que o teste visual automatizado viabiliza. Fazer essa classificação manualmente em 100 páginas seria exaustivo e sujeito a erros. Com uma ferramenta que destaca as diferenças e permite validá-las ou rejeitá-las uma por uma, é metódico e confiável.
Etapa 5: monitoramento pós-migração
A migração não termina no dia da virada. Nos dias e semanas que seguem, problemas adicionais podem surgir — um cache que se limpa e revela um problema oculto, conteúdo antigo que passa por um caminho de renderização não testado, uma interação entre o novo código e uma extensão de navegador popular.
Mantenha um monitoramento visual regular por pelo menos duas semanas após a migração. A nova baseline é o novo site validado, e qualquer desvio em relação a essa baseline é um alerta.
O que a Delta-QA traz em um contexto de migração
A Delta-QA é particularmente adequada para migrações por várias razões estruturais.
A captura de baseline sem código. Você não precisa configurar um pipeline CI/CD para capturar o site antigo. Você abre a Delta-QA, navega pelo seu site, e a ferramenta captura cada página. É uma operação que qualquer membro da equipe pode fazer — o gerente de projeto, o testador, o designer.
A comparação estrutural. O algoritmo de 5 passes da Delta-QA não compara imagens. Ele compara as propriedades CSS calculadas — dimensões, cores, fontes, espaçamentos, posições. Quando ele diz "a margem entre a seção Hero e a seção Funcionalidades passou de 64px para 48px", você sabe exatamente o que verificar e corrigir.
Essa abordagem elimina o ruído de falsos positivos por diferenças de renderização que afetam ferramentas pixel diff durante migrações. Uma mudança de framework pode modificar ligeiramente o anti-aliasing das fontes sem alterar as propriedades CSS — uma ferramenta pixel diff sinalizaria uma mudança em cada texto de cada página. A Delta-QA ignorará essas diferenças cosméticas e se concentrará nas verdadeiras mudanças estruturais.
Zero infraestrutura. Em um contexto de migração, a equipe já está sobrecarregada. Adicionar uma ferramenta que requer um pipeline, uma conta cloud, integração SDK e manutenção é adicionar complexidade no pior momento. A Delta-QA se instala em minutos e funciona imediatamente, localmente, sem dependências externas.
Os erros clássicos a evitar ao testar uma migração
A experiência mostra que certos erros se repetem sistematicamente. Conhecê-los permite evitá-los.
Não capturar a baseline a tempo. Se você captura a baseline depois de começar a migração, já não tem uma referência confiável do site antigo. Capture antes de qualquer modificação e guarde essas capturas com cuidado.
Testar apenas em um ambiente. O site em staging pode se comportar de forma diferente do site em produção — URLs diferentes, dados diferentes, configuração de servidor diferente. Idealmente, teste tanto em staging quanto em produção (após a virada) e compare ambos com a baseline.
Ignorar páginas de baixo tráfego. A página "Sobre" com 50 visitas por mês não é prioridade de negócio. Mas se estiver visualmente quebrada, é um sinal de qualidade negativo para cada visitante que a consulta — incluindo prospects avaliando sua credibilidade. Páginas de baixo tráfego são frequentemente as primeiras esquecidas e as últimas corrigidas.
Esquecer os estados autenticados. Muitos sites têm uma experiência diferente para usuários logados e deslogados. Se você só testa o estado deslogado, perde as regressões do dashboard, perfil, configurações — páginas que seus clientes existentes usam diariamente.
Confiar apenas no feedback dos usuários. "Vamos ver se os usuários reportam problemas" não é uma estratégia de QA. Os usuários não reportam problemas visuais sutis — eles vão embora silenciosamente. Você só verá a consequência nas métricas de taxa de rejeição e conversão, semanas depois, quando for tarde demais para isolar a causa.
Checklist de teste visual para uma migração
Aqui está uma checklist que você pode seguir para estruturar sua abordagem de teste visual na próxima migração.
Antes da migração:
- Listar todas as páginas e templates únicos do site
- Capturar as baselines em desktop e mobile para cada página
- Verificar que as capturas estão completas e corretas
- Documentar as mudanças intencionais esperadas
- Identificar as zonas dinâmicas a excluir da comparação (datas, contadores, conteúdo personalizado)
Durante a migração (staging):
- Capturar as mesmas páginas no novo site em staging
- Comparar com as baselines e classificar as diferenças
- Corrigir as regressões identificadas
- Relançar a comparação após correções
- Iterar até que apenas as mudanças intencionais permaneçam
Após a migração (produção):
- Capturar o site em produção nas horas seguintes à virada
- Comparar com as baselines validadas em staging
- Verificar as páginas de baixo tráfego frequentemente esquecidas
- Monitorar visualmente durante duas semanas
- Atualizar as baselines definitivas para a vigilância contínua
FAQ
Quanto tempo antes da migração deve-se capturar a baseline?
Idealmente, capture a baseline uma a duas semanas antes da data prevista de migração. Isso lhe dá tempo para verificar que as capturas estão completas e resolver eventuais problemas de captura (páginas que exigem autenticação, conteúdo dinâmico a estabilizar). Se seu site evolui frequentemente, recapture a baseline alguns dias antes da virada para ter a referência mais fresca possível.
Como lidar com mudanças intencionais durante a comparação antes/depois?
Documente as mudanças esperadas antes de lançar a comparação. Quando analisar os resultados, trate primeiro as diferenças inesperadas — são suas regressões prioritárias. As mudanças intencionais podem ser validadas em lote e servir para atualizar a baseline. Algumas ferramentas como a Delta-QA permitem excluir zonas específicas da comparação para ignorar os elementos que mudam voluntariamente.
O teste visual é suficiente para validar uma migração?
Não. O teste visual cobre a integridade da interface — o que o usuário vê. Mas uma migração também envolve a verificação de redirecionamentos 301, do SEO técnico (robots.txt, sitemap, tags canonical, dados estruturados), das funcionalidades da aplicação (formulários, pagamento, autenticação) e do desempenho. O teste visual é um pilar da validação, não a validação completa.
Qual é a diferença entre uma ferramenta pixel diff e uma ferramenta estrutural para testar uma migração?
Uma ferramenta pixel diff sobrepõe duas capturas de tela e sinaliza os pixels diferentes. É sensível ao renderizado de fontes, ao anti-aliasing e às micro-variações — o que gera muitos falsos positivos durante uma migração onde o motor de renderização muda. Uma ferramenta estrutural como a Delta-QA compara as propriedades CSS calculadas (dimensões, cores, posições). Ela detecta as verdadeiras mudanças de layout e estilo sem ser poluída pelas diferenças de renderizado cosméticas.
Como testar páginas que exigem autenticação?
Conecte-se à sua aplicação antes de capturar as baselines, depois permaneça conectado durante toda a sessão de captura. Com uma ferramenta desktop como a Delta-QA, você navega na sua aplicação normalmente — a autenticação funciona exatamente como para um usuário real. Capture as páginas autenticadas como uma jornada: login, navegação até o dashboard, perfil, configurações.
Quantas páginas devem ser testadas durante uma migração?
Idealmente, todas as páginas com um template único. Um site com 500 páginas mas 15 templates diferentes pode ser coberto eficientemente testando uma amostra representativa de cada template — no mínimo a página mais visitada de cada tipo. Para sites e-commerce, adicione páginas de produto com características variadas (títulos longos/curtos, com/sem imagens, com/sem promoções) para cobrir os casos limite do template.
Conclusão
Uma migração é um investimento importante para sua empresa — em tempo, orçamento e risco. Não verificar sistematicamente o resultado visual desse investimento é uma escolha que nada justifica quando as ferramentas existem para fazê-lo de forma eficiente.
O teste visual antes/depois da migração transforma um processo baseado na esperança ("deve estar bom") em um processo baseado em evidências ("aqui está exatamente o que mudou, aqui está o que está validado, aqui está o que precisa ser corrigido").
Sua próxima migração merece melhor do que verificações manuais parciais e preces silenciosas.
Experimente a Delta-QA Gratuitamente →