Teste visual de componentes (component visual testing): método de verificação automatizada que consiste em renderizar componentes de interface de forma isolada (fora do contexto da página completa) e comparar sua aparência com um estado de referência validado, para detectar regressões visuais no nível do design system antes que elas se propaguem para as páginas em produção.
Há uma pergunta que as equipes de front-end evitam cuidadosamente fazer: "nossos componentes são testados visualmente no Storybook, mas nossas páginas em produção também são?". A resposta, na maioria dos casos, é não. E essa lacuna custa caro, porque os bugs visuais que chegam aos seus usuários não vivem no Storybook: vivem nas páginas reais, com dados reais, interações reais e combinações reais de componentes.
O Chromatic é uma excelente ferramenta para testar componentes isolados. O Delta-QA foi feito para testar páginas completas. Para uma introdução ao teste visual, consulte nosso guia de regressão visual. Eles não são concorrentes no sentido estrito: são ferramentas que olham para o mesmo problema de altitudes diferentes. Mas se você precisa escolher apenas uma, ou quer entender o que cada uma entrega, este comparativo vai direto ao ponto.
Todos os nossos comparativos, com critérios verificáveis: Alternativas e comparativos.
O Chromatic verifica componentes isolados; quem testa as suas páginas reais em produção? O Delta-QA cobre essas páginas sem escrever código, com uma conta gratuita e sem cartão de crédito. Testar o Delta-QA grátis →
Chromatic: o guardião do design system
O Chromatic, criado pelos mantenedores do Storybook, é a extensão natural do ecossistema Storybook para o teste visual. Para uma visão geral do teste visual aplicado a design systems, consulte nosso guia dedicado. O conceito é brilhante em sua lógica: você já definiu seus componentes no Storybook com seus diferentes estados (stories). O Chromatic captura um screenshot de cada story a cada commit, compara com a baseline e sinaliza as mudanças.
É um fluxo perfeitamente integrado para equipes que trabalham com design systems. Seu designer define um botão com quatro variantes (primary, secondary, disabled, loading). Seu desenvolvedor implementa essas variantes e cria as stories correspondentes. A cada mudança de código, o Chromatic verifica se as quatro variantes não regrediram visualmente. Se o border-radius do botão mudar por acidente, o Chromatic detecta antes que alguém faça o code review.
A ferramenta também oferece uma funcionalidade de revisão de UI (UI Review) que permite a designers e desenvolvedores validar visualmente as mudanças antes do merge. É essencialmente um code review visual, e é realmente útil para manter a coerência de um design system.
Em 10/2026, o Chromatic não se limita mais às stories: ele também executa testes de interação e de acessibilidade, se apoia em testes Playwright, Cypress ou Vitest existentes e renderiza as capturas em quatro navegadores (Chrome, Firefox, Safari, Edge). Ele também se apresenta como uma proteção para interfaces escritas por agentes de IA, com um servidor MCP documentado para dar a eles o contexto dos componentes validados.
O ponto cego do Chromatic: o mundo real
Eis o problema que o Chromatic não resolve (não por falta de qualidade, mas por escolha arquitetural): componentes isolados não se comportam como páginas montadas.
Um botão testado isoladamente no Storybook é renderizado em um ambiente controlado: viewport fixo, sem vizinhos, sem contexto CSS herdado, sem dados dinâmicos, sem interações com outros componentes. É exatamente isso que torna o teste confiável no nível do componente. Mas é também o que o deixa cego aos problemas de montagem.
O que quebra visualmente em produção? Raramente um componente isolado. O que quebra é a combinação. Um componente de header que se sobrepõe a um componente de navegação porque um z-index mudou. Uma grade de produtos que se desalinha porque um componente de card recebeu um margin adicional. Um formulário que transborda do contêiner porque um label é mais longo do que o previsto em outro idioma. Um footer que sobe sobre o conteúdo principal porque uma seção intermediária perdeu sua altura mínima.
Esses bugs são invisíveis no Storybook. Cada componente, tomado isoladamente, está visualmente correto. É a montagem que causa o problema. E o Chromatic, por design, não testa a montagem: testa os tijolos, não o edifício.
O Delta-QA testa o edifício. Você grava um percurso no seu site, sem código, e a ferramenta o reproduz em um navegador de verdade a cada versão, com todos os componentes montados, seus estilos herdados, suas interações e seus dados. Cada página é comparada com sua referência como faria o olho humano: o relatório diz qual elemento mudou (um botão que passou de azul para verde, uma margem que se moveu). É o teste da realidade, não o teste da planta do arquiteto.
O abismo entre o Storybook e a produção
Existe uma defasagem estrutural entre o que o Storybook mostra e o que a produção exibe, e essa defasagem raramente é discutida.
Os dados. No Storybook, seus componentes recebem dados mock, escolhidos com cuidado para serem representativos e caberem no layout. Em produção, recebem dados reais: um nome de produto de 150 caracteres que ninguém previu, uma imagem com proporção improvável, um preço com número variável de casas decimais, uma lista de categorias que ocupa três linhas em vez de uma. Esses dados reais criam situações visuais que o Storybook nunca reproduz.
Os estilos herdados. No Storybook, cada componente é renderizado em uma sandbox CSS relativamente limpa. Em produção, os componentes herdam estilos globais, resets de CSS, temas, overrides contextuais e, às vezes, estilos de terceiros (widgets de analytics, chatbots, banner de cookies). Um componente pode ser perfeito no Storybook e visualmente quebrado em produção por causa de um conflito de estilos que nenhuma story reproduz.
Os estados dinâmicos. O Storybook testa estados predefinidos, aqueles que o desenvolvedor julgou útil documentar. Em produção, os componentes passam por estados intermediários, estados de erro imprevistos, combinações de estados que ninguém pensou em testar. O formulário com uma validação em andamento, o botão dentro de um contêiner flex que se redimensiona, o card de produto com uma promoção que adiciona um badge: cada combinação é um teste visual que o Storybook não cobre.
O Delta-QA testa o que seus usuários realmente veem. Não o que o Storybook promete que eles verão.
No-code vs Storybook: a questão do público
O Chromatic se dirige a desenvolvedores front-end que trabalham com Storybook. É um público legítimo e importante. Mas é um público restrito.
Para usar o Chromatic, você precisa ter testes escritos em código: stories do Storybook ou testes Playwright, Cypress ou Vitest. Precisa saber escrevê-los. Precisa entender o conceito de baseline e de snapshot visual. Precisa estar à vontade com um fluxo baseado em pull requests e integração contínua. Resumindo: você precisa ser desenvolvedor front-end.
O seu QA manager que quer verificar uma página antes do release? Ele não pode usar o Chromatic diretamente. O seu product owner que percebe um problema visual na homologação? Ele não consegue disparar um teste. O seu designer que quer comparar o layout com o resultado em produção? Ele não tem acesso ao fluxo do Chromatic sem passar por um desenvolvedor.
O Delta-QA abre o teste visual para toda a equipe. Sem Storybook obrigatório. Sem código. Sem pipeline de CI/CD para entender. Você navega pelo seu site como um usuário, o Delta-QA grava o cenário, o reproduz na versão seguinte e você lê o relatório. O QA verifica o percurso de compra antes da entrada em produção. O product owner confere que uma evolução não quebrou nada em outro lugar. Cada um é autônomo.
Para os desenvolvedores que querem verificar suas páginas a partir dos testes Playwright em CI, o Delta-QA agora tem um SDK, o SDK Vision: uma linha por página a verificar, e uma diferença não avaliada faz o teste falhar.
Isso não é anti-intelectualismo tecnológico. É o reconhecimento de que a qualidade visual diz respeito a todos, e de que as ferramentas deveriam refletir essa realidade.
Componentes vs páginas: dois níveis de teste complementares
Em vez de opor Chromatic e Delta-QA, é mais justo posicioná-los como dois níveis de uma estratégia completa de teste visual.
Nível componente (Chromatic): verificar se cada tijolo do design system está visualmente conforme suas especificações. É o teste unitário do visual. Detecta as regressões no nível mais granular, o mais cedo possível no ciclo de desenvolvimento (antes mesmo do merge).
Nível página (Delta-QA): verificar se as páginas montadas, com dados reais e estilos em cascata, estão visualmente corretas. É o teste de integração do visual. Detecta problemas de montagem, conflitos de estilos e regressões que só existem no contexto da página completa.
Uma equipe que faz os dois tem uma cobertura visual notável. As regressões de componentes são detectadas cedo pelo Chromatic. As regressões de páginas são detectadas pelo Delta-QA. A rede de segurança é dupla.
Mas se você só pode escolher um (por restrição de orçamento, de tempo ou de recursos), a pergunta passa a ser: qual nível de teste protege melhor os seus usuários? E a resposta, sem ambiguidade, é o nível página. Porque seus usuários não veem componentes. Eles veem páginas.
Cloud ou On-Premise: para onde vão as suas capturas?
Além do modelo componentes/páginas, há uma diferença de arquitetura que pesa muito para certas organizações: onde ficam as suas capturas de tela.
O Chromatic é um serviço em nuvem. Seus screenshots são enviados e armazenados na infraestrutura do Chromatic; em 10/2026, sua tabela de preços não menciona implantação self-hosted, nem mesmo no plano Enterprise (que oferece SSO, SLA e ajustes de retenção de dados). Para a maioria dos projetos públicos, isso não é problema. Mas para uma aplicação interna, um back-office com dados de clientes ou uma organização sujeita a exigências regulatórias rígidas, o simples fato de capturas da interface saírem do perímetro da empresa pode ser um impeditivo.
O Delta-QA oferece uma versão On-Premise, instalada em Docker na sua infraestrutura: suas capturas não saem da sua rede, e a oferta pode ser avaliada com um POC gratuito de um mês. É a mesma lógica da soberania de dados detalhada mais adiante, mas formulada no nível da arquitetura: data stays vs data leaves.
O modelo econômico: cobrança por snapshot
O Chromatic cobra pelo número de snapshots por mês. Um snapshot = uma story, um navegador, uma resolução. Com 200 componentes de 3 stories cada em 2 navegadores, são 1.200 snapshots por build. Vinte builds por dia (uma equipe ativa) dão 720.000 por mês.
Em 10/2026, o plano gratuito oferece 5.000 snapshots cobrados por mês, o suficiente para cobrir um primeiro escopo, rapidamente esgotado quando o design system cresce. E esse plano gratuito é limitado ao Chrome: o teste multinavegador (Firefox, Safari, Edge) começa no plano Starter, a US$ 179/mês para 35.000 snapshots. O plano Pro sobe para US$ 399/mês para 85.000 snapshots, cada snapshot adicional é cobrado a US$ 0,008, e o Enterprise é sob consulta. O TurboSnap atenua a fatura: apenas os testes afetados por uma mudança de arquivos são recapturados, os demais pesam menos na cota. Na prática, 180 stories × 3 resoluções = 540 snapshots por build, ou seja, apenas 9 builds antes de esgotar a cota gratuita. E isso cria a mesma tensão que no Percy: a cobertura de teste é inversamente proporcional ao orçamento. Sem o TurboSnap, as equipes acabam limitando as stories testadas ou a frequência dos builds para ficar dentro da cota.
O Delta-QA começa com uma conta gratuita, sem cartão de crédito. Sua cobertura é pensada em percursos e etapas verificadas, não em stories multiplicadas por navegadores e resoluções.
O Chromatic testa os componentes isolados; e as suas páginas completas? O Delta-QA as cobre em no-code e sem cartão de crédito. Testar o Delta-QA grátis →
O que o Chromatic faz e o Delta-QA não faz
A transparência exige reconhecer os pontos fortes exclusivos do Chromatic.
A revisão de UI colaborativa. O fluxo do Chromatic permite que desenvolvedores e designers validem visualmente as mudanças de componentes no contexto de uma pull request. É um processo de revisão integrado que não tem equivalente exato no Delta-QA.
O teste de todos os estados de um componente. Se o seu botão tem 12 variantes (tamanho, cor, estado, tema), o Chromatic as testa todas de forma sistemática. Testar essas 12 variantes no nível da página exigiria encontrar 12 páginas diferentes onde elas aparecem, o que nem sempre é possível.
O multinavegador. O Chromatic captura seus testes em Chrome, Firefox, Safari e Edge (a partir do plano Starter). O Delta-QA compara hoje no Chromium; Firefox e WebKit estão previstos.
A integração nativa com o Storybook. O Chromatic é feito pelos criadores do Storybook. A integração é a mais profunda possível: detecção automática de novas stories, configuração mínima, fluxo fluido. É uma vantagem real se o Storybook está no centro do seu fluxo de desenvolvimento de UI.
A documentação visual viva. O Chromatic mantém um histórico visual de cada componente ao longo do tempo. É uma biblioteca de design viva que mostra a evolução de cada componente, uma funcionalidade valiosa para design systems.
O que o Delta-QA traz e o Chromatic não cobre
O teste da realidade. As páginas em produção, com os dados reais, os estilos herdados reais, as interações reais entre componentes. Não a idealização limpa do Storybook, mas o mundo como ele é.
A acessibilidade universal. Qualquer membro da equipe pode rodar um teste visual. Sem precisar ser desenvolvedor, sem precisar conhecer o Storybook, sem precisar acessar o pipeline de CI. A democratização do teste visual.
A independência tecnológica. O Delta-QA funciona qualquer que seja o seu stack front-end. React, Vue, Angular, Svelte, WordPress, Shopify, site estático, aplicação legada em jQuery, tanto faz. Se aparece em um navegador, o Delta-QA testa. O Chromatic se apoia em testes escritos em código (Storybook, Playwright, Cypress, Vitest), portanto em um projeto front-end preparado para isso.
A soberania dos dados. Com a oferta On-Premise, a comparação roda na sua infraestrutura e nenhuma captura é enviada a terceiros. Para aplicações internas, dados sensíveis e organizações sujeitas a regulamentações rígidas.
Um relatório como faria o olho humano. Cada diferença é associada a um elemento da página e descrita com clareza: a cor, a margem, a fonte, a posição. Você sabe o que olhar sem interpretar uma imagem de diferenças.
O cenário ideal: os dois juntos
Se a sua equipe já usa o Storybook e tem orçamento para o Chromatic, a combinação das duas ferramentas é a estratégia mais robusta.
O Chromatic vigia seus componentes no nível do design system. Cada mudança de estilo, cada variação, cada estado é verificado visualmente. As regressões são detectadas durante o desenvolvimento, antes que o código chegue à branch principal.
O Delta-QA vigia suas páginas em produção (ou em staging). Os problemas de montagem, os conflitos de estilos, os bugs que só aparecem no contexto real são detectados antes que os usuários os vejam.
Juntos, formam uma dupla cobertura: os tijolos de um lado, os percursos montados do outro.
O cenário pragmático: uma única ferramenta
Se você precisa escolher uma única ferramenta (porque o orçamento é limitado, porque a equipe é pequena ou porque quer começar simples), a questão se resume a isto: o que protege melhor os seus usuários?
Seus usuários não veem seus componentes do Storybook. Eles veem suas páginas. Interagem com suas páginas. Formam sua opinião sobre o seu produto olhando suas páginas. Um componente perfeito no Storybook, mas quebrado na página montada, é um componente quebrado do ponto de vista do usuário.
O Delta-QA testa o que seus usuários veem. É simples assim.
Pronto para testar as páginas que seus usuários realmente veem? 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 →
FAQ
O Chromatic funciona sem Storybook?
Sim. Em 10/2026, o Chromatic também captura as páginas dos seus testes Playwright, Cypress ou Vitest, além das stories do Storybook. É preciso, porém, ter testes escritos em código: são eles que definem o que é capturado. O Delta-QA parte de um cenário gravado sem código, qualquer que seja o stack que produz suas páginas; para testes Playwright, ele oferece o SDK Vision.
Testar os componentes no Storybook basta para garantir a qualidade visual?
Não. Componentes testados em isolamento não reproduzem as condições reais de uma página montada: herança de estilos, dados dinâmicos, interações entre componentes, estilos de terceiros. O Chromatic verifica se os seus tijolos estão corretos. O Delta-QA verifica se a montagem está correta. Os dois níveis são necessários para uma cobertura completa.
O Chromatic detecta problemas de responsividade?
Sim, dentro do limite do que o Storybook mostra. Você pode configurar suas stories para diferentes tamanhos de viewport, e o Chromatic as testará. Mas os problemas de responsividade específicos de uma página montada (um elemento que transborda quando combinado com outros, um layout que quebra com dados reais longos) não serão detectados. O Delta-QA, por sua vez, compara a página montada em um navegador de verdade, com seus dados reais.
O que o plano gratuito do Chromatic cobre?
Em 10/2026, o plano gratuito do Chromatic oferece 5.000 snapshots cobrados por mês, apenas no Chrome, o que cobre algumas dezenas de componentes com builds ocasionais. Assim que o número de componentes ou a frequência de builds aumenta, a cota é rapidamente atingida. Um projeto com 100 componentes, 3 stories por componente e 2 builds diários consome cerca de 18.000 snapshots por mês sem o TurboSnap.
É possível usar o Delta-QA para testar componentes isolados?
O Delta-QA é otimizado para páginas completas, não para componentes isolados. Se você tem um ambiente em que seus componentes são renderizados individualmente em URLs acessíveis (como um Storybook publicado), tecnicamente pode usar o Delta-QA para compará-los. Mas esse não é seu caso de uso principal. Para o teste de componentes isolados, o Chromatic continua sendo a ferramenta de referência.
Como o Delta-QA lida com design systems se não atua no nível do componente?
O Delta-QA verifica a coerência visual do seu design system no nível em que ela mais importa: nas páginas que o utilizam. Se uma mudança no seu design system quebra o layout de uma dezena de páginas, o Delta-QA detecta diretamente. É um teste end-to-end do design system, complementar ao teste unitário do Chromatic.