Cuando un botón de pago cambia de color, la mayoría de tus pruebas de software siguen en verde. Porque las pruebas verifican que el botón existe, no que se vea bien. Lo que hay en pantalla es color, posición, tipografía y espacio en blanco, y lo único que el software conoce con certeza es el DOM.
La regresión visual cubre esa distancia: toma una captura de una página, la compara con una imagen de referencia, encuentra la diferencia y te la señala.
En este artículo explicamos qué hace realmente la técnica, dónde compensa su coste, cuáles son los métodos habituales y —lo más útil— dónde no conviene usarla. Porque no es una herramienta que se añada a cualquier proyecto, y colocarla en el sitio equivocado produce ruido durante semanas.
Por qué las pruebas del DOM no bastan
La mayoría de las pruebas verifican que un elemento está presente:
expect(page.locator('[data-testid="checkout-button"]')).toBeVisible()
Esa prueba pasa aunque todo lo siguiente sea cierto:
- El botón se ha salido de la pantalla (el desbordamiento no rompe la visibilidad)
- Otra capa está encima (no se puede pulsar, pero sigue siendo "visible")
- El color de fondo ha bajado del umbral de contraste
- La fuente no cargó y se ha renderizado con una alternativa
- Los elementos se solapan en móvil
Nada de esto rompe una prueba del DOM. La regresión visual sí, porque compara lo que la página muestra de verdad.
Cómo funciona, en cuatro pasos
1. Capturar una referencia. La página se guarda en un estado conocido como bueno. Esa es la referencia.
2. Volver a capturar. La misma página, mismo navegador, mismo tamaño de ventana, mismas condiciones de espera.
3. Calcular la diferencia de píxeles. Se comparan las dos imágenes y la herramienta indica qué píxeles cambiaron y cuánto.
4. Aplicar un umbral. Las diferencias pequeñas se ignoran; las grandes rompen la integración.
La parte difícil es el paso cuatro. Si el umbral es demasiado laxo, se escapan fallos reales; si es demasiado estricto, cada recarga genera una prueba rota. Las animaciones, los relojes, el contenido aleatorio y la carga de fuentes se enmascaran justo por eso.
Los métodos habituales
Diferencia de píxeles. Las imágenes se comparan píxel a píxel. Simple y rápido, pero frágil ante desplazamientos pequeños: mueve un elemento un píxel y la prueba falla.
Hash perceptual. La imagen se reduce a un resumen numérico que aproxima la percepción humana y se comparan dos números. Mucho más tolerante a los desplazamientos; puede pasar por alto cambios pequeños pero significativos.
Similitud estructural (SSIM). Mide cuánto se parecen estructuralmente dos imágenes. Importa más la disposición que el color. Más estable cuando las pruebas se rompen porque el texto se ha movido.
DOM y visual juntos. Muchos equipos los combinan: las pruebas del DOM dan respuesta rápida, las visuales verifican a fondo. El coste es la suma de ambas.
Dónde compensa de verdad
- Cambios en el sistema de diseño. Una actualización de un componente puede afectar a cuarenta páginas. Revisar cuarenta páginas a mano no ocurre en la práctica.
- Recorridos de conversión con tráfico. Pago, registro, carrito. Una rotura ahí es directamente ingresos.
- Consistencia entre navegadores y tamaños. Cómo se ve la misma página en distintos anchos.
- Contenido corporativo. Tablas de precios, textos legales, imágenes de campaña.
Dónde no:
- Pantallas CRUD sencillas con texto plano y fondos lisos. El coste supera la tasa de fallos que realmente vas a detectar.
- Contenido personal que cambia constantemente. Una fecha, un contador o un espacio publicitario rompen la prueba en cada ejecución, el equipo aprende a ignorarla, y eso es peor que no tener prueba.
- Revisiones puntuales antes de publicar. Abrir un navegador es más rápido.
Un uso distinto para sitios en producción
Todo lo anterior es prueba previa a la publicación: verificar lo que produce tu código.
Una agencia o el dueño de un sitio tiene otro problema: vigilar el sitio publicado desde fuera. Nadie lo está probando y nadie escribió el código. Un cambio de CSS oculta un elemento, el servidor falla, un formulario deja de enviarse.
Eso es regresión visual ejecutada desde fuera. La misma comparación, salvo que tú guardas la imagen de referencia y la comparación se ejecuta sola.
La diferencia práctica para una agencia: revisar a mano treinta sitios de clientes cada día no es posible. Automatizado, "algo ha cambiado en tu web" te llega antes de que el cliente tenga que preguntar.
Errores frecuentes
Ajustar el umbral demasiado estricto. Las pruebas se rompen, el equipo aprende a tratarlas como ruido y acaba dejando de mirarlas. Una prueba rota es peor que no tenerla.
Omitir las máscaras. Si el reloj, la fecha y el hueco publicitario no se enmascaran, falla cada ejecución. Empezar sin máscaras es más difícil que añadirlas después.
Un número de pruebas sin límite. Escribir una prueba por página en lugar de por recorrido de usuario exige mantenimiento constante y no detecta nada adicional.
No fijar el tamaño de ventana. Si la prueba pasa a 1280px, no sabes nada de lo que pasa a 375px.
Resumen
- La regresión visual cubre lo que el DOM no puede ver: la apariencia real.
- Su mayor victoria es detectar cambios que una sola persona no puede revisar a mano.
- La diferencia de píxeles es rápida pero frágil; el hash perceptual y el SSIM toleran mejor los desplazamientos.
- Una prueba mal colocada es peor que ninguna: produce ruido y ciega al equipo.
- Vigilar sitios en producción usa la misma técnica, ejecutada por una herramienta externa.
Los pasos de configuración están en nuestra documentación técnica, y puedes comparar planes o empezar gratis.