Prueba visual de componentes (component visual testing): método de verificación automatizada que consiste en renderizar componentes de interfaz de usuario de forma aislada (fuera del contexto de la página completa) y comparar su apariencia con un estado de referencia validado, para detectar las regresiones visuales a nivel del design system antes de que se propaguen a las páginas en producción.
Hay una pregunta que los equipos de front-end evitan hacerse con cuidado: «nuestros componentes se prueban visualmente en Storybook, pero ¿también se prueban nuestras páginas en producción?». En la mayoría de los casos, la respuesta es no. Y esa laguna sale cara, porque los bugs visuales que llegan a sus usuarios no viven en Storybook: viven en las páginas reales, con datos reales, interacciones reales y combinaciones de componentes reales.
Chromatic es una excelente herramienta para probar componentes aislados. Delta-QA está pensado para probar páginas completas. Para una introducción a las pruebas visuales, consulte nuestra guía de regresión visual. No son competidores en sentido estricto: son herramientas que miran el mismo problema desde alturas distintas. Pero si tiene que elegir una sola, o si quiere entender qué aporta cada una, esta comparativa va directa al grano.
Todas nuestras comparativas, con criterios verificables: Alternativas y comparativas.
Chromatic verifica componentes aislados; ¿quién prueba sus páginas reales en producción? Delta-QA las cubre sin escribir código, con una cuenta gratuita y sin tarjeta bancaria. Probar Delta-QA gratis →
Chromatic: el guardián del design system
Chromatic, creado por los mantenedores de Storybook, es la extensión natural del ecosistema Storybook para las pruebas visuales. Para una visión general de las pruebas visuales aplicadas a los design systems, consulte nuestra guía dedicada. El concepto es brillante en su lógica: usted ya definió sus componentes en Storybook con sus distintos estados (stories). Chromatic captura una imagen de cada story en cada commit, la compara con la línea base y señala los cambios.
Es un flujo de trabajo perfectamente integrado para los equipos que trabajan con design systems. Su diseñador define un botón con cuatro variantes (primary, secondary, disabled, loading). Su desarrollador implementa esas variantes y crea las stories correspondientes. Chromatic verifica en cada cambio de código que las cuatro variantes no hayan sufrido una regresión visual. Si el border-radius del botón cambia por accidente, Chromatic lo detecta antes de que nadie haga una revisión de código.
La herramienta ofrece también una función de revisión de UI (UI Review) que permite a diseñadores y desarrolladores validar visualmente los cambios antes del merge. Es, en esencia, una code review visual, y resulta realmente útil para mantener la coherencia de un design system.
A 10/2026, Chromatic ya no se limita a las stories: también ejecuta pruebas de interacción y de accesibilidad, se apoya en pruebas Playwright, Cypress o Vitest existentes y renderiza las capturas en cuatro navegadores (Chrome, Firefox, Safari, Edge). Además se presenta como un guardarraíl para las interfaces escritas por agentes de IA, con un servidor MCP documentado que les da el contexto de los componentes validados.
El punto ciego de Chromatic: el mundo real
Este es el problema que Chromatic no resuelve (no por falta de calidad, sino por decisión de arquitectura): los componentes aislados no se comportan como las páginas ensambladas.
Un botón probado de forma aislada en Storybook se renderiza en un entorno controlado: un viewport fijo, sin vecinos, sin contexto CSS heredado, sin datos dinámicos, sin interacciones con otros componentes. Eso es justo lo que hace fiable la prueba a nivel de componente. Pero también lo que la deja ciega ante los problemas de ensamblaje.
¿Qué se rompe visualmente en producción? Rara vez un componente aislado. Lo que se rompe es la combinación. Un componente de cabecera que se solapa con un componente de navegación porque cambió un z-index. Una cuadrícula de productos que se desalinea porque un componente de tarjeta recibió un margin adicional. Un formulario que desborda su contenedor porque una etiqueta es más larga de lo previsto en otro idioma. Un pie de página que sube sobre el contenido principal porque una sección intermedia perdió su altura mínima.
Estos bugs son invisibles en Storybook. Cada componente, tomado por separado, es visualmente correcto. Es su ensamblaje lo que falla. Y Chromatic, por diseño, no prueba el ensamblaje: prueba los ladrillos, no el edificio.
Delta-QA prueba el edificio. Usted graba un recorrido en su sitio, sin código, y la herramienta lo reproduce en un navegador real en cada versión, con todos los componentes ensamblados, sus estilos heredados, sus interacciones y sus datos. Cada página se compara con su referencia como lo haría el ojo humano: el informe indica qué elemento ha cambiado (un botón que pasó de azul a verde, un margen que se movió). Es la prueba de la realidad, no la prueba del plano del arquitecto.
La brecha entre Storybook y producción
Existe un desfase estructural entre lo que muestra Storybook y lo que muestra producción, y rara vez se habla de él.
Los datos. En Storybook, sus componentes reciben datos simulados (mock), cuidadosamente elegidos para ser representativos y encajar en la maqueta. En producción reciben datos reales: un nombre de producto de 150 caracteres que nadie había previsto, una imagen con una proporción improbable, un precio con un número de decimales variable, una lista de categorías que ocupa tres líneas en lugar de una. Esos datos reales crean situaciones visuales que Storybook nunca reproduce.
Los estilos heredados. En Storybook, cada componente se renderiza en un sandbox CSS relativamente limpio. En producción, los componentes heredan estilos globales, resets CSS, temas, overrides contextuales y, a veces, estilos de terceros (widgets de analítica, chatbots, banner de cookies). Un componente puede ser perfecto en Storybook y estar visualmente roto en producción por un conflicto de estilos que ninguna story reproduce.
Los estados dinámicos. Storybook prueba estados predefinidos, los que el desarrollador consideró oportuno documentar. En producción, los componentes pasan por estados intermedios, estados de error imprevistos, combinaciones de estados que a nadie se le ocurrió probar. El formulario con una validación en curso, el botón dentro de un contenedor flex que cambia de tamaño, la tarjeta de producto con una promoción que añade una insignia: cada combinación es una prueba visual que Storybook no cubre.
Delta-QA prueba lo que sus usuarios ven realmente. No lo que Storybook promete que verán.
Sin código vs Storybook: la cuestión de la audiencia
Chromatic se dirige a los desarrolladores front-end que trabajan con Storybook. Es una audiencia legítima e importante. Pero es una audiencia reducida.
Para usar Chromatic, necesita pruebas escritas en código: stories de Storybook o pruebas Playwright, Cypress o Vitest. Tiene que saber escribirlas. Tiene que entender el concepto de línea base y de snapshot visual. Tiene que sentirse cómodo con un flujo basado en pull requests e integración continua. En resumen: tiene que ser desarrollador front-end.
¿Su QA manager que quiere verificar una página antes del release? No puede usar Chromatic directamente. ¿Su product owner que nota un problema visual en la recepción? No puede lanzar una prueba. ¿Su diseñador que quiere comparar la maqueta con el resultado en producción? No tiene acceso al flujo de Chromatic sin pasar por un desarrollador.
Delta-QA abre las pruebas visuales a todo el equipo. No requiere Storybook. Sin código. Sin un pipeline CI/CD que entender. Usted recorre su sitio como un usuario, Delta-QA graba el escenario, lo reproduce en la versión siguiente y usted lee el informe. El QA verifica el recorrido de compra antes de la puesta en producción. El product owner comprueba que una evolución no ha roto nada en otro sitio. Cada uno es autónomo.
Para los desarrolladores que quieren verificar sus páginas desde sus pruebas Playwright en CI, Delta-QA cuenta ahora con un SDK, el SDK Vision: una línea por página a verificar, y una diferencia no revisada hace fallar la prueba.
No es antiintelectualismo tecnológico. Es reconocer que la calidad visual concierne a todos, y que las herramientas deberían reflejar esa realidad.
Componentes vs páginas: dos niveles de prueba complementarios
En lugar de oponer Chromatic y Delta-QA, es más justo situarlos como dos niveles de una estrategia completa de pruebas visuales.
Nivel componente (Chromatic): verificar que cada ladrillo del design system cumple visualmente sus especificaciones. Es la prueba unitaria de lo visual. Detecta las regresiones al nivel más granular, lo antes posible en el ciclo de desarrollo (incluso antes del merge).
Nivel página (Delta-QA): verificar que las páginas ensambladas, con los datos reales y los estilos en cascada, son visualmente correctas. Es la prueba de integración de lo visual. Detecta los problemas de ensamblaje, los conflictos de estilos y las regresiones que solo existen en el contexto de la página completa.
Un equipo que hace las dos cosas tiene una cobertura visual notable. Chromatic detecta pronto las regresiones de componentes. Delta-QA detecta las regresiones de páginas. La red de seguridad es doble.
Pero si solo puede elegir una (por restricciones de presupuesto, de tiempo o de recursos), la pregunta pasa a ser: ¿qué nivel de prueba protege mejor a sus usuarios? Y la respuesta, sin ambigüedad, es el nivel página. Porque sus usuarios no ven componentes. Ven páginas.
Cloud u On-Premise: ¿adónde van sus capturas?
Más allá del modelo componentes/páginas, hay una diferencia de arquitectura que pesa mucho en ciertas organizaciones: dónde viven sus capturas de pantalla.
Chromatic es un servicio cloud. Sus capturas se envían y almacenan en la infraestructura de Chromatic; a 10/2026, su tabla de precios no menciona un despliegue self-hosted, ni siquiera en el plan Enterprise (que ofrece SSO, SLA y ajustes de retención de datos). Para la mayoría de los proyectos públicos no es un problema. Pero para una aplicación interna, un back-office con datos de clientes o una organización sujeta a restricciones regulatorias estrictas, el simple hecho de que capturas de la interfaz salgan del perímetro de la empresa puede ser un impedimento.
Delta-QA ofrece una versión On-Premise, instalada en Docker en su infraestructura: sus capturas no salen de su red, y la oferta se evalúa con un POC gratuito de un mes. Es la misma lógica que la soberanía de los datos detallada más abajo, pero formulada a nivel de arquitectura: data stays vs data leaves.
El modelo económico: la facturación por snapshot
Chromatic factura por número de snapshots al mes. Un snapshot = una story, un navegador, una resolución. Con 200 componentes de 3 stories cada uno en 2 navegadores, son 1 200 snapshots por build. Veinte builds al día (un equipo activo) son 720 000 al mes.
A 10/2026, el plan gratuito ofrece 5 000 snapshots facturados al mes, suficiente para cubrir un primer perímetro, que se agota rápido cuando el design system crece. Y ese plan gratuito está limitado a Chrome: las pruebas multinavegador (Firefox, Safari, Edge) empiezan en el plan Starter, a 179 $/mes por 35 000 snapshots. El plan Pro sube a 399 $/mes por 85 000 snapshots, cada snapshot adicional se factura a 0,008 $, y el Enterprise es a medida. TurboSnap atenúa la factura: solo se recapturan las pruebas afectadas por un cambio de archivos, las demás cuentan menos en la cuota. En concreto, 180 stories × 3 resoluciones = 540 snapshots por build, apenas 9 builds antes de agotar la cuota gratuita. Y esto crea la misma tensión que con Percy: la cobertura de pruebas es inversamente proporcional al presupuesto. Sin TurboSnap, los equipos acaban limitando las stories probadas o la frecuencia de los builds para mantenerse dentro de su cuota.
Delta-QA se empieza a usar con una cuenta gratuita, sin tarjeta bancaria. Su cobertura se razona en recorridos y pasos verificados, no en stories multiplicadas por navegadores y resoluciones.
Chromatic prueba los componentes aislados; ¿y sus páginas completas? Delta-QA las cubre sin código y sin tarjeta bancaria. Probar Delta-QA gratis →
Lo que Chromatic hace y Delta-QA no
La transparencia obliga a reconocer las fortalezas únicas de Chromatic.
La revisión de UI colaborativa. El flujo de Chromatic permite a desarrolladores y diseñadores validar visualmente los cambios de componentes dentro de una pull request. Es un proceso de revisión integrado que no tiene equivalente exacto en Delta-QA.
La prueba de todos los estados de un componente. Si su botón tiene 12 variantes (tamaño, color, estado, tema), Chromatic las prueba todas de forma sistemática. Probar esas 12 variantes a nivel de página exigiría encontrar 12 páginas distintas donde aparezcan, algo que no siempre es posible.
El multinavegador. Chromatic captura sus pruebas en Chrome, Firefox, Safari y Edge (a partir del plan Starter). Delta-QA compara hoy en Chromium; Firefox y WebKit están previstos.
La integración nativa con Storybook. Chromatic lo hacen los creadores de Storybook. La integración es todo lo profunda que puede ser: detección automática de nuevas stories, configuración mínima, flujo fluido. Es una ventaja real si Storybook es el centro de su flujo de desarrollo de UI.
La documentación visual viva. Chromatic mantiene un historial visual de cada componente a lo largo del tiempo. Es una biblioteca de diseño viva que muestra la evolución de cada componente, una función valiosa para los design systems.
Lo que Delta-QA aporta y Chromatic no cubre
La prueba de la realidad. Las páginas en producción, con los datos reales, los estilos heredados reales, las interacciones reales entre componentes. No la idealización limpia de Storybook, sino el mundo tal como es.
La accesibilidad universal. Cualquier miembro del equipo puede lanzar una prueba visual. No hace falta ser desarrollador, ni conocer Storybook, ni acceder al pipeline CI. La democratización de las pruebas visuales.
La independencia tecnológica. Delta-QA funciona con cualquier stack front-end. React, Vue, Angular, Svelte, WordPress, Shopify, sitio estático, aplicación legacy en jQuery, da igual. Si se muestra en un navegador, Delta-QA lo prueba. Chromatic se apoya en pruebas escritas en código (Storybook, Playwright, Cypress, Vitest), es decir, en un proyecto front-end equipado para ello.
La soberanía de los datos. Con la oferta On-Premise, la comparación se ejecuta en su infraestructura y ninguna captura se envía a un tercero. Para las aplicaciones internas, los datos sensibles y las organizaciones sujetas a regulaciones estrictas.
Un informe como lo haría el ojo humano. Cada diferencia se asocia a un elemento de la página y se describe con claridad: el color, el margen, la fuente, la posición. Usted sabe qué mirar sin interpretar una imagen de diferencias.
El escenario ideal: las dos juntas
Si su equipo ya usa Storybook y tiene presupuesto para Chromatic, combinar las dos herramientas es la estrategia más robusta.
Chromatic vigila sus componentes a nivel del design system. Cada cambio de estilo, cada variación, cada estado se verifica visualmente. Las regresiones se detectan en el momento del desarrollo, antes de que el código llegue a la rama principal.
Delta-QA vigila sus páginas en producción (o en staging). Los problemas de ensamblaje, los conflictos de estilos y los bugs que solo aparecen en el contexto real se detectan antes de que los usuarios los vean.
Juntas, ofrecen una doble cobertura: los ladrillos por un lado, los recorridos ensamblados por otro.
El escenario pragmático: una sola herramienta
Si tiene que elegir una sola herramienta (porque el presupuesto es limitado, porque el equipo es pequeño o porque quiere empezar de forma sencilla), la cuestión se resume en esto: ¿qué protege mejor a sus usuarios?
Sus usuarios no ven sus componentes de Storybook. Ven sus páginas. Interactúan con sus páginas. Se forman una opinión de su producto mirando sus páginas. Un componente perfecto en Storybook pero roto en la página ensamblada es un componente roto desde el punto de vista del usuario.
Delta-QA prueba lo que ven sus usuarios. Así de simple.
¿Listo para probar las páginas que sus usuarios ven de verdad? Lance su primera comparación con Delta-QA, con una cuenta gratuita y sin tarjeta bancaria. Probar Delta-QA gratis →
FAQ
¿Funciona Chromatic sin Storybook?
Sí. A 10/2026, Chromatic también captura las páginas de sus pruebas Playwright, Cypress o Vitest, además de las stories de Storybook. Eso sí, hacen falta pruebas escritas en código: ellas definen qué se captura. Delta-QA parte de un escenario grabado sin código, sea cual sea el stack que produce sus páginas; para las pruebas Playwright, ofrece su SDK Vision.
¿Basta con probar los componentes en Storybook para garantizar la calidad visual?
No. Los componentes probados de forma aislada no reproducen las condiciones reales de una página ensamblada: herencia de estilos, datos dinámicos, interacciones entre componentes, estilos de terceros. Chromatic verifica que sus ladrillos son correctos. Delta-QA verifica que el ensamblaje es correcto. Los dos niveles son necesarios para una cobertura completa.
¿Detecta Chromatic los problemas responsive?
Sí, dentro de lo que muestra Storybook. Puede configurar sus stories para distintos tamaños de viewport y Chromatic las probará. Pero los problemas responsive específicos de una página ensamblada (un elemento que desborda al combinarse con otros, un layout que se rompe con datos reales largos) no se detectarán. Delta-QA, en cambio, compara la página ensamblada en un navegador real, con sus datos reales.
¿Qué cubre el plan gratuito de Chromatic?
A 10/2026, el plan gratuito de Chromatic ofrece 5 000 snapshots facturados al mes, solo en Chrome, lo que cubre unas decenas de componentes con builds ocasionales. En cuanto aumenta el número de componentes o la frecuencia de los builds, la cuota se alcanza enseguida. Un proyecto con 100 componentes, 3 stories por componente y 2 builds diarios consume unos 18 000 snapshots al mes sin TurboSnap.
¿Se puede usar Delta-QA para probar componentes aislados?
Delta-QA está optimizado para páginas completas, no para componentes aislados. Si tiene un entorno donde sus componentes se renderizan individualmente en URLs accesibles (como un Storybook desplegado), técnicamente puede usar Delta-QA para compararlos. Pero no es su caso de uso principal. Para la prueba de componentes aislados, Chromatic sigue siendo la herramienta de referencia.
¿Cómo gestiona Delta-QA los design systems si no es a nivel de componente?
Delta-QA verifica la coherencia visual de su design system al nivel donde más importa: en las páginas que lo usan. Si un cambio en su design system rompe el diseño de una decena de páginas, Delta-QA lo detecta directamente. Es una prueba end-to-end del design system, complementaria a la prueba unitaria de Chromatic.