El costo real de los flaky tests en GitHub Actions

Un análisis de 10,000 runs reales de GitHub Actions publicado en mayo de 2026 determinó que el 30% de los reruns en CI no tienen nada que ver con bugs reales: son pruebas flaky en GitHub Actions que pasan al segundo intento sin ningún cambio de código. El costo promedio por ocurrencia es USD 37,50 en tiempo de ingeniería.

Qué son las pruebas flaky y por qué son invisibles

Un flaky test es una prueba que falla o pasa de forma no determinista ante el mismo código, sin ningún cambio en el fuente. No es un bug. No es un problema de configuración permanente. Falla ahora, pasa en un rato, y todo el mundo sigue adelante como si nada.

Ponele que estás mirando el pipeline a las 11 de la mañana y ves un trabajo rojo. Lo volvés a correr. Verde. Cerrás la tab y seguís con otra cosa. Eso es exactamente el ciclo que hace que los flaky tests sean tan difíciles de atacar: el problema desaparece solo, nadie abre un ticket, y el costo se acumula de forma completamente silenciosa durante meses.

El análisis de 10,000 workflow runs reales lo confirma con datos: 15 a 25% del cómputo de CI, dependiendo del repo, se gasta en reruns causados por estas pruebas. No es una estimación. Es lo que dice el log.

La diferencia entre un flaky test y un test roto es sutil pero crítica. Un test roto siempre falla. Uno flaky falla con cierta probabilidad, que puede variar según el orden de ejecución, el estado del sistema operativo, la hora del día, o si hay un proceso externo lento en ese momento. Eso lo hace mucho más difícil de reproducir y, por ende, de arreglar.

El costo económico real: números que probablemente te sorprenderán

USD 37,50 por ocurrencia parece razonable hasta que hacés el cálculo completo.

El modelo del análisis de ByteFrame usa una tasa de USD 75/h de costo total de ingeniería (salario más overhead), y contabiliza 30 minutos perdidos por ocurrencia: 7 minutos de investigación directa más 23 minutos de recuperación del contexto de trabajo profundo (estudios de productividad indican que ese es el tiempo promedio para retomar el estado mental anterior). En si comparamos con otras herramientas de CI profundizamos sobre esto.

Un test que flakea 3 veces por semana cuesta USD 5,850 al año. Eso es un test. Un equipo de 50 personas con una suite de tamaño normal puede estar dejando entre USD 200,000 y USD 400,000 anuales sobre la mesa, según las proyecciones del análisis.

¿Y qué pasó cuando lo llevaron a equipos reales? Exacto: nadie lo había calculado así. La mayoría simplemente absorbió el costo como parte del ruido operacional.

Lo que hace que este número sea peor de lo que parece a primera vista: el 8% del tiempo de QA de muchos equipos se va persiguiendo falsos positivos. 5 a 10 horas por semana por equipo, según el análisis de Autonoma sobre costos en CI/CD. No es overhead menor.

Cómo detectar pruebas flaky en GitHub Actions

El primer paso es dejar de depender de la memoria del equipo. “Ah sí, ese test falla cada tanto” no es un sistema de detección. Necesitás datos del historial de runs.

Historial de runs y patrones de reintento

GitHub Actions guarda el historial de ejecuciones. Si un mismo job fue reejecutado varias veces en los últimos 30 días sin cambios de código en el medio, ese es un candidato. La señal es simple: fallo seguido de éxito sin commit entre medio. El problema es que hacer ese análisis a mano sobre cientos de runs es un trabajo tedioso.

Herramientas de detección automática

Tres opciones concretas que existen hoy:

• GitHub Test Reporter (CTRF): la librería ctrf-io/github-test-reporter genera reportes estructurados de resultados de tests directamente en GitHub Actions. Permite identificar patrones de flakiness con datos históricos por test.
• BuildPulse: servicio dedicado a detección de flaky tests. Se integra al pipeline y manda alertas cuando detecta tests con comportamiento no determinista. Tiene versión gratuita con límites.
• Shaker: herramienta de investigación académica disponible en star-rg.github.io/shaker que usa análisis estático para identificar patrones de código que históricamente generan inestabilidad.

La diferencia entre flaky y roto importa a la hora de configurar estas herramientas: un test roto siempre falla, así que no aparece en el análisis de reruns exitosos. Los que pasaron al segundo intento sin cambio de código son los flaky. Cubrimos ese tema en detalle en cómo los tiempos de carga impactan en SEO.

El impacto en la productividad: el efecto que nadie ve en el dashboard

El cambio de contexto de 23 minutos no es un número de relleno. Viene de investigación sobre trabajo cognitivo profundo (deep work), y aplica muy bien a la realidad de un desarrollador que estaba en medio de implementar algo y tuvo que frenar para verificar por qué el pipeline se rompió.

Ese es el costo oculto que no aparece en ningún dashboard de CI: las 5 a 10 horas semanales por equipo que se van en investigar falsos positivos, las reuniones donde alguien dice “no, ese test falla a veces, ignorenlo”, y la erosión gradual de la confianza en la suite completa.

Cuando la gente deja de creerle a sus tests (porque “a veces fallan nomás”), el valor de tener una suite cae dramáticamente. Ese es el daño más difícil de reparar.

El efecto cascada es otro problema concreto: un job flaky que bloquea el pipeline deja a otros tests sin ejecutarse, retrasando el feedback en toda la cadena. No es un problema aislado, es un problema sistémico.

Estrategias prácticas: cuarentena, debugging y prevención

La cuarentena es el primer movimiento, no el último. Si un test flakea, no lo borrés, no lo comentés. Movelo a una suite de cuarentena que corre pero no bloquea el merge. Eso contiene el problema mientras lo arreglás. Tema relacionado: ejecutar tests en múltiples regiones.

Para depurar un flaky test, el truco es recrear las condiciones que lo hacen fallar. Tres señales típicas que buscás:

• Orden de ejecución: corré los tests en orden aleatorio con un seed fijo. Si con seed A pasa y con seed B falla, el test tiene dependencia de estado compartido.
• Timing: los tests que usan sleeps fijos en vez de esperar condiciones explícitas fallan cuando el sistema está bajo carga. Reemplazá `sleep(2)` por `waitFor(() => elemento.visible)`.
• Recursos externos: un test que depende de un servicio externo sin mock es un flaky test esperando el momento para fallar. Si el endpoint tardó 3 segundos cuando el timeout era 2, listo.

El principio de Pareto aplica acá de forma bastante directa: en la mayoría de las suites, 3 tests concentran el 80% de los reruns. Identificar esos tres y arreglarlos primero es la estrategia que da el mejor retorno sobre tiempo invertido.

Herramientas: comparativa básica

Si ya usás Datadog para observabilidad, su módulo de CI Visibility incluye detección de flaky tests y es probablemente la integración más directa si tu stack ya está ahí. Si no, el GitHub Test Reporter es el punto de entrada gratuito más accesible.

Plan de acción: por dónde empezar esta semana

Paso uno: auditá tu historial de runs de los últimos 30 días. Identificá los 10 tests con más reruns exitosos sin commit entre medio. Esos son tus candidatos.

Paso dos: cuarentena inmediata de los tres peores. No bloqueés el pipeline por tests que no reflejan bugs reales mientras los analizás.

Paso tres: configurá detección automatizada. Incluso con el GitHub Test Reporter gratuito podés tener visibilidad estructurada en pocas horas. Más contexto en plataformas que integran GitHub Actions.

El ROI esperado según el análisis es claro: corregir 3 tests problemáticos elimina aproximadamente el 80% del desperdicio de CI en una semana de trabajo. A USD 37,50 por ocurrencia, el retorno sobre tiempo invertido es de los mejores que vas a encontrar en optimización de pipeline.

Errores comunes

• Ignorar el flaky test porque “pasó al reintentar”. Ese es exactamente el patrón que hace que el costo se acumule durante meses sin que nadie lo vea. Un reintento exitoso es una señal de alerta, no una señal de alivio.
• Borrar o comentar el test en vez de cuarentenarlo. Un test borrado es cobertura perdida. La cuarentena mantiene la cobertura y detiene el impacto en el pipeline.
• Asumir que el problema es el ambiente de CI, no el test. A veces el ambiente falla, pero si el mismo test flakea en distintas máquinas y distintos momentos, el problema está en el test.
• No configurar un seed en el orden de ejecución. Sin seed fijo, no podés reproducir el fallo de forma consistente, y sin reproducción consistente, el debugging es una ruleta.
• Atacar todos los flaky tests al mismo tiempo. Concentrate en los 3 que generan más reruns. Los demás pueden esperar. La dispersión de esfuerzo en esto es un error clásico.

Preguntas Frecuentes

¿Qué son las pruebas flaky y por qué son un problema en CI?

Un flaky test es una prueba que falla o pasa de forma no determinista ante el mismo código fuente. Son un problema porque generan reruns innecesarios, erosionan la confianza en la suite y consumen tiempo de ingeniería sin aportar valor. El análisis de 10,000 runs de GitHub Actions determinó que el 30% de los reruns de CI son causados por tests flaky, no por bugs reales.

¿Cuál es el costo real de un flaky test por equipo?

A USD 75/h de costo total de ingeniería, cada ocurrencia de un flaky test cuesta aproximadamente USD 37,50 en tiempo perdido (30 minutos entre investigación y recuperación del contexto). Un test que flakea 3 veces por semana genera pérdidas de USD 5,850 anuales. Un equipo de 50 personas puede perder entre USD 200,000 y USD 400,000 al año si tiene múltiples tests inestables sin gestionar.

¿Cómo detectar qué tests son flaky en mi repositorio?

La señal más directa es buscar en el historial de GitHub Actions runs donde el mismo job falló y luego pasó sin ningún commit entre medio. Para automatizar esto, podés usar GitHub Test Reporter (CTRF) o BuildPulse. Ambos se integran al workflow de GitHub Actions y generan reportes estructurados que permiten identificar los tests con patrones de inestabilidad.

¿Cómo se arregla un test que falla aleatoriamente?

Las causas más comunes son: dependencia de estado compartido entre tests (se detecta corriendo en orden aleatorio con seed fijo), timeouts fijos en lugar de esperas condicionales, y dependencia de servicios externos sin mock. La primera acción recomendada es cuarentena: mover el test a una suite que no bloquee merges mientras se analiza y corrige la causa raíz.

¿Qué herramientas existen para gestionar flaky tests en GitHub Actions?

Las tres más usadas hoy son: BuildPulse (SaaS con integración nativa a GitHub Actions, freemium), GitHub Test Reporter basado en CTRF (open source, gratuito), y Datadog CI Visibility (pago, parte del stack de observabilidad de Datadog). Para equipos que recién empiezan, el GitHub Test Reporter es el punto de entrada más accesible sin costo adicional.

Conclusión

Los datos de 10,000 runs reales de GitHub Actions dejan poco margen para la duda: las pruebas flaky no son un problema menor de QA, son un drenaje silencioso de tiempo y dinero que la mayoría de los equipos no tiene cuantificado. USD 37,50 por ocurrencia, 30% de reruns desperdiciados, 5 a 10 horas semanales por equipo. Son números reales.

Lo que hace que esto sea atacable es que la distribución es muy concentrada: pocos tests generan la mayor parte del daño. Identificar los tres peores de tu suite, cuarentenarlos esta semana, y configurar detección automatizada es un trabajo de horas que puede tener retorno en días. No hace falta refactorizar toda la suite. Hace falta saber dónde mirar.

Fuentes

• ByteFrame en Dev.to – Análisis de 10,000 GitHub Actions runs y el costo de los flaky tests (mayo 2026)
• Autonoma Blog – Costo de ingeniería de los flaky tests en CI/CD
• ctrf-io/github-test-reporter – GitHub Test Reporter en GitHub
• Currents.dev – Qué es un flaky test y cómo solucionarlo
• Datadog Knowledge Center – Flaky Tests