Regressão visual: modificação não intencional da aparência de uma interface de usuário (layout, cores, tipografia, espaçamento, alinhamento) introduzida por uma mudança de código, uma atualização de dependência ou uma alteração de configuração, e detectável apenas pela comparação visual entre dois estados da interface.
Eis uma verdade que muitas equipes que usam Cypress preferem ignorar: sua suíte de testes Cypress, por mais completa que seja, é estruturalmente cega a toda uma categoria de bugs. As regressões visuais passam pelas suas asserções como água por uma peneira, não porque seus testes estejam mal escritos, mas porque o Cypress simplesmente não foi projetado para detectá-las.
Isso não é uma crítica ao Cypress. É uma constatação. E a diferença entre uma constatação e uma crítica é que a constatação pede uma solução, não um debate.
Todos os nossos comparativos, com critérios verificáveis: Alternativas e comparativos.
Sua suíte Cypress confirma que tudo funciona, não que tudo aparece direito. Complemente-a com o Delta-QA: seus percursos gravados sem código, uma conta gratuita e sem cartão de crédito. Testar o Delta-QA grátis →
Cypress: excelente no que faz, ausente onde o visual importa
O Cypress revolucionou o teste de front-end quando chegou ao mercado. A execução no navegador, o recarregamento automático, o time-travel debugging, a API intuitiva (tudo isso tornou o teste end-to-end acessível a equipes que viam o Selenium como um instrumento de tortura medieval). E no campo do teste funcional, o Cypress continua sendo uma ferramenta notável.
Mas faça a si mesmo esta pergunta: quando foi a última vez que você escreveu um teste Cypress que verifica se a sua página inicial está com a aparência correta? Não que um botão exista. Não que um texto esteja presente. Que ela esteja com a aparência correta: que os espaçamentos estejam certos, que as cores sejam coerentes, que o layout não tenha se movido nem um pixel.
A resposta, para a imensa maioria das equipes, é "nunca". E não é por descuido. É porque o Cypress não compara imagens. A própria documentação diz isso em 10/2026: o comando cy.screenshot() captura uma imagem, mas não a compara; o teste visual passa por plugins ou serviços de terceiros.
O ponto cego do Cypress: nenhuma comparação visual nativa
Quando você escreve cy.get('.button').should('be.visible'), está verificando que o elemento existe no DOM e não está escondido por CSS. Não está verificando se ele tem a cor certa. Não está verificando se está no lugar certo. Não está verificando se o texto está legível. Não está verificando se ele não se sobrepõe a outro elemento.
Um botão pode ser "visível" no sentido do Cypress (presente no DOM, display diferente de none, opacity maior que 0) e estar completamente inutilizável visualmente. Texto branco sobre fundo branco. Tamanho de 2 pixels por 2 pixels. Posicionado a 3000 pixels à direita da tela. O Cypress dirá que está tudo bem. Seu usuário dirá outra coisa.
É um ponto cego fundamental, não uma limitação menor. Uma parte importante dos problemas relatados pelos usuários envolve a exibição: um botão ilegível, um formulário deslocado, um bloco que transborda. E o Cypress, em sua configuração nativa, não detecta nenhum deles.
Os plugins visuais do Cypress: uma solução parcial e frágil
Diante dessa lacuna, o ecossistema Cypress produziu plugins de teste visual. Os mais conhecidos se apoiam em serviços de terceiros (Percy, Applitools, Happo) para capturar screenshots e compará-los, ou no cypress-image-snapshot para uma comparação local. Se você procura o detalhe de cada opção, nosso guia completo para adicionar teste visual ao Cypress analisa essas abordagens e seus limites reais. É um caminho que funciona, mas com restrições significativas.
A dependência de um serviço de terceiros. Todo plugin visual para Cypress depende de uma plataforma externa. Seus screenshots são enviados aos servidores de um fornecedor, comparados lá, e os resultados voltam para você. Isso adiciona latência ao seu pipeline de CI, uma dependência de rede e um custo de licença do serviço de terceiros, além do custo do Cypress Cloud se você o utiliza.
A complexidade de configuração. Adicionar um plugin visual ao Cypress exige instalar um pacote npm, configurar a autenticação com o serviço de terceiros, modificar seus testes existentes para incluir chamadas de captura, gerenciar tokens de API e treinar sua equipe na plataforma externa. Não é intransponível, mas também não é a experiência de "funciona em 5 minutos" que as páginas de marketing prometem.
A manutenção dupla. Você acaba mantendo dois sistemas: seus testes Cypress e a configuração do plugin visual. Quando o Cypress é atualizado, o plugin pode quebrar. Quando o serviço de terceiros muda sua API, seus testes podem falhar. Quando sua equipe muda, é preciso treinar os novatos em duas ferramentas em vez de uma.
A cobertura limitada. Um plugin visual integrado ao Cypress captura screenshots durante a execução dos seus testes funcionais. Isso significa que a cobertura visual depende da cobertura funcional. Se você não tem um teste Cypress para a página "Termos e Condições de Venda", também não tem teste visual para essa página. Sua cobertura visual é limitada pela sua cobertura funcional, e as duas não têm nenhuma razão para coincidir.
Delta-QA: o teste visual como disciplina autônoma
O Delta-QA parte de uma filosofia diferente. O teste visual não é uma funcionalidade enxertada em uma ferramenta de teste funcional. É uma disciplina por si só, com suas próprias exigências, seus próprios fluxos e seus próprios usuários.
A independência em relação aos testes funcionais. O Delta-QA grava seus percursos enquanto você navega. Você não precisa de um teste funcional como veículo para capturar uma página. Sua cobertura visual não depende da sua cobertura funcional: você pode verificar dezenas de páginas sem escrever um único teste.
A acessibilidade para não desenvolvedores. Quem são as pessoas mais competentes para julgar a qualidade visual de uma interface? Os designers. Os QAs manuais. Os product owners. E essas pessoas, na maioria das organizações, não sabem escrever JavaScript. Com Cypress + plugin visual, elas dependem de um desenvolvedor para configurar, executar e interpretar os testes. Com o Delta-QA, são autônomas. É uma diferença que muda a dinâmica de uma equipe.
A gestão nativa das referências. O Delta-QA integra um fluxo completo: relatório que compara a página como faria o olho humano, julgamento de cada diferença (intencional ou bug), histórico das modificações. Esse fluxo foi pensado para equipes multidisciplinares, não para um desenvolvedor solo que faz push e merge na mesma manhã.
O navegador. O Delta-QA reproduz seus percursos em um navegador de verdade, hoje o Chromium; Firefox e WebKit estão previstos. No Cypress, Chrome, Edge e Firefox são suportados, e o WebKit continua experimental.
O problema estrutural dos plugins: a lei da cobertura acoplada
Vamos retomar esse ponto, porque ele merece ser desenvolvido. Quando seu teste visual está acoplado ao seu teste funcional (como é o caso dos plugins visuais do Cypress), sua cobertura visual herda todas as limitações da sua cobertura funcional.
Você tem um teste Cypress para o funil de compra? A cobertura visual do funil de compra está garantida. Não tem teste Cypress para a página de FAQ? Sem cobertura visual da página de FAQ. Seu teste Cypress para a página de perfil cobre o caso "usuário logado com assinatura premium"? Você tem cobertura visual para esse caso, mas não para "usuário logado sem assinatura" nem para "usuário cuja assinatura expirou".
A cobertura funcional e a cobertura visual têm lógicas diferentes. No funcional, você testa percursos: sequências de ações e verificações. No visual, você testa estados: snapshots de páginas em condições dadas. Um percurso funcional de 10 etapas pode precisar de apenas 2 verificações visuais (página de entrada e página de confirmação). Inversamente, uma página simples sem lógica funcional complexa (uma página "Sobre") pode exigir uma verificação visual em 5 resoluções e 3 navegadores.
Acoplar as duas é forçar uma disciplina a adotar a cobertura da outra. É como dizer que você só vai inspecionar visualmente uma sala da fábrica quando um operário entrar nela para usar uma máquina. Nos dias em que ninguém trabalha nessa sala, os vazamentos de água passam despercebidos.
O Cypress faz isso melhor: o teste funcional
Reconheçamos os pontos fortes do Cypress, porque são reais e significativos.
A experiência do desenvolvedor. O Cypress foi concebido por desenvolvedores para desenvolvedores. A interface de depuração com time-travel, a rapidez de execução, a API encadeada fluida (é um prazer de usar). O Delta-QA não pretende oferecer essa experiência porque esse não é o seu terreno.
A verificação da lógica de negócio. Um funil de pagamento que calcula corretamente impostos, frete e códigos promocionais: quem verifica isso é o Cypress. Não o Delta-QA. A lógica de negócio é invisível visualmente até produzir um resultado exibido, e mesmo assim, verificar que "o valor exibido está correto" exige conhecer o valor esperado, algo que só um teste funcional pode calcular.
A interceptação de rede. O Cypress pode interceptar requisições HTTP, simular respostas do servidor, testar casos de erro. É uma poderosa ferramenta de teste de integração front-end que vai muito além da simples verificação de interface.
Um ecossistema Cloud que se amplia. Em 10/2026, o Cypress Cloud oferece Test Replay para reproduzir uma falha, UI Coverage, Cypress Accessibility, resumos de falhas gerados por IA, e o comando cy.prompt() transforma etapas escritas em linguagem natural em comandos Cypress. Nada disso compara a aparência de uma página com uma referência, mas a ferramenta evolui rápido.
A velocidade de execução. A arquitetura do Cypress, que executa os testes no mesmo processo da aplicação, oferece uma velocidade de execução notável para testes funcionais. Sem latência de rede entre o teste e a aplicação, sem protocolo WebDriver intermediário.
Sua suíte Cypress valida a lógica, não a aparência. Preencha essa lacuna com o Delta-QA: teste visual no-code, conta gratuita e sem cartão de crédito. Testar o Delta-QA grátis →
O Delta-QA faz isso melhor: o teste visual
A cobertura rápida. Cobrir visualmente suas páginas principais leva o tempo de percorrê-las no Delta-QA. Obter a mesma cobertura com um plugin Cypress exigiria escrever um teste para cada página, gerenciar as baselines e estabilizar as capturas. Dias de trabalho de um lado, algumas horas de navegação do outro.
O fluxo de aprovação. Quando o Delta-QA detecta uma mudança, seu designer pode julgá-la diretamente na interface. Sem passar por um desenvolvedor, sem precisar entender o relatório do Cypress. O relatório fala a linguagem de quem avalia a qualidade visual: qual elemento mudou e como.
A redução de falsos positivos. Os plugins visuais para Cypress costumam herdar as limitações da comparação bruta pixel a pixel. Um anti-aliasing de fonte diferente entre duas execuções? Falso positivo. Um cursor de texto que aparece em um campo? Falso positivo. O Delta-QA compara os elementos da página em vez de seus pixels: uma variação de renderização que não muda nem a cor, nem o tamanho, nem a posição de um elemento não é sinalizada.
O histórico visual. O Delta-QA conserva o histórico das referências e das mudanças avaliadas. Você pode rastrear a evolução de uma página ao longo das versões. Com um plugin Cypress local, suas baselines são arquivos no Git (versionados, mas sem interface para visualizar sua evolução).
O cenário típico: quando o plugin Cypress não basta mais
Imagine um cenário comum. Sua equipe usa Cypress há dois anos. Você tem 300 testes funcionais. Sua cobertura é boa. Então, um dia, uma refatoração de CSS atinge o seu design system. A variável --color-primary muda. Todos os testes Cypress passam, nenhum deles verifica cores. Em produção, 30 páginas têm um botão de ação cujo contraste ficou insuficiente para ser legível. O suporte recebe 15 tickets em duas horas. A correção é implantada às pressas.
Depois desse incidente, seu líder técnico decide adicionar um plugin visual ao Cypress. A instalação leva meio dia. A configuração de baselines para 50 páginas críticas leva um dia. As primeiras execuções geram 47 falsos positivos. A triagem dos falsos positivos leva um dia. Duas semanas depois, um desenvolvedor atualiza o Cypress e o plugin deixa de ser compatível. A suíte visual é desativada "temporariamente". Três meses depois, continua desativada.
Esse cenário não é inventado: é o relato composto de dezenas de conversas com equipes de QA. O problema fundamental não é o plugin. É que o teste visual enxertado em uma ferramenta de teste funcional nunca é prioridade. É sempre "aquela coisa a mais" que se faz quando há tempo: ou seja, nunca.
O Delta-QA evita essa armadilha porque o teste visual é a razão de ser da ferramenta, não um acréscimo opcional. Não há suíte funcional que tome a prioridade. Não há configuração mais urgente para manter. O teste visual é a prioridade, e a ferramenta é construída em torno dessa prioridade.
A combinação vencedora: Cypress + Delta-QA
A posição que defendemos não é "abandone o Cypress pelo Delta-QA". Isso seria absurdo. O Cypress é uma excelente ferramenta de teste funcional. O Delta-QA foi concebido para a não regressão de interface. A combinação dos dois entrega uma cobertura de QA que nenhum dos dois consegue oferecer sozinho.
O Cypress verifica se a sua aplicação funciona. Os percursos do usuário, a lógica de negócio, as integrações de API, os casos de erro. É a camada funcional da sua garantia de qualidade.
O Delta-QA verifica se a sua aplicação tem a aparência correta. As cores, a tipografia, os espaçamentos, o layout. É a camada visual da sua garantia de qualidade.
Cada camada tem seu ritmo. Os testes Cypress rodam no seu pipeline de CI/CD; os cenários do Delta-QA são reproduzidos a cada versão. Cada uma olha para uma dimensão diferente da qualidade, com ferramentas otimizadas para essa dimensão.
É como ter ao mesmo tempo um sistema de alarme e câmeras de vigilância. O alarme detecta intrusões (funcional: alguém entrou e não deveria). As câmeras mostram o que está acontecendo (visual: tudo parece normal?). Os dois juntos são mais eficazes do que cada um separado.
O argumento do "já temos Cypress, basta"
Essa é a objeção mais frequente. "Já investimos no Cypress, não vamos adicionar outra ferramenta." É um argumento compreensível, mas falacioso. Você já tem um martelo, mas isso não transforma todo problema em prego.
Se a sua aplicação tem uma interface de usuário (e se você está lendo este artigo, provavelmente tem), uma parte significativa do valor percebido pelos seus usuários vem da aparência dessa interface. Não da lógica de negócio subjacente, por mais brilhante que seja. Um usuário não vê a sua arquitetura de microsserviços. Ele vê um botão azul, um formulário alinhado, uma tipografia coerente.
Não testar essa dimensão é apostar que ninguém jamais quebrará o CSS da sua aplicação. É uma aposta que você vai perder. A questão não é se, mas quando. E quando acontecer, o custo será proporcional ao tempo que a regressão passa em produção: um tempo que se reduz detectando-a antes da implantação.
Quanto tempo leva para adicionar o Delta-QA a um setup Cypress existente
Se você já usa Cypress e quer adicionar o Delta-QA, veja o que isso implica na prática.
O Delta-QA funciona independentemente do Cypress. Você não precisa modificar seus testes Cypress existentes. Não precisa instalar um plugin. Não precisa mexer na configuração do Cypress. As duas ferramentas coexistem sem conflito porque não compartilham nada.
A implantação do Delta-QA consiste em abrir o seu site e percorrer os cenários a cobrir. A primeira passagem estabelece as referências. Só isso: a cobertura visual está ativa, independentemente dos seus testes Cypress.
Para ir mais longe na CI, o Delta-QA agora tem um SDK, o Vision. Hoje ele cobre o Playwright, em TypeScript e JavaScript; o suporte ao Cypress está previsto na sequência. Com o Playwright, basta uma linha por página a verificar: uma diferença não avaliada faz o teste falhar, e o log da CI traz o link do relatório.
FAQ
O Cypress vai adicionar teste visual nativo algum dia?
É uma pergunta recorrente na comunidade Cypress. Em 10/2026, a documentação indica que o Cypress não compara imagens por conta própria e encaminha para plugins. O Cypress Cloud ganha recursos (Test Replay, UI Coverage, Accessibility, funções de IA como cy.prompt()), mas sem comparação visual com uma referência. E mesmo que o Cypress a adicionasse, ela continuaria acoplada à execução dos testes funcionais: o que manteria o problema de cobertura acoplada descrito acima.
Os plugins visuais do Cypress não são suficientes? Para um uso básico, podem quebrar o galho. Mas eles adicionam uma dependência de um serviço de terceiros (com seu próprio custo de licença), acoplam a cobertura visual à cobertura funcional, e sua manutenção é uma carga adicional. Se você tem 10 páginas e um desenvolvedor disponível para manter o plugin, pode funcionar. Se tem 100 páginas e uma equipe de QA mista, as limitações se tornam bloqueantes.
O Delta-QA pode detectar bugs que o Cypress não detecta? Sim, por definição. O Cypress verifica asserções programáticas: "este elemento contém este texto", "esta URL está correta", "esta requisição retornou 200". O Delta-QA verifica a aparência visual: "esta página tem aparência idêntica à versão de referência". Os bugs visuais (regressões de CSS, problemas de responsividade, conflitos de z-index, fontes ausentes) são invisíveis às asserções do Cypress, mas detectados pelo Delta-QA.
O Delta-QA deixa o pipeline de CI/CD mais lento? Seus cenários Delta-QA gravados sem código não passam pelo seu pipeline Cypress: não o deixam mais lento. Para uma integração na CI, o SDK Vision cobre hoje o Playwright; o Cypress está previsto na sequência.
É preciso escolher entre o Cypress Cloud e o Delta-QA? Não. Os dois atendem a objetivos diferentes. O Cypress Cloud otimiza seus testes funcionais Cypress: paralelização, reprodução de falhas, detecção de testes flaky, cobertura de interface e acessibilidade. O Delta-QA cobre a comparação visual com uma referência, que o Cypress Cloud não aborda. Os dois são investimentos complementares.
Minha equipe de QA não é técnica. Eles podem usar o Delta-QA sem ajuda de um desenvolvedor? É precisamente o caso de uso para o qual o Delta-QA foi concebido. A interface no-code permite que um testador de QA, um designer ou um product owner configure, execute e interprete os testes visuais sem nenhuma habilidade de programação. É um dos diferenciais fundamentais em relação a um plugin Cypress, que exige modificar código JavaScript para adicionar pontos de captura visual.
É possível usar o Delta-QA com outro framework além do Cypress? Sim. Os cenários do Delta-QA são independentes de qualquer framework de teste: seja você usuário de Cypress, Playwright, Selenium, TestCafe ou de nenhum framework, eles funcionam da mesma forma. E para as equipes Playwright, o SDK Vision permite adicionar uma verificação do Delta-QA a um teste existente.
Conclusão: não deixe o Cypress carregar um fardo que não é dele
O Cypress é uma ferramenta notável no que faz. Mas pedir a ele que cubra o teste visual (via plugins, gambiarras ou asserções de CSS improvisadas) é impor uma missão para a qual ele não foi projetado. É como equipar um velocista com uma mochila de 20 quilos e se surpreender que ele seja menos rápido.
Libere o Cypress. Deixe-o fazer o que faz de melhor: testar se a sua aplicação funciona. E entregue o teste visual a uma ferramenta feita para isso.
Pronto para cobrir o ponto cego visual da sua suíte de testes? Rode sua primeira comparação com o Delta-QA, com uma conta gratuita e sem cartão de crédito. Testar o Delta-QA grátis →