Un test flaky (o test inestable) es un test que produce resultados diferentes — éxito o fallo — para el mismo código y la misma configuración, sin que se haya realizado ninguna modificación al sistema testeado. A veces pasa, a veces falla. Sin explicación aparente.
Aquí va una opinión que quizás te incomode: un test visual flaky es peor que no tener ningún test. Y no es una provocación gratuita. Un test ausente no cuesta nada en el día a día. No bloquea tu pipeline de integración. No consume el tiempo de tu equipo. No destruye la confianza en tu infraestructura de testing. Un test flaky hace todo eso, cada día, de forma insidiosa — porque cada falso fallo se parece lo suficiente a un fallo real como para requerir investigación.
Los datos de Google sobre sus propios sistemas de test son elocuentes: aproximadamente el 1,5% de sus tests son flaky en cualquier momento dado, pero esos tests consumen una parte desproporcionada del tiempo de ingeniería. Si una empresa del tamaño y la capacidad técnica de Google no ha eliminado el problema, no es una cuestión trivial. Y en el dominio específico de las pruebas visuales, el problema se amplifica por la propia naturaleza de lo que se compara.
Por qué los tests visuales son particularmente vulnerables a la inestabilidad
El test visual automatizado introduce una capa de no-determinismo que los tests unitarios o funcionales no tienen. Un test unitario verifica que una función devuelve el valor correcto. Un test funcional verifica que un botón dispara la acción correcta. Estos resultados son binarios y deterministas.
La regresión visual verifica que el renderizado de tu interfaz coincide con una imagen de referencia. Y el renderizado de una página web es el resultado de una cadena compleja de procesos, cada uno introduciendo su propia variabilidad: análisis de HTML, aplicación de CSS, ejecución de JavaScript, carga de recursos externos, cálculo de layout, rasterización, composición. Cada eslabón de esta cadena es una fuente potencial de no-determinismo.
Las cuatro causas principales de los tests visuales flaky
Timing: el problema que no puedes ignorar
La web es asíncrona por naturaleza. Cuando le pides al navegador que capture una captura de referencia, ¿está la página realmente lista? La respuesta es casi siempre: depende.
La carga de una página no es un evento único — es una cascada de eventos. El HTML se analiza, el CSS se aplica, los scripts se ejecutan, las imágenes se cargan, las web fonts se aplican, las peticiones a la API devuelven datos. Cada paso tiene una duración variable. La estrategia clásica de esperar a que esté «listo» — DOMContentLoaded, evento load, o network idle — no garantiza que el renderizado visual esté completo.
Resultado: tu captura a veces muestra una página completa, a veces una página a medio renderizar. Y el test falla sin motivo real.
Animaciones: movimiento en un medio estático
Una captura de pantalla es una imagen fija. Una animación es un cambio continuo. Los dos son fundamentalmente incompatibles para la comparación automatizada. Si tu página contiene una animación de 300ms que se lanza al cargar, el momento exacto de la captura relativo al inicio de la animación varía entre ejecuciones.
Las animaciones infinitas (spinners, skeleton loaders) son aún peores: no existe ningún momento «estable» para capturar la captura de pantalla. Cada ejecución congela la animación en un punto diferente.
Contenido dinámico: todo lo que cambia sin que tú intervengas
Fechas, horas, anuncios publicitarios, avatares generados aleatoriamente, notificaciones en tiempo real, contadores de visitantes — todo varía entre ejecuciones de test. Cada variación se detecta como una diferencia visual. Cada diferencia hace fallar el test.
Red e infraestructura: las variables que no controlas
Tu test se ejecuta en un entorno que depende de recursos externos: servidores de API, CDN para imágenes y fuentes, servicios de terceros. La latencia varía entre ejecuciones. En un pipeline de CI/CD, el problema se amplifica — tu runner de CI comparte recursos con otros jobs, lo que introduce variabilidad adicional en el rendimiento.
El coste real de los tests flaky
El coste más visible es el tiempo de triaje. Cada fallo de un test flaky requiere investigación: alguien debe examinar los resultados, comparar manualmente, decidir si es real, y relanzar si es necesario. En un equipo con decenas de tests visuales, eso puede representar horas por semana.
Pero el coste más destructivo es invisible: la pérdida de confianza. Cuando un equipo aprende que los tests visuales fallan «todo el tiempo» sin motivo, desarrolla un reflejo automático de relanzamiento. El día que un test falla por un bug real, el reflejo es el mismo: relanzar. Y el bug llega a producción.
Este fenómeno tiene un nombre: el efecto «¡que viene el lobo!». Una vez instaurado, es muy difícil de revertir.
Estrategias de estabilización que realmente funcionan
Controlar el entorno de renderizado
Utiliza un navegador headless en un contenedor controlado con resolución fija, fuentes preinstaladas y configuración de red determinista. Congela la versión del navegador, desactiva el renderizado por GPU, configura un tamaño de viewport fijo. Cada variable que elimines es una fuente menos de inestabilidad.
Neutralizar las animaciones
Inyecta una hoja de estilos que fuerce todas las animaciones y transiciones a duración cero. Esto congela instantáneamente todos los elementos animados en su estado final, eliminando una de las fuentes más comunes de inestabilidad visual.
Estabilizar el contenido dinámico
Fija las fechas y horas, desactiva los widgets de terceros, mockea los datos de la API, sustituye los avatares generados por imágenes estáticas en los fixtures de test. El objetivo es un entorno donde la única variable sea tu código de interfaz.
Esperar de forma inteligente
En lugar de retrasos fijos (esperar 3 segundos), utiliza estrategias de espera basadas en el estado real de la página. Espera a que los elementos críticos sean visibles, a que las imágenes estén cargadas, a que las fuentes se hayan aplicado, a que las peticiones de red se hayan completado.
Adoptar una comparación que tolere el ruido
La comparación píxel a píxel es la más sensible al no-determinismo de renderizado. Los algoritmos perceptuales (SSIM, pHash) son más tolerantes. El enfoque estructural — comparar el DOM y las propiedades CSS calculadas en lugar de píxeles — es el más resistente al ruido de renderizado, porque ignora nativamente las variaciones de sub-píxel que causan la mayoría de los fallos intermitentes.
Cumplir con los criterios de accesibilidad WCAG también contribuye a la estabilidad: un diseño accesible tiende a ser más predecible en su renderizado.
El test visual no-code como solución al problema de mantenimiento
Las herramientas no-code como Delta-QA eliminan la capa de fragilidad de los scripts. No escribes scripts — configuras tus tests visualmente.
Cuándo eliminar un test flaky
Si un test visual falla de forma intermitente a pesar de todos los intentos de estabilización, la decisión más valiente — y a menudo más sabia — es eliminarlo. Un test flaky que nadie corrige degrada activamente tu pipeline. Acostumbra a tu equipo a ignorar los fallos.
Elimínalo, documenta por qué, y sustitúyelo por un check más específico. El objetivo no es tener el máximo de tests — es tener tests en los que tu equipo confíe.
FAQ
¿Cuál es la diferencia entre un test flaky y un falso positivo?
Un falso positivo señala un problema que no existe — basta una sola ocurrencia. Un test flaky produce resultados inconsistentes de una ejecución a otra para el mismo código. Un test flaky genera falsos positivos de forma intermitente.
¿Cómo se mide la tasa de flakiness de tus tests visuales?
Ejecuta la misma suite de tests visuales varias veces sin modificar el código y cuenta los tests cuyo resultado cambia entre ejecuciones. Cinco ejecuciones consecutivas son suficientes para identificar los tests más inestables.
¿Los tests visuales no-code son menos flaky que los tests con código?
Eliminan una categoría completa de flakiness — la fragilidad de los scripts de test (selectores frágiles, timing de navegación, gestión de estado). Pero siguen sujetos a las mismas restricciones de renderizado del navegador.
¿Hay que relanzar automáticamente los tests visuales que fallan?
El reintento es un parche, no una solución. Enmascara el problema. Si debes activar reintentos, limítalos a uno solo y marca los tests que necesitaron un reintento para su posterior investigación.
¿Cuál es el umbral de flakiness aceptable en CI/CD?
Apunta a menos del 1% del total de tu suite de tests. Por encima del 3%, el impacto en productividad se vuelve medible. Por encima del 5%, tu equipo casi con certeza desarrolla el reflejo de relanzar sistemáticamente los pipelines fallidos.
¿Delta-QA ayuda a estabilizar los tests visuales?
Delta-QA reduce la flakiness en origen utilizando un enfoque estructural en lugar de una comparación píxel a píxel. Las variaciones de renderizado de sub-píxel, el anti-aliasing y los problemas de timing que causan la mayoría de los fallos intermitentes se ignoran nativamente. Combinado con el enfoque no-code que elimina los scripts de test frágiles, Delta-QA produce resultados fiables y reproducibles sin configuración compleja.
Para profundizar
- Falsos Positivos en Test Visual: Por Qué Matan Tus Tests y Cómo Eliminarlos
- IA y Pruebas Visuales: Promesas, Realidad y Por Qué lo Determinista Sigue Siendo Más Fiable
- Cobertura de código vs cobertura de tests: por qué el front-end escapa a las métricas clásicas
- CSS roto después del despliegue: por qué ocurre y cómo evitarlo
Un test visual solo tiene valor si tu equipo confía en él. Los tests flaky destruyen esa confianza día a día. En lugar de perder tiempo estabilizando scripts frágiles y clasificando falsos fallos, adopta una herramienta diseñada para la fiabilidad desde el primer día.