Pruebas de regresión visual en el flujo de CI: así entra el layout en la pipeline

Los equipos de desarrollo modernos confían en su pipeline de integración continua: cada push lanza una build, los tests unitarios se ejecutan, el linter comprueba el estilo y solo cuando todo está en verde el código pasa a la rama principal. Esta red de seguridad tiene, sin embargo, un punto ciego. La pipeline clásica no comprueba si la web, después del cambio, sigue teniendo el aspecto que debe tener. Una refactorización de CSS puede superar todos los tests y aun así empujar el formulario de contacto detrás del footer.

La razón está en la naturaleza de los tipos de test habituales. Los tests unitarios comprueban funciones contra valores de retorno esperados; los tests de integración, la interacción entre componentes; los tests end-to-end recorren flujos a golpe de clic y verifican que determinados elementos están presentes. Ninguno de estos enfoques ve la página como la ve una persona: como imagen renderizada. Un botón puede existir técnicamente, ser clicable y estar correctamente etiquetado — y aun así permanecer invisible en blanco sobre blanco.

Cómo surgen esas roturas lo muestra una mirada al día a día: una actualización de dependencias arrastra una nueva versión del framework CSS que ajusta de otro modo algunos espaciados estándar. Una refactorización renombra una clase utilitaria que todavía se usa en un rincón olvidado. Se sustituye un archivo de fuente que resulta mínimamente más ancho, y una navegación salta de línea. Nada de esto lanza un error, nada de esto hace fallar la build — y cada uno de estos cambios parece completamente inofensivo en la vista de código.

Las pruebas de regresión visual cierran esa brecha con un principio sencillo. De páginas definidas se registra un estado de referencia, la llamada baseline. Tras cada cambio se generan nuevas capturas de pantalla que una herramienta compara con esa baseline. Si la imagen actual se desvía, la comprobación salta y una persona decide: ¿cambio deseado o regresión?

La pregunta interesante para la práctica no es tanto el si como el dónde: ¿en qué punto del flujo de CI tienen su lugar estas comprobaciones? A diferencia de los tests unitarios, que trabajan directamente sobre el código fuente, las pruebas visuales necesitan una página renderizada y accesible a través de la red. Eso las desplaza al final de la cadena — allí donde ya existe una versión ejecutable de la aplicación.

Servicios como ScanU trabajan por eso sobre URL: se entrega la dirección de una página accesible y el servicio genera en unos 30 segundos capturas de pantalla en varios navegadores y clases de dispositivo — Chrome, Firefox y Safari, cada uno en vistas de móvil, tableta y escritorio. Cómo construye ScanU un ciclo de prueba de este tipo paso a paso lo describe el propio proveedor; el patrón de fondo, sin embargo, vale para cualquier herramienta basada en URL: sin un entorno que sirva la nueva versión, no hay nada que fotografiar.

Donde esto encaja con más elegancia es en flujos con las llamadas deploy previews. Muchas plataformas de hosting construyen automáticamente, para cada pull request, un entorno de vista previa propio con dirección propia. Exactamente esa dirección es el punto de partida natural para la comparación visual: la vista previa muestra el estado tras el cambio; la baseline, el estado aprobado anterior. Si la comparación señala una desviación, todos los implicados ven el problema antes de que el código llegue a la rama principal — y la discusión tiene lugar donde debe tenerla: en la review.

En concreto, el orden en una pipeline así queda de este modo: primero la CI construye la nueva versión, después la plataforma de hosting publica el entorno de vista previa y devuelve su dirección, y solo entonces puede arrancar el paso de comprobación visual. Justo en este punto es donde más a menudo algo falla en la práctica. Quien lanza la tanda de capturas antes de que la vista previa esté completamente servida fotografía una página cargada a medias o un mensaje de error — y luego lo compara, con toda seriedad, con la baseline. Una breve comprobación de accesibilidad de la dirección de la vista previa antes del ciclo propiamente dicho ahorra ese tipo de confusión. Cuando el informe está listo, su enlace pertenece al pull request, como comentario o en el texto de descripción, para que la valoración se produzca allí donde de todos modos se habla del cambio. Los informes compartibles, como los que genera ScanU, están pensados exactamente para ese gesto: el informe es la base común de discusión, no una ventana de herramienta que solo una persona tiene abierta.

Los equipos sin entornos de preview recurren al entorno de staging y comprueban después del merge, pero antes del despliegue a producción. Es la segunda mejor solución: las regresiones se detectan más tarde, cuando varios cambios ya se han mezclado, y la búsqueda del causante se vuelve más laboriosa. Un ciclo regular adicional contra la página de producción atrapa además cambios que ni siquiera proceden del propio código — por ejemplo, cuando un script de terceros incrustado o una actualización del CMS desplaza la apariencia.

La integración técnica es, con todo, la parte menor del trabajo. La mayor es un asunto de proceso: el cuidado de la baseline. Una baseline no es un artefacto técnico, sino un acuerdo — así debe verse la página. Quien despliega un cambio de diseño deseado debe actualizar después la baseline de forma consciente; de lo contrario, cada ejecución posterior notificará la misma desviación esperada. Quien, en cambio, la actualiza por reflejo tras cada alarma, acaba algún día declarando estado objetivo un error real.

Ha dado buen resultado tratar las actualizaciones de la baseline como cambios de código: alguien las mira, alguien las aprueba y la aprobación queda trazable. ScanU muestra para ello la baseline y el estado actual una junto al otro y genera informes compartibles. Suena poco espectacular, pero cambia la colaboración: también las compañeras y los compañeros de diseño o de gestión de producto pueden juzgar una desviación sin arrancar un entorno de desarrollo — y la decisión «deseado o roto» a menudo no es puramente técnica.

Un equipo debería aclarar además a quién pertenece la comprobación. Las pruebas visuales que no están asignadas a nadie quedan huérfanas con una fiabilidad absoluta: los informes se acumulan, nadie se siente responsable y al cabo de un mes todo el mundo los ignora. Se ha acreditado la misma regla que con las builds rotas: quien causó el cambio se ocupa de la desviación notificada, y un turno rotatorio mantiene la vista sobre las ejecuciones regulares.

A la planificación pertenece también la pregunta de con qué frecuencia se comprueba. No todo commit necesita el ciclo completo sobre todas las páginas y combinaciones de dispositivo. Modelos de facturación como el sistema de créditos de ScanU hacen tangible esta reflexión: el nivel gratuito comprende 500 créditos al mes para un proyecto; los niveles de pago van de 3000 créditos por 19 euros a 50000 créditos por 49 euros al mes. Quien hace pasar cada ejecución de la pipeline por todos los perfiles de dispositivo consume rápidamente su cuota — y genera de paso más informes de los que el equipo puede siquiera revisar.

Más sensato es un escalonado. Los pull requests con cambios en estilos o plantillas reciben la comparación sobre las páginas más importantes; una ejecución diaria o semanal cubre el conjunto más amplio en todos los navegadores; antes de una release se ejecuta todo una vez. Así la relación señal-ruido se mantiene sana y cada alarma tiene una posibilidad real de ser tomada en serio. Una prueba visual cuyas notificaciones el equipo descarta por rutina vale menos que ninguna.

Al elegir las páginas rige: plantillas en lugar de instancias. Una tienda online no necesita fotografiar 2000 páginas de producto, sino una página representativa por tipo de layout. La página de inicio, una página de producto o de artículo por plantilla, el carrito, los formularios y la página de error cubren en la mayoría de los proyectos la mayor parte del riesgo. Las páginas de alto valor de negocio — por ejemplo, el proceso de pago — merecen más combinaciones de dispositivo que el Impressum (el aviso legal).

La misma ponderación vale para los perfiles de dispositivo. Los niveles de precio de ScanU se diferencian también en el número de dispositivos disponibles — de diez en el nivel gratuito a 98 en el mayor. Eso invita a la exhaustividad, pero más perfiles significan más imágenes, más créditos y más trabajo de revisión. Más practicable es orientarse por las propias cifras de acceso: las tres o cuatro combinaciones de dispositivo por las que llega realmente la mayor parte de las visitantes y los visitantes, más un representante de cada tamaño extremo — muy estrecho, muy ancho.

Un obstáculo merece atención especial: los contenidos dinámicos. Teasers rotatorios, recomendaciones personalizadas, banners de cookies, horas insertadas o publicidad cambian la imagen en cada carga — sin regresión alguna. Estas falsas alarmas son la razón más frecuente de que los equipos vuelvan a desconectar las pruebas visuales al cabo de pocas semanas. Los antídotos son conocidos: entornos de prueba con datos de ejemplo fijos, animaciones desactivadas, estados de partida consistentes. Las falsas alarmas nunca desaparecen del todo, pero se dejan reducir a un nivel soportable.

A la honestidad pertenece también nombrar los límites. Una comparación de capturas superada no dice nada sobre si el formulario envía realmente los datos, si la búsqueda devuelve resultados o si el proceso de pago se completa. Las pruebas visuales comprueban presentación, no función — complementan los tests unitarios y end-to-end, no los sustituyen. Quien reduce su cobertura de tests funcionales en favor de las capturas cambia un riesgo por otro.

También el valor de las conclusiones depende del entorno. Las comprobaciones basadas en URL fotografían lo que sirve la dirección indicada. Si el entorno de staging difiere claramente de producción — otros datos, otras feature flags, scripts de terceros ausentes —, se está comprobando una imagen distorsionada. Y las zonas tras un login necesitan consideraciones aparte antes de que un servicio externo pueda siquiera capturarlas.

Para que la comprobación quede anclada en el equipo ayuda un trato sobrio con sus resultados. Merece la pena hacer balance de vez en cuando: ¿cuántas desviaciones notificadas eran regresiones reales, cuántas falsas alarmas, cuántos cambios deseados? Si la proporción se inclina hacia la falsa alarma, no es motivo para desconectar, sino un encargo de trabajo para el entorno de prueba. Y si la comparación sencillamente no encuentra nada durante meses, un equipo también puede reducir la frecuencia de comprobación — disciplina de testing no significa despliegue máximo, sino adecuación.

Un aspecto subestimado es el historial. Si una regresión no se detecta hasta pasados unos días, ayuda la mirada atrás: ¿cuándo se vio la página correcta por última vez, qué periodo entra en consideración como causante? ScanU conserva los historiales, según el nivel de precio, entre tres y 90 días. También eso pertenece a la planificación — un historial de tres días se agota rápido en un fin de semana largo, mientras que 90 días responden también a la pregunta de si un problema ya existía antes de la última release trimestral.

Para empezar, mucho habla a favor del comienzo pequeño: un proyecto, un puñado de páginas, una ejecución semanal más una por release. Cuando crece la confianza en las alarmas, sigue el engranaje más estrecho con la pipeline. Los detalles sobre el funcionamiento están en la documentación de ScanU; una visión general en español la ofrece la página del producto en español del proveedor.

Queda la pregunta de fondo: ¿compensa el esfuerzo? La respuesta depende menos del tamaño del equipo que de la frecuencia de cambios. Quien despliega cada semana produce cada semana ocasiones para roturas silenciosas de layout — y sin comprobación sistemática las descubre cuando las usuarias y los usuarios hace tiempo que las han visto. La pipeline de CI enseñó al día a día del desarrollo a atrapar los errores de lógica antes de la publicación. Hay pocas razones para negar esa misma protección a la capa más visible de una web.