Publique la interfaz que diseñó — no la que se coló por la CI

Las pruebas funcionales responden bien a una pregunta: «¿hace el botón lo correcto cuando se pulsa?». Son mudas sobre todo lo que ocurre antes del clic — si el botón tiene el color adecuado, el tamaño adecuado, la posición adecuada, si sigue siendo legible en una pantalla de 360 píxeles o si es siquiera visible tras la última refactorización CSS. Es en ese hueco donde viven la mayor parte de los incidentes del día de lanzamiento.

Las regresiones reales que vemos, y para atrapar las cuales ScanU está diseñado, se agrupan en torno a un puñado de desencadenantes predecibles:

• Una refactorización CSS colapsa el gap de un contenedor flex en un único breakpoint. En escritorio el layout parece idéntico; en una tableta de 768 píxeles, dos tarjetas se solapan.
• Un ajuste de design tokens mueve cada valor de espaciado dos píxeles. Nada falla; una docena de composiciones cuidadosamente equilibradas dejan de estarlo en silencio.
• Un widget de terceros — un banner de cookies, un live chat, un hueco de anuncio — publica una actualización silenciosa que desplaza el first paint. Los Core Web Vitals empeoran de la noche a la mañana sin un solo cambio de código por su parte.
• Una subida de versión del framework cambia la pila de font-features por defecto. El texto se reflúja media línea en las páginas largas. Los CTA del hero caen de pronto bajo la línea de flotación.
• Un rollout con feature flag reordena el DOM. En Safari, el stacking context de una modal cambia y el botón de cerrar se vuelve no clicable. En Chrome todo parece normal.

Ninguno de esos cambios hace fallar una aserción. Todos rompen la experiencia de un usuario. El trabajo de ScanU es hacer que este segundo tipo de fallo sea tan fácil de ver, revisar y bloquear como una prueba unitaria en rojo. Cuando el diff aparece en la pull request, una diseñadora puede opinar igual que un reviewer opina sobre una firma de función — antes de mergear, no después de que llegue a producción.

Ese cambio — pasar de «esperemos que alguien lo note en staging» a «revisemos un cambio visual como revisamos un cambio de código» — es el valor central de una herramienta de regresión visual en una pipeline de entrega moderna.

Cada ejecución es una pipeline de tres pasos. Primero ScanU navega en cada motor hasta la página o el componente bajo prueba, espera un conjunto configurado de señales de readiness — tipografías cargadas, imágenes decodificadas, red en silencio, un atributo data-ready o una sonda JavaScript personalizada — y fija todas las animaciones CSS en su frame final. Después captura la página en cada viewport configurado en la misma ejecución, con scroll-stitching para páginas largas, de modo que obtenga el artefacto completo y no solo el trozo visible. Por último compara la captura con la baseline aceptada y produce un resultado por par (navegador, viewport): idéntico, dentro de la tolerancia o significativamente distinto.

La comparación en sí no es un diff ingenuo de píxeles. ScanU aplica un modelo perceptual que entiende el anti-aliasing, el renderizado sub-pixel y los pequeños cambios de espacio de color, para que una peculiaridad de kerning en WebKit no se disfrace de bug. También admite máscaras explícitas para las zonas que usted sabe que cambiarán en cada carga — datos en vivo, marcas de tiempo relativas, contenido aleatorizado, carruseles — de forma que esas áreas aporten cero ruido al diff.

Cuando aparece un cambio real, la plataforma muestra tres paneles sincronizados: la baseline, la captura actual y un overlay de diff que resalta exactamente lo que se movió. Una única decisión revisable — aceptar, rechazar o actualizar la baseline — se registra para cada cambio, y esa decisión pasa a formar parte de la historia del proyecto. No hay deriva silenciosa ni aceptación automática: la baseline solo se mueve cuando una persona autorizada lo decide.

La misma pipeline se puede invocar desde tres puntos de entrada: contra URLs en vivo (producción, staging, previsualizaciones de PR), contra un sitio estático o un bundle construido, o contra previsualizaciones de componentes en un sandbox estilo Storybook. La mayor parte de los equipos usa la primera vía como release gate, la segunda para artefactos de despliegue y la tercera para el trabajo en design system — las tres alimentan el mismo almacén de baselines.

Sea cual sea la forma del equipo, ScanU se suele adoptar por una de cinco razones: un incidente reciente en producción que una regresión visual habría atrapado; una migración de design system cuyo radio de impacto es imposible de auditar a mano; un flujo CI/CD que necesita un release gate más rico que «pruebas en verde»; un entregable orientado al cliente que requiere evidencia antes/después; o una postura de compliance que prefiere herramientas de test alojadas en la UE. Una integración CI/CD común está detrás de las cinco — la misma pipeline hace el trabajo, la dispare una PR, un merge o una planificación nocturna.

ScanU está construido y alojado en la Unión Europea, con almacenamiento y procesamiento en infraestructura operada en la UE. Para equipos con compromisos de residencia de datos — sectores regulados, compradores públicos, clientes B2B sensibles a la privacidad — a menudo es un requisito de compras, no una preferencia. ScanU está diseñado para satisfacerlo sin ceder en capacidades de producto.

De esa postura se derivan algunas decisiones deliberadas de diseño:

• Minimización de datos. La plataforma almacena capturas y los metadatos necesarios para hacer el diff; no absorbe el código fuente de la página, cookies ni cuerpos de petición que no contribuyan al diff.
• Enmascaramiento por defecto en contextos sensibles. Los campos conocidos por contener datos personales — cabeceras de cuenta, direcciones de email, números de pedido — pueden declararse como regiones enmascaradas, de modo que la imagen capturada ya esté redactada cuando se escribe en el almacenamiento.
• Control de acceso. Quién puede ver un diff es un permiso de primera clase. Revisores, colaboradores y auditores externos reciben roles explícitos, y cada actualización de baseline queda registrada con la persona que la autorizó.
• Transparencia sobre subencargados. La lista de subencargados está publicada y versionada. No hay ningún pipeline de analítica oculto que vea sus capturas.
• Retención que usted controla. Baselines y artefactos de diff se conservan durante el horizonte que configure; las ejecuciones antiguas expiran automáticamente en lugar de acumularse en silencio.

Para la postura de privacidad completa — subencargados, alojamiento regional, DPA, ventanas de retención — consulte la documentación sobre RGPD y tratamiento de datos. Para la mayoría de los equipos, la versión corta es suficiente: sus capturas se quedan en la UE, y la plataforma está construida para que se queden ahí.

Los bugs visuales se agrupan en un puñado de patrones recurrentes. Cada uno parece trivial de forma aislada; cada uno puede llegar a producción sin una sola prueba en rojo. Todos salen a la luz como diff en la próxima ejecución de ScanU, antes de que la PR se mergee.

• Desplazamientos de espaciado. Una utilidad de gap sube de 16 a 20 píxeles; una rejilla de tarjetas que respiraba con soltura se ve de pronto apretada en móvil. El HTML no ha cambiado; el layout sí.
• Layouts rotos tras el despliegue. Una actualización del pipeline de build deja fuera un plugin de PostCSS que se encargaba de autoprefijar backdrop-filter. En Safari una barra de navegación aparece de repente opaca donde antes difuminaba.
• Regresiones CSS por cambios de especificidad. Un cambio de orden en clases de Tailwind, una nueva capa de utilidades o una cascada refactorizada alteran sutilmente qué regla gana — un encabezado pierde su color de acento en unas cuantas páginas.
• Breakpoints responsive que fallan. Un nuevo ítem de nav se desborda en el breakpoint de tableta y pasa a una segunda línea, empujando el hero por debajo de la línea de flotación en iPads y en Android grandes.
• Diferencias de renderizado entre navegadores. Un diseño que confía en text-wrap: balance luce nítido en Chrome pero sigue desequilibrado en motores que aún no lo han publicado. Sin un check cross-browser es invisible en la máquina de quien desarrolla.
• Deriva de tipografía y fuentes. Un proveedor de fuentes cambia un subset, los pesos se corren cien gramos, y cada párrafo de un sitio de marketing se reflúja un cuarto de línea. La densidad del texto cambia; ningún diff en el repositorio lo explica.
• Regresiones de widgets de terceros. Un proveedor de banner de consentimiento publica una actualización que deja invisible el botón de aceptar en temas oscuros. Su tasa de conversión cae; sus pruebas pasan.
• Deriva del design system. Un componente de botón cambia el offset de su anillo de foco. Veinte consumidores dependen de ese componente. Veinte páginas quedan ahora sutilmente distintas. Nadie revisa veinte páginas a mano.
• Bugs visuales que se escapan a producción. Cualquiera de los anteriores, multiplicado por las rutas y breakpoints que nadie abre en una semana dada, a través de los navegadores que nadie del equipo usa a diario.

La descripción de funcionalidades repasa las primitivas de detección con más detalle — tolerancias perceptuales, regiones enmascaradas, captura por scroll, branching de baseline — y muestra cómo cada una se corresponde con una de las categorías anteriores. Para la mayoría de los equipos la versión corta es: si algo cambia visualmente, ScanU lo detecta; si es esperado, lo acepta con un clic; si no, lo ha atrapado antes que nadie.