Lista de verificación de pruebas de regresión visual que su equipo de control de calidad realmente necesita

Tus pruebas funcionales son correctas. Las pruebas unitarias se superan. Implementas el viernes. El lunes por la mañana, la cola de soporte está colapsada: la página de precios no funciona en Safari, el botón de pago se oculta tras un banner promocional en dispositivos móviles y la ventana modal de configuración se cierra inesperadamente en tabletas.

Todas las pruebas se superaron. Nadie se fijó en cómo quedó la página después del cambio.

Esa brecha entre “funciona correctamente” y “se ve bien” es precisamente lo que las pruebas de regresión visual buscan cerrar. Comparan capturas de pantalla de la interfaz de usuario antes y después de los cambios en el código y señalan las diferencias: cambios en el diseño, discrepancias de color, vistas responsivas defectuosas, problemas con el índice z.

Los fallos visuales son uno de los problemas de calidad más insidiosos, ya que no generan errores ni hacen fallar ninguna prueba. Simplemente erosionan silenciosamente la confianza del usuario, reducen drásticamente las tasas de conversión y generan incidencias de soporte que nadie puede reproducir desde un punto de vista funcional.

Esta lista de verificación se basa en nuestra experiencia probando más de 300 productos, incluyendo aplicaciones con más de 600 integraciones en tres plataformas de escritorio. Sin fines comerciales. Simplemente lo que funciona.

Lo que detectan las pruebas de regresión visual (y que no detectan las pruebas funcionales)

Las pruebas funcionales verifican el comportamiento. Al hacer clic en un botón, ¿sucede lo esperado? Las pruebas visuales plantean una pregunta diferente: ¿la página se ve bien después de que ocurre esa acción?

Esto es lo que siempre se escapa a las pruebas funcionales:

• Cambios en el diseño. Una refactorización CSS en un componente compartido rompe silenciosamente el margen de todas las etiquetas de formulario en 40 páginas. Los formularios se siguen enviando. Las pruebas pasan. Los usuarios ven un desastre.
• Problemas de visualización entre navegadores. Un diseño que se ve perfecto en Chrome se distorsiona en Safari. Una fuente se muestra 2 píxeles más alta en Windows que en macOS, lo que hace que un botón de llamada a la acción quede fuera del área visible de la pantalla.
• Problemas de superposición y de índice Z. Existe un botón, se puede hacer clic en él y devuelve la respuesta correcta, pero es invisible detrás de otro elemento. Las pruebas funcionales lo detectan, pero los usuarios no.
• Puntos de interrupción adaptables. Una cuadrícula de tarjetas funciona correctamente a 1440 px, pero se apila incorrectamente a 768 px. Ninguna prueba lo detecta a menos que se tomen capturas de pantalla en múltiples tamaños de pantalla.

Lo comprobamos de primera mano al trabajar con Station, una aplicación de escritorio que unificaba más de 670 aplicaciones web en una sola interfaz. Con más de 600 integraciones en Windows, macOS y Ubuntu, la coherencia visual era un desafío diario. Cada nueva integración conllevaba el riesgo de generar problemas visuales, por lo que realizamos pruebas de regresión completas en las tres plataformas en plazos muy ajustados de uno o dos días. La conclusión: sin comprobaciones visuales sistemáticas, las regresiones se cuelan más rápido de lo que se pueden escribir los casos de prueba.

Cuándo las pruebas de regresión visual son excesivas: Si te encuentras en una fase muy temprana de desarrollo de un producto mínimo viable (MVP), donde la interfaz de usuario cambia a diario, o si tienes un sitio web de marketing estático que se actualiza dos veces al año, el coste de mantener las líneas base podría no compensar. Sinceramente, a veces una comprobación manual puntual es más rápida.

La lista de verificación

A continuación, presentamos la lista de verificación que hemos perfeccionado a lo largo de cientos de proyectos. Cubre específicamente la capa visual; si necesita una visión completa que incluya comprobaciones funcionales, de rendimiento y de seguridad, nuestra lista de verificación para pruebas de sitios web le será de gran utilidad. Está organizada en cuatro fases: configuración, ejecución de pruebas, integración de CI/CD y gestión de falsos positivos. Adáptela a su infraestructura tecnológica: los principios son independientes de las herramientas.

Configuración y línea base

Antes de escribir una sola prueba visual, asegúrese de tener una base sólida. Saltarse esta fase es la razón por la que la mayoría de los equipos abandonan las pruebas visuales automatizadas en un plazo de tres meses.

1. Primero, define el alcance. No intentes capturar todo el contenido el primer día. Empieza con 5 a 10 páginas con mayor tráfico y flujos de usuario clave (inicio de sesión, pago, panel de control). Amplía el alcance una vez que tu equipo se familiarice con el flujo de trabajo de revisión.
2. Elige tu método de comparación. Existen tres opciones: comparación píxel a píxel (detecta todo, pero genera ruido), comparación basada en DOM (estructural, pero no detecta cambios sutiles de color) y comparación con IA (filtrado inteligente, pero tiene un coste). Para la mayoría de los equipos en 2026, la comparación con IA es la opción más adecuada.
3. Elige tu herramienta. Más información a continuación, pero en resumen: Playwright utiliza la función integrada toHaveScreenshot() para equipos que buscan una solución gratuita y rápida. Percy o Applitools son ideales para equipos que necesitan escalabilidad y análisis de diferencias mediante IA.
4. Bloquea tu entorno de prueba. Ejecuta pruebas visuales dentro de un contenedor Docker o una máquina virtual de integración continua dedicada. La representación de fuentes varía entre Windows, macOS y Linux; si tu entorno no es estable, cada ejecución de prueba generará ruido. Tamaños de ventana gráfica fijos, fuentes consistentes, renderizado de GPU desactivado.
5. Captura imágenes de referencia nítidas. Desactiva las animaciones. Utiliza datos de prueba deterministas (sin avatares de usuario aleatorios ni marcas de tiempo en tiempo real). Una captura de pantalla de referencia con contenido dinámico es una referencia engañosa.

Redacción y ejecución de pruebas visuales

En esta fase, la mayoría de los equipos o bien construyen algo que se pueda mantener o bien crean un desastre frágil que abandonarán en dos sprints.

• Nombra las capturas de pantalla de forma descriptiva. Por ejemplo, checkout-desktop-1440.png, no test1.png. Cuando una diferencia falla en una revisión de solicitud de extracción, el nombre por sí solo debería indicar qué falló y dónde.
• Enmascara el contenido dinámico desde el primer día. Crea una configuración compartida de selectores para excluir en todas las pruebas: marcas de tiempo, avatares de usuario, anuncios, contadores de datos en tiempo real y widgets de chat. Cada elemento dinámico sin enmascarar es un falso positivo que hará perder el tiempo a tu revisor.
• Desactive las animaciones y transiciones CSS antes de la captura. Una captura tomada durante una animación provocará un error en la siguiente ejecución sin motivo aparente.
• Establece umbrales de fallo por componente. Una diferencia de píxeles del 0,01 % en tu página de pago merece ser investigada. ¿La misma diferencia en una entrada de blog? Probablemente se deba al suavizado de bordes. Ajusta los umbrales según la criticidad, no de forma global.
• Realice pruebas en al menos dos navegadores y tres tamaños de pantalla. Chrome y Safari presentan las mayores diferencias en el motor de renderizado (Blink frente a WebKit). Para los tamaños de pantalla: 375 px (móvil), 768 px (tableta), 1440 px (ordenador). Esto no es un extra, ya que las pruebas visuales en varios navegadores detectan errores que las pruebas en un solo navegador pasan por alto sistemáticamente.

¿Necesitas pruebas de compatibilidad más exhaustivas? Eso requiere un conocimiento especializado. Y si tu producto está dirigido a usuarios con discapacidades, considera también realizar pruebas con fuentes grandes y temas de alto contraste; nuestra lista de verificación de accesibilidad móvil lo explica paso a paso.

Integración de CI/CD

Las pruebas visuales deben formar parte de tu flujo de trabajo, no estar en la terminal local de alguien. El ecosistema para las pruebas visuales de CI/CD está consolidado. Úsalo.

Realiza pruebas de regresión visual en cada solicitud de extracción. No todas las noches. Ni todas las semanas. En cada solicitud de extracción. Revisar las diferencias en una solicitud de extracción cuesta cinco minutos. Depurar un error visual en producción cuesta un día completo de sprint, además de la pérdida de confianza del cliente.

Separe las pruebas visuales de las pruebas funcionales. Las pruebas visuales son más lentas, ya que capturan capturas de pantalla, suben las diferencias y esperan a que se completen las comparaciones. No permita que bloqueen el ciclo de retroalimentación de sus pruebas funcionales. Ejecútelas en un proceso de integración continua (CI) paralelo.

Almacena las diferencias visuales como artefactos de integración continua. Tu revisor necesita ver las imágenes de antes/después/diferencias directamente en la solicitud de extracción. Si tiene que ejecutar pruebas localmente para ver qué cambió, no lo hará.

Las actualizaciones de la línea base requieren aprobación explícita. Nunca actualice automáticamente las líneas base al fusionar cambios. Este es el error más común que observamos. Si nadie revisa el cambio, la línea base se desfasa y, como consecuencia, se realizan pruebas con una referencia incorrecta.

Programa pruebas visuales semanales comparándolas con el entorno de producción. Si a esto le sumas pruebas de estrés previas al lanzamiento, habrás cubierto tanto los escenarios de riesgo graduales como los de impactos repentinos. Los widgets de terceros, las actualizaciones del navegador y los cambios en la CDN pueden provocar regresiones sin que tengas que modificar el código. Las ejecuciones programadas las detectan.

Cómo controlar los falsos positivos

Si tu presupuesto lo permite, utiliza la comparación de diferencias con IA. Herramientas como Percy y Applitools Eyes emplean visión artificial para comprender el contenido de la captura de pantalla, no solo los valores de los píxeles. Un motor de IA reconoce un botón como tal: distingue entre un cambio de diseño significativo y una variación de suavizado de subpíxeles. Los equipos que cambian de la comparación de píxeles a la comparación de diferencias con IA suelen observar una reducción del 40 al 60 % en los falsos positivos y el ruido en las pruebas visuales.

Mantenga una lista de enmascaramiento centralizada. Un archivo de configuración compartido que enumere todos los selectores que se deben ignorar: .timestamp, .user-avatar, .ad-banner, .live-counter, .chat-widget. Aplíquelo globalmente a todos los conjuntos de pruebas de regresión visual.

Establezca la tolerancia de suavizado de bordes. Las diferencias en la representación de fuentes entre sistemas operativos no son errores. Un threshold: 0.1 en su configuración de diff resuelve la mayoría de estos problemas sin ocultar señales útiles.

Revisa cada diferencia que falle. Si nadie aprueba ni rechaza los cambios, las líneas base se desvían y la herramienta pierde valor. Trata las diferencias visuales como una revisión de código: no son opcionales.

Herramientas de pruebas visuales: una comparación honesta

Sin afiliaciones. Sin recomendaciones patrocinadas. El mercado de herramientas para pruebas de regresión visual ha madurado rápidamente; aquí les mostramos lo que hemos visto funcionar en proyectos reales.

Playwright toHaveScreenshot(): Gratuito, integrado y sin necesidad de infraestructura. Playwright ha superado las 85 000 estrellas en GitHub. Si tu equipo ya utiliza las pruebas de regresión visual de Playwright, la comparación de capturas de pantalla integrada es la opción más rápida. Limitación: solo compara píxeles, sin filtrado por IA. Ideal para equipos con interfaces de usuario estables y menos de 50 páginas clave.

Percy (BrowserStack): Comparación de archivos en la nube con IA, plan gratuito generoso (5000 capturas de pantalla al mes). Integración perfecta con las solicitudes de extracción de GitHub/GitLab. El Agente de Revisión Visual, lanzado a finales de 2025, automatiza aún más la clasificación de archivos. Ideal para equipos en crecimiento que necesitan instantáneas multiplataforma sin gestionar la infraestructura.

Applitools Eyes: el motor visual con IA más potente. Complemento para Storybook y Figma para la validación del diseño a código. Es más caro, pero la IA visual reduce significativamente la carga de trabajo de revisión. Ideal para equipos empresariales donde la coherencia de la interfaz de usuario es un requisito de marca.

BackstopJS: código abierto, autoalojado y con configuración personalizable. Genera informes HTML con comparaciones lado a lado. Ideal para sitios web y equipos de marketing que buscan un control total sin depender de la nube.

Chromatic: diseñado específicamente para Storybook. Si tu biblioteca de componentes reside en Storybook, Chromatic captura automáticamente cada historia como una prueba visual. Ideal para equipos de sistemas de diseño y bibliotecas de componentes.

Para tener una visión más amplia de cómo abordamos las pruebas automatizadas en todo tipo de proyectos, el principio es el mismo: elige la herramienta que se adapte a tu flujo de trabajo, no la que tenga la mejor página de marketing.

Envío de lo que los usuarios realmente ven

Las pruebas funcionales te indican que algo funciona. Las pruebas visuales te indican que tiene buen aspecto. Ambas son importantes, pero solo una de ellas detecta el error que hace que el botón de pago se oculte tras un banner en Safari para móviles.

La lista de verificación anterior no es teórica. Es la que utilizamos en todos los proyectos. Los errores visuales no generan errores, y precisamente por eso son peligrosos.

Empieza poco a poco. Selecciona cinco páginas clave. Establece un entorno estable. Registra las líneas base. Realiza comparaciones en cada solicitud de extracción. Controla los falsos positivos antes de que afecten la motivación de tu equipo.

¿Pierde clientes porque los diseños fallan al implementarlos? Llevamos detectando errores visuales en más de 300 productos desde 2015. ¿Plazos ajustados? Contáctenos.

FAQ

Vea cómo una aplicación de escritorio con más de 670 integraciones mantuvo la coherencia visual en Windows, macOS y Ubuntu, con ciclos de regresión completos en ventanas de 1 a 2 días

Por favor ingrese su correo electrónico comercial no es un correo electrónico comercial

Obtenga el estudio de caso