Regresión visual: modificación no intencionada del aspecto de una interfaz de usuario (maquetación, colores, tipografía, espaciado, alineación) introducida por un cambio de código, una actualización de dependencia o una modificación de configuración, y detectable únicamente mediante la comparación visual entre dos estados de la interfaz.
Esta es una verdad que muchos equipos que usan Cypress prefieren ignorar: su suite de pruebas Cypress, por completa que sea, es estructuralmente ciega a toda una categoría de bugs. Las regresiones visuales atraviesan sus aserciones como el agua un colador, no porque sus pruebas estén mal escritas, sino porque Cypress sencillamente no fue diseñado para detectarlas.
No es una crítica a Cypress. Es una constatación. Y la diferencia entre una constatación y una crítica es que la constatación pide una solución, no un debate.
Todas nuestras comparativas, con criterios verificables: Alternativas y comparativas.
Su suite Cypress confirma que todo funciona, no que todo se vea bien. Complétela con Delta-QA: sus recorridos grabados sin código, con una cuenta gratuita y sin tarjeta bancaria. Probar Delta-QA gratis →
Cypress: excelente en lo suyo, ausente donde lo visual importa
Cypress revolucionó las pruebas front-end cuando llegó al mercado. La ejecución en el navegador, la recarga automática, el time-travel debugging, la API intuitiva (todo ello hizo accesibles las pruebas end-to-end a equipos que consideraban Selenium un instrumento de tortura medieval). Y en el terreno de las pruebas funcionales, Cypress sigue siendo una herramienta notable.
Pero hágase esta pregunta: ¿cuándo fue la última vez que escribió una prueba Cypress que verifica que su página de inicio se ve bien? No que un botón exista. No que haya un texto. Que se ve bien: que los espaciados son correctos, que los colores son coherentes, que la maquetación no se ha movido ni un píxel.
La respuesta, para la inmensa mayoría de los equipos, es «nunca». Y no es por descuido. Es porque Cypress no compara imágenes. Su propia documentación lo dice a 10/2026: el comando cy.screenshot() captura una imagen, pero no la compara; la prueba visual pasa por plugins o servicios de terceros.
El punto ciego de Cypress: no hay comparación visual nativa
Cuando escribe cy.get('.button').should('be.visible'), verifica que el elemento existe en el DOM y que el CSS no lo oculta. No verifica que tenga el color correcto. No verifica que esté en el lugar correcto. No verifica que su texto sea legible. No verifica que no se solape con otro elemento.
Un botón puede ser «visible» según Cypress (presente en el DOM, display distinto de none, opacity mayor que 0) y estar completamente inutilizable visualmente. Texto blanco sobre fondo blanco. Tamaño de 2 píxeles por 2 píxeles. Posicionado a 3000 píxeles a la derecha de la pantalla. Cypress le dirá que todo va bien. Su usuario le dirá otra cosa.
Es un punto ciego fundamental, no una limitación menor. Una parte importante de los problemas que reportan los usuarios tiene que ver con la visualización: un botón ilegible, un formulario desplazado, un bloque que desborda. Y Cypress, en su configuración nativa, no detecta ninguno.
Los plugins visuales de Cypress: una solución parcial y frágil
Ante esta carencia, el ecosistema Cypress ha producido plugins de pruebas visuales. Los más conocidos se apoyan en servicios de terceros (Percy, Applitools, Happo) para capturar imágenes y compararlas, o en cypress-image-snapshot para una comparación local. Si busca el detalle de cada opción, nuestra guía completa para añadir pruebas visuales a Cypress repasa estos enfoques y sus límites reales. Es una vía que funciona, pero con restricciones significativas.
La dependencia de un servicio de terceros. Cada plugin visual para Cypress se apoya en una plataforma externa. Sus capturas se envían a los servidores de un proveedor, se comparan allí y los resultados le llegan de vuelta. Esto añade latencia a su pipeline CI, una dependencia de red y un coste de licencia del servicio de terceros, además del coste de Cypress Cloud si lo usa.
La complejidad de configuración. Añadir un plugin visual a Cypress exige instalar un paquete npm, configurar la autenticación con el servicio de terceros, modificar sus pruebas existentes para añadir llamadas de captura, gestionar los tokens de API y formar a su equipo en la plataforma externa. No es insuperable, pero tampoco es la experiencia de «funciona en 5 minutos» que prometen las páginas de marketing.
El mantenimiento doble. Acaba manteniendo dos sistemas: sus pruebas Cypress y la configuración del plugin visual. Cuando Cypress se actualiza, el plugin puede romperse. Cuando el servicio de terceros cambia su API, sus pruebas pueden fallar. Cuando cambia su equipo, hay que formar a los nuevos en dos herramientas en lugar de una.
La cobertura limitada. Un plugin visual integrado en Cypress captura imágenes durante la ejecución de sus pruebas funcionales. Lo que significa que la cobertura visual depende de la cobertura funcional. Si no tiene una prueba Cypress para la página «Condiciones Generales de Venta», tampoco tiene prueba visual para esa página. Su cobertura visual está limitada por su cobertura funcional, y ambas no tienen ninguna razón para coincidir.
Delta-QA: la prueba visual como disciplina autónoma
Delta-QA parte de una filosofía distinta. La prueba visual no es una función injertada en una herramienta de pruebas funcionales. Es una disciplina por derecho propio, con sus propias exigencias, sus propios flujos de trabajo y sus propios usuarios.
La independencia respecto a las pruebas funcionales. Delta-QA graba sus recorridos mientras usted navega. No necesita una prueba funcional como vehículo para capturar una página. Su cobertura visual no depende de su cobertura funcional: puede verificar decenas de páginas sin escribir una sola prueba.
La accesibilidad para quienes no son desarrolladores. ¿Quiénes son las personas más competentes para juzgar la calidad visual de una interfaz? Los diseñadores. Los QA manuales. Los product owners. Y esas personas, en la mayoría de las organizaciones, no saben escribir JavaScript. Con Cypress + plugin visual, dependen de un desarrollador para configurar, lanzar e interpretar las pruebas. Con Delta-QA, son autónomas. Es una diferencia que cambia la dinámica de un equipo.
La gestión nativa de las referencias. Delta-QA integra un flujo completo: informe que compara la página como lo haría el ojo humano y nombra cada elemento cambiado, juicio de cada diferencia (intencionada o bug), historial de modificaciones. Este flujo está pensado para equipos multidisciplinares, no para un desarrollador en solitario que hace push y merge en la misma mañana.
El navegador. Delta-QA reproduce sus recorridos en un navegador real, Chromium hoy; Firefox y WebKit están previstos. En el lado de Cypress, se admiten Chrome, Edge y Firefox, y WebKit sigue siendo experimental.
El problema estructural de los plugins: la ley de la cobertura acoplada
Retomemos este punto, porque merece desarrollarse. Cuando su prueba visual está acoplada a su prueba funcional (como ocurre con los plugins visuales de Cypress), su cobertura visual hereda todas las limitaciones de su cobertura funcional.
¿Tiene una prueba Cypress para el embudo de compra? La cobertura visual del embudo de compra está asegurada. ¿No tiene una prueba Cypress para la página de FAQ? No hay cobertura visual de la página de FAQ. ¿Su prueba Cypress de la página de perfil cubre el caso «usuario conectado con suscripción premium»? Tiene cobertura visual para ese caso, pero no para «usuario conectado sin suscripción» ni para «usuario cuya suscripción ha caducado».
La cobertura funcional y la cobertura visual tienen lógicas distintas. En lo funcional, se prueban recorridos: secuencias de acciones y verificaciones. En lo visual, se prueban estados: instantáneas de páginas en condiciones dadas. Un recorrido funcional de 10 pasos puede necesitar solo 2 verificaciones visuales (página de entrada y página de confirmación). A la inversa, una página sencilla sin lógica funcional compleja (una página «Acerca de») puede requerir una verificación visual en 5 resoluciones y 3 navegadores.
Acoplar ambas es obligar a una disciplina a adoptar la cobertura de la otra. Es como decir que solo inspeccionará visualmente una sala de la fábrica cuando un operario entre a usar una máquina. Los días en que nadie trabaja en esa sala, las fugas de agua pasan inadvertidas.
Cypress lo hace mejor: la prueba funcional
Reconozcamos las fortalezas de Cypress, porque son reales y significativas.
La experiencia de desarrollador. Cypress fue diseñado por desarrolladores para desarrolladores. La interfaz de depuración con time-travel, la rapidez de ejecución, la API encadenada y fluida (es un placer usarla). Delta-QA no pretende ofrecer esa experiencia porque no es su terreno de juego.
La verificación de la lógica de negocio. Un embudo de pago que calcula correctamente los impuestos, los gastos de envío y los códigos promocionales: eso lo verifica Cypress. No Delta-QA. La lógica de negocio es invisible visualmente hasta que produce un resultado mostrado, e incluso entonces, verificar que «el importe mostrado es correcto» exige conocer el importe esperado, algo que solo una prueba funcional puede calcular.
La interceptación de red. Cypress puede interceptar peticiones HTTP, simular respuestas del servidor y probar casos de error. Es una potente herramienta de pruebas de integración front-end que va mucho más allá de la simple verificación de interfaz.
Un ecosistema Cloud que se amplía. A 10/2026, Cypress Cloud ofrece Test Replay para reproducir un fallo, UI Coverage, Cypress Accessibility, resúmenes de fallos generados por IA, y el comando cy.prompt() convierte pasos escritos en lenguaje natural en comandos Cypress. Nada de esto compara el aspecto de una página con una referencia, pero la herramienta avanza rápido.
La velocidad de ejecución. La arquitectura de Cypress, que ejecuta las pruebas en el mismo proceso que la aplicación, ofrece una velocidad de ejecución notable para las pruebas funcionales. Sin latencia de red entre la prueba y la aplicación, sin protocolo WebDriver intermedio.
Su suite Cypress valida la lógica, no el aspecto. Cubra esa carencia con Delta-QA: pruebas visuales sin código, cuenta gratuita y sin tarjeta bancaria. Probar Delta-QA gratis →
Delta-QA lo hace mejor: la prueba visual
La cobertura rápida. Cubrir visualmente sus páginas principales lleva el tiempo de recorrerlas en Delta-QA. Obtener la misma cobertura con un plugin de Cypress exigiría escribir una prueba para cada página, gestionar las líneas base y estabilizar las capturas. Días de trabajo por un lado, unas horas de navegación por el otro.
El flujo de aprobación. Cuando Delta-QA detecta un cambio, su diseñador puede juzgarlo directamente en la interfaz. No hace falta pasar por un desarrollador, ni entender el informe de Cypress. El informe habla el lenguaje de las personas que juzgan la calidad visual: qué elemento ha cambiado y cómo.
La reducción de falsos positivos. Los plugins visuales para Cypress suelen heredar las limitaciones de la comparación píxel a píxel en bruto. ¿Un antialiasing de fuente distinto entre dos ejecuciones? Falso positivo. ¿Un cursor de texto que aparece en un campo? Falso positivo. Delta-QA compara los elementos de la página en lugar de sus píxeles: una variación de renderizado que no cambia ni el color, ni el tamaño, ni la posición de un elemento no se señala.
El historial visual. Delta-QA conserva el historial de las referencias y de los cambios juzgados. Puede reconstruir la evolución de una página a lo largo de las versiones. Con un plugin local de Cypress, sus líneas base son archivos en Git (versionados, pero sin una interfaz para visualizar su evolución).
El escenario típico: cuando el plugin de Cypress ya no basta
Imaginemos un escenario común. Su equipo usa Cypress desde hace dos años. Tiene 300 pruebas funcionales. Su cobertura es buena. Un día, una refactorización de CSS afecta a su design system. Cambia la variable --color-primary. Todas las pruebas Cypress pasan, ninguna verifica los colores. En producción, 30 páginas tienen un botón de acción cuyo contraste ha dejado de ser suficiente para ser legible. El soporte recibe 15 tickets en dos horas. La corrección se despliega de urgencia.
Tras este incidente, su líder técnico decide añadir un plugin visual a Cypress. La instalación lleva media jornada. La configuración de líneas base para 50 páginas críticas lleva un día. Las primeras ejecuciones generan 47 falsos positivos. Clasificar los falsos positivos lleva un día. Dos semanas después, un desarrollador actualiza Cypress y el plugin ya no es compatible. La suite visual se desactiva «temporalmente». Tres meses después, sigue desactivada.
Este escenario no es inventado: es el relato compuesto de decenas de conversaciones con equipos QA. El problema de fondo no es el plugin. Es que la prueba visual injertada en una herramienta de pruebas funcionales nunca es prioritaria. Siempre es «lo extra» que se hace cuando hay tiempo: es decir, nunca.
Delta-QA evita esta trampa porque la prueba visual es la razón de ser de la herramienta, no un añadido opcional. No hay una suite funcional que tenga prioridad. No hay una configuración más urgente que mantener. La prueba visual es la prioridad, y la herramienta está construida en torno a ella.
La combinación ganadora: Cypress + Delta-QA
La postura que defendemos no es «abandone Cypress por Delta-QA». Sería absurdo. Cypress es una excelente herramienta de pruebas funcionales. Delta-QA está diseñado para la no regresión de interfaz. La combinación de ambas ofrece una cobertura QA que ninguna de las dos puede dar por sí sola.
Cypress verifica que su aplicación funciona. Los recorridos de usuario, la lógica de negocio, las integraciones de API, los casos de error. Es la capa funcional de su aseguramiento de la calidad.
Delta-QA verifica que su aplicación se ve bien. Los colores, la tipografía, los espaciados, la maquetación. Es la capa visual de su aseguramiento de la calidad.
Cada capa tiene su ritmo. Las pruebas Cypress corren en su pipeline CI/CD; los escenarios de Delta-QA se reproducen en cada versión. Cada una mira una dimensión distinta de la calidad, con herramientas optimizadas para esa dimensión.
Es como tener a la vez un sistema de alarma y cámaras de vigilancia. La alarma detecta las intrusiones (funcional: alguien ha entrado y no debería). Las cámaras muestran lo que ocurre (visual: ¿todo tiene aspecto normal?). Las dos juntas son más eficaces que cada una por separado.
El argumento del «ya tenemos Cypress, es suficiente»
Es la objeción más frecuente. «Ya hemos invertido en Cypress, no vamos a añadir otra herramienta.» Es un argumento comprensible pero falaz. Ya tiene un martillo, pero eso no convierte cada problema en un clavo.
Si su aplicación tiene una interfaz de usuario (y si lee este artículo, probablemente la tiene), una parte significativa del valor que perciben sus usuarios viene del aspecto de esa interfaz. No de la lógica de negocio subyacente, por brillante que sea. Un usuario no ve su arquitectura de microservicios. Ve un botón azul, un formulario alineado, una tipografía coherente.
No probar esa dimensión es apostar a que nadie romperá jamás el CSS de su aplicación. Es una apuesta que va a perder. La cuestión no es si, sino cuándo. Y cuando ocurra, el coste será proporcional al tiempo que la regresión pase en producción: un tiempo que se reduce detectándola antes del despliegue.
Cuánto se tarda en añadir Delta-QA a una configuración Cypress existente
Si ya usa Cypress y quiere añadir Delta-QA, esto es lo que implica en concreto.
Delta-QA funciona de forma independiente de Cypress. No necesita modificar sus pruebas Cypress existentes. No necesita instalar un plugin. No necesita tocar su configuración de Cypress. Las dos herramientas coexisten sin conflicto porque no comparten nada.
La puesta en marcha de Delta-QA consiste en abrir su sitio y recorrer los escenarios que quiere cubrir. La primera pasada establece las referencias. Eso es todo: la cobertura visual está activa, independientemente de sus pruebas Cypress.
Para ir más lejos en la CI, Delta-QA cuenta ahora con un SDK, Vision. Hoy cubre Playwright, en TypeScript y JavaScript; la compatibilidad con Cypress está prevista después. Con Playwright basta una línea por página a verificar: una diferencia no revisada hace fallar la prueba, y el log de la CI ofrece el enlace al informe.
FAQ
¿Añadirá Cypress algún día pruebas visuales nativas?
Es una pregunta recurrente en la comunidad de Cypress. A 10/2026, la documentación indica que Cypress no compara imágenes por sí mismo y remite a plugins. Cypress Cloud se enriquece (Test Replay, UI Coverage, Accessibility, funciones de IA como cy.prompt()), pero sin comparación visual con una referencia. Y aunque Cypress la añadiera, seguiría acoplada a la ejecución de las pruebas funcionales: lo que mantendría el problema de cobertura acoplada descrito más arriba.
¿No bastan los plugins visuales de Cypress? Para un uso básico, pueden salvar del apuro. Pero añaden una dependencia de un servicio de terceros (con su propio coste de licencia), acoplan la cobertura visual a la cobertura funcional y su mantenimiento supone una carga adicional. Si tiene 10 páginas y un desarrollador disponible para mantener el plugin, puede funcionar. Si tiene 100 páginas y un equipo QA mixto, las limitaciones se vuelven bloqueantes.
¿Puede Delta-QA detectar bugs que Cypress no detecta? Sí, por definición. Cypress verifica aserciones programáticas: «este elemento contiene este texto», «esta URL es correcta», «esta petición devolvió un 200». Delta-QA verifica el aspecto visual: «esta página se ve idéntica a la versión de referencia». Los bugs visuales (regresiones de CSS, problemas de responsive, conflictos de z-index, fuentes ausentes) son invisibles para las aserciones de Cypress, pero Delta-QA los detecta.
¿Delta-QA ralentiza el pipeline CI/CD? Sus escenarios de Delta-QA grabados sin código no pasan por su pipeline Cypress: no lo ralentizan. Para una integración en la CI, el SDK Vision cubre hoy Playwright; Cypress está previsto después.
¿Hay que elegir entre Cypress Cloud y Delta-QA? No. Sirven objetivos distintos. Cypress Cloud optimiza sus pruebas funcionales de Cypress: paralelización, reproducción de fallos, detección de pruebas inestables (flaky), cobertura de interfaz y accesibilidad. Delta-QA cubre la comparación visual con una referencia, que Cypress Cloud no aborda. Ambas son inversiones complementarias.
Mi equipo QA no es técnico. ¿Puede usar Delta-QA sin ayuda de un desarrollador? Es precisamente el caso de uso para el que se diseñó Delta-QA. La interfaz sin código permite a un tester QA, un diseñador o un product owner configurar, lanzar e interpretar las pruebas visuales sin ninguna competencia de desarrollo. Es uno de los diferenciadores fundamentales frente a un plugin de Cypress, que requiere modificar código JavaScript para añadir puntos de captura visual.
¿Se puede usar Delta-QA con otro framework distinto de Cypress? Sí. Los escenarios de Delta-QA son independientes de cualquier framework de pruebas: ya use Cypress, Playwright, Selenium, TestCafe o ninguno, funcionan igual. Y para los equipos Playwright, el SDK Vision permite añadir una verificación de Delta-QA en una prueba existente.
Conclusión: no deje que Cypress cargue con un fardo que no es suyo
Cypress es una herramienta notable para lo que hace. Pero pedirle que cubra las pruebas visuales (mediante plugins, hacks o aserciones CSS apañadas) es imponerle una misión para la que no fue concebido. Es como equipar a un velocista con una mochila de 20 kilos y sorprenderse de que sea menos rápido.
Libere a Cypress. Déjelo hacer lo que mejor sabe: probar que su aplicación funciona. Y confíe la prueba visual a una herramienta diseñada para ello.
¿Listo para cubrir el punto ciego visual de su suite de pruebas? Lance su primera comparación con Delta-QA, con una cuenta gratuita y sin tarjeta bancaria. Probar Delta-QA gratis →