Diffs de capturas en la práctica: baselines, umbrales y falsas alarmas

Sobre el papel, una prueba visual es el tipo de test más sencillo del mundo: dos imágenes, una comparación, listo. Quien lo prueba nota enseguida que entre «comparar dos imágenes» y «saber con fiabilidad si la web está rota» media todo un oficio. Ese oficio tiene tres conceptos centrales — baseline, umbral, falsa alarma — y quien los entiende entiende también por qué las pruebas visuales son imprescindibles en unos equipos y en otros se vuelven a desconectar al cabo de tres semanas.

Al principio está la baseline: un juego de capturas de pantalla que fija el estado deseado de la página. Importa lo que la baseline significa — y lo que no. No es una medida objetiva de corrección, sino una instantánea que alguien ha declarado estado objetivo. Un diff contra la baseline nunca dice, por eso, «la página está rota», sino solo «la página es distinta del estado aprobado». Si distinto significa también peor, ningún algoritmo puede decidirlo.

La comparación en sí trabaja, en su principio básico, píxel a píxel: para cada posición de la imagen se determina la desviación de color entre la baseline y la captura actual; la suma de las desviaciones da una medida del cambio. Este principio básico es robusto y rápido — y tiene una debilidad incorporada: trata igual toda desviación, da lo mismo que haya desaparecido un botón del carrito o que una fuente se haya suavizado de forma mínimamente distinta.

Justo de ahí procede el mayor problema práctico de las pruebas visuales: el ruido. El suavizado de fuentes varía según el sistema y la pasada de renderizado. Los bordes se dibujan unas veces un subpíxel antes, otras después. Las imágenes atraviesan compresión que genera desviaciones mínimas de color. Nada de eso es una regresión — pero todo eso genera diferencias de píxeles. Una comparación ingenua, que dé la alarma con cada píxel desviado, notifica por eso prácticamente siempre algo.

La segunda fuente de ruido son los propios contenidos. Una hora insertada cambia con cada carga. Un carrusel nunca está dos veces en la misma imagen. Los espacios publicitarios entregan motivos cambiantes; las franjas de recomendaciones, productos cambiantes; un banner de cookies aparece unas veces antes y otras después de la captura. Quien fotografía una web de noticias por la mañana y al mediodía obtiene dos imágenes completamente distintas — y ambas son correctas.

La herramienta contra el ruido se llama umbral: solo cuando la desviación supera una medida definida, la comparación se considera llamativa. Con ello empieza una ponderación que no se deja optimizar hasta desaparecer. Un umbral estricto notifica cada nimiedad y genera fatiga de alarmas; uno generoso pasa por alto errores reales — un precio descolocado puede quedarse por debajo del umbral si solo afecta a unos pocos píxeles. El único valor correcto no existe; existe solo el valor adecuado para una página determinada y un equipo determinado.

Para fijarlo hay, al menos, un procedimiento tangible: medir el propio ruido. Para ello se fotografía la misma página dos veces, una inmediatamente después de la otra, sin cambiar nada, y se comparan ambas tomas entre sí. Toda diferencia que esa comparación notifique es, por definición, ruido — suavizado de fuentes, compresión, timing. Quien repite esta medición para las páginas y combinaciones de dispositivo más importantes conoce el nivel de base de su propio entorno de prueba y puede fijar el umbral justo por encima, en lugar de adivinarlo. El procedimiento entrega, de paso, una señal de alerta temprana: si el nivel de base así medido sube después de forma notable, el entorno se ha vuelto más inquieto — y merece la pena perseguir la causa antes de que las alarmas pierdan su credibilidad.

La fatiga de alarmas no es aquí un tema blando y secundario, sino la estocada mortal más frecuente para las pruebas visuales. Un sistema de comprobación que salta tres veces al día sin motivo, al cabo de dos semanas ya no lo toma nadie en serio — y entonces la alarma que de verdad notifica una página de pago rota es solo una más de tantas que se descartan por rutina. Una prueba visual en la que el equipo no confía es peor que ninguna, porque finge una seguridad que no proporciona.

Por eso compensa trabajar en las condiciones de contorno antes de tocar el umbral. Se han acreditado los datos de ejemplo fijos en lugar de datos en vivo en los entornos de prueba, las animaciones desactivadas, los estados de partida consistentes — por ejemplo, un diálogo de cookies ya respondido —, los tiempos de espera suficientes hasta la carga completa y los tamaños de ventana idénticos en cada pasada. Las indicaciones específicas de cada herramienta al respecto pertenecen a toda implantación; para el servicio aquí considerado las reúne la documentación de ScanU en la web del proveedor. Cada una de estas medidas elimina una fuente de ruido — y hace menos importante el umbral, porque las alarmas verdaderas y las falsas se separan con más claridad.

Para las fuentes de ruido tenaces — el espacio publicitario, la fecha en vivo, la zona con comentarios de usuarios — algunas herramientas ofrecen además la posibilidad de excluir zonas de la imagen de la comparación. Es eficaz, pero tiene un precio que conviene conocer: una zona excluida es un punto ciego. Justo ahí puede pasar en el futuro cualquier cosa sin que nadie lo notifique. La ponderación no es, por eso, «excluir o soportar falsas alarmas», sino: ¿es esta zona lo bastante importante como para querer enterarse de sus cambios? Para un banner publicitario rotatorio la respuesta suele ser no; para una columna de precios, siempre sí. Las zonas de exclusión definidas deben además documentarse y revisarse de vez en cuando — si no, se acumulan manchas silenciosas y la comprobación cubre menos de lo que todos los implicados creen.

Una decisión emparentada afecta al encuadre. Una toma de la zona visible de la ventana comprueba lo que las visitantes y los visitantes ven sin hacer scroll — rápida y económica, pero ciega para todo lo de debajo. Una toma de la página a lo largo completo lo captura todo, pero reacciona con más sensibilidad: si un elemento de la zona superior crece veinte píxeles, todo el resto de la página se desplaza hacia abajo y la comparación marca superficies que en contenido no han cambiado en absoluto. Para páginas compactas y estables, el largo completo suele ser la elección correcta; en páginas muy largas y vivas puede ser más inteligente comprobar selectivamente las secciones críticas. Tampoco esto es una minucia técnica, sino una decisión sobre qué errores se quieren ver — y cuáles se aceptan conscientemente.

El segundo gran tema metodológico es el cuidado de la baseline a lo largo del tiempo. Las webs cambian a propósito: rediseños, contenidos nuevos, campañas de temporada. Tras cada cambio deseado hay que poner al día la baseline; si no, cada pasada futura notificará la misma diferencia esperada. El peligro está en la rutina: quien entiende las actualizaciones de la baseline como un clic molesto acaba actualizando por reflejo — y con ello, tarde o temprano, declara nuevo estado objetivo un error real. A partir de ahí, cada pasada en verde confirma la versión rota.

Contra eso ayuda un principio sencillo: las actualizaciones de la baseline son aprobaciones y merecen el mismo cuidado que una code review. Alguien se mira la diferencia, alguien decide conscientemente, alguien puede reconstruir después la decisión. Las herramientas lo apoyan con desigual fortuna; ScanU, por ejemplo, muestra la baseline y el estado actual una junto al otro y genera informes compartibles, de modo que también los no técnicos pueden juzgar una desviación — qué funciones de comparación están disponibles en detalle lo muestra la página de funciones del servicio. El principio, sin embargo, es independiente de la herramienta: la aprobación de una baseline es una decisión de contenido, no técnica.

Una dimensión se escamotea con gusto en los textos introductorios: el tiempo. Las regresiones no siempre se notan de inmediato. Entonces empieza la búsqueda: ¿desde cuándo es así? ¿Qué cambio entra en consideración? Aquí rinde el historial — la posibilidad de consultar estados antiguos y acotar el momento del cambio. En ScanU, la conservación depende del nivel de precio, de tres días en el nivel gratuito a 90 días en el mayor. Para la metodología significa: quien comprueba solo rara vez necesita historiales que lleguen más atrás; quien comprueba a diario acota bien los periodos incluso con un historial corto.

Queda el límite más fundamental del procedimiento: la brecha semántica. Una comparación de píxeles no sabe qué compara. Dos píxeles de desplazamiento en un botón de pago pueden ser síntoma de una retícula de layout rota; veinte píxeles de desplazamiento en un pie de página son casi siempre irrelevantes. El diff no conoce la diferencia — mide superficie, no significado. La última palabra la tiene por eso siempre una persona que conoce la página y puede clasificar qué desviación tiene relevancia de negocio.

Y, por último, lo que un diff de capturas por principio no puede ver: todo lo que no se plasma en la imagen. Una página puede verse impecable y aun así mostrar datos falsos; un formulario puede estar perfectamente renderizado y fracasar al enviarse; un servidor puede entregar correctamente contenidos obsoletos. Las pruebas visuales son una capa en el entramado de tests — junto a los tests funcionales, la monitorización y la curiosidad humana ocasional —, no su sustituto.

Cómo encajan las piezas sueltas lo muestra un ejemplo jugado de principio a fin — no un caso de estudio, sino una secuencia típica. Semana uno: un equipo crea baselines para diez páginas y a la mañana siguiente se encuentra decenas de desviaciones notificadas. La revisión muestra que casi todas se remontan a un carrusel y al diálogo de cookies. Semana dos: calmar el entorno de prueba — datos de ejemplo fijos, estado de partida definido, animaciones fuera; las pasadas enmudecen. Semana tres: una actualización de dependencias desplaza en uno de los tres motores los espaciados de la navegación — el primer hallazgo real, que antes nadie habría notado, porque en el día a día nadie abre rutinariamente todos los motores. Semana cuatro: un rediseño de la página de inicio genera diferencias esperadas en todas las vistas; tras la revisión, la baseline se actualiza conscientemente. Nada en esta secuencia es espectacular — y justo ahí está el punto. El valor no nace de hallazgos dramáticos, sino del paso de «probablemente todo se ve bien» a un comprobado «desde el último estado aprobado no ha cambiado nada indeseado». Cómo transcurre técnicamente una pasada de comprobación concreta lo muestra la presentación paso a paso de ScanU.

Quien quiera empezar va bien servido con un orden sencillo: primero definir un conjunto pequeño de páginas importantes, luego calmar el entorno de prueba, luego generar las baselines y acordar en el equipo quién juzga y aprueba las desviaciones — y solo después negociar sobre umbrales y frecuencia de comprobación. Una introducción al tema en español la ofrece el panorama de ScanU en español; la metodología de fondo vale para cualquier herramienta de este género. Porque esa es, al final, la idea central: el valor de las pruebas visuales no nace en el algoritmo que compara píxeles, sino en el procedimiento de alrededor — referencias limpias, umbrales honestos y personas que juzgan las diferencias en lugar de descartarlas con un clic.