La suite que se comió la entrega: cuando subir el tiempo límite esconde la causa

Un viernes a las 19:05, la versión nueva del sitio corporativo se quedó sin salir: el build llevaba 99 minutos de un tope de 100, y en el minuto 100 el sistema lo cortó.

El build es la canalización de entrega: compila, corre la suite de pruebas automatizadas y deja lista la versión. No falló ninguna prueba. Simplemente no terminaron a tiempo, y la cadena de entrega hizo lo que tenía que hacer: detenerse. La versión traía un cambio de texto y una corrección en el formulario de contacto, y mercadotecnia la necesitaba ese día: el lunes arrancaba una campaña.

En el canal del equipo, alguien escribió lo que todos pensaban: «¿Y si lo subimos a 120?».

La pregunta para usted es otra: ¿cuántas veces subió su equipo un tiempo límite este año, y en cuántas de ellas alguien preguntó por qué hacía falta?

Una aclaración antes de empezar: este es un escenario hipotético e ilustrativo. El equipo, el sitio y las cifras son inventados y no describen a ningún cliente de Hábil. El patrón aparece en muchos equipos y suele empezar igual: un defecto de diseño tapado por un parche que suena razonable. Lo que viene de fuentes publicadas lleva su número de referencia; cuando algo es lectura nuestra, lo decimos.

En 1 minuto

• El riesgo: tratar la duración de las pruebas como un problema de configuración: cada vez que la entrega se acerca al límite, alguien sube el límite y la causa sigue creciendo.
• El caso: en cinco semanas, el tope del build pasó de 30 a 100 minutos. La causa estaba desde el primer día: cada archivo de prueba reconstruía el sitio completo antes de revisar lo suyo. Ningún parche la tocó.
• Lo que cuesta no actuar: una entrega detenida el día que el negocio la necesitaba, una campaña sin página y un equipo que deja de confiar en sus propias alarmas. Para la validación que corre con cada cambio, Fowler recoge una guía de unos diez minutos [1] y DORA, un límite de unos 10 minutos para las pruebas [2]; en este equipo, la etapa de pruebas terminó en unos 58 minutos y el tope en cien.
• Lo que le toca decidir el lunes: que la duración de las pruebas tenga presupuesto y se compare versión contra versión, y que ningún parche se acepte si no explica la causa, lo proponga una persona o un asistente de inteligencia artificial.

En este artículo

1. ¿Qué pasó el viernes en que la entrega no salió?
2. ¿Cómo se llegó a cien minutos en cinco semanas?
3. ¿Cuál era la causa real?
4. ¿Por qué ningún parche resolvió el problema?
5. ¿Qué dice la práctica de la industria sobre cuánto debe tardar una entrega?
6. ¿Qué tres reglas cambian la historia?
7. ¿Qué papel jugó la inteligencia artificial?
8. ¿Cómo se ve la versión aburrida de esta historia?
9. Para llevar
10. ¿Qué hace Hábil?
11. Preguntas frecuentes

¿Qué pasó el viernes en que la entrega no salió?

La entrega no se detuvo por un error en el código: se detuvo porque las pruebas tardaron más que el tiempo que se les permitía.

Conviene separar dos relojes desde el principio, porque en esta historia se confunden con facilidad:

El tope es un permiso. La duración es un hecho. Subir el permiso no cambia el hecho; solo cambia cuándo se entera usted de él.

El sitio era el corporativo de una empresa mediana: unas páginas en español e inglés, un formulario y una sección de noticias. Nada de misión crítica. Por eso el caso es útil: el mismo patrón puede afectar sistemas más críticos, con un impacto que depende de su arquitectura, de la capacidad disponible y del diseño de sus pruebas.

En la semana 5, la etapa de pruebas rondaba los 58 minutos en condiciones normales; el resto del build completo se sumaba a esa cifra. Ese viernes, además, otra canalización ocupaba la misma máquina de integración: el build completo, con todas sus etapas y la espera por recursos, llegó a los 100 minutos del tope y se detuvo. La máquina compartida fue el empujón, no la causa: una suite sana habría tardado más, pero lejos del tope. Esta ya vivía tan cerca del límite que cualquier carga extra bastaba para cruzarlo.

¿Cómo se llegó a cien minutos en cinco semanas?

Con cinco decisiones que, una por una, tenían sentido, y ninguna de las cuales preguntó por qué tardaba lo que tardaba.

El equipo usaba asistentes de inteligencia artificial para generar buena parte del código y de las pruebas, y cada funcionalidad nueva llegaba con su prueba. Eso parecía disciplina. Cada fila de la tabla tuvo una explicación que sonaba bien: «la suite creció», «los archivos grandes son lentos», «la máquina se ahoga». Y nadie hizo la única pregunta que importaba: ¿por qué tarda lo que tarda?

¿Cuál era la causa real?

Cada archivo de prueba reconstruía el sitio completo antes de revisar lo suyo: un costo que debía pagarse una vez se pagaba doscientas treinta.

La pista estuvo en la tabla todo el tiempo. Mire la semana 5: casi las mismas pruebas, unos 18 minutos más. Como el alcance de las pruebas cambió poco, la hipótesis razonable era que esos minutos venían de cómo se ejecutaban, no de qué se probaba. Una hipótesis se confirma midiendo: separando el tiempo de preparación, el de prueba y la espera por recursos. En el escenario, esa medición muestra que casi todo era preparación.

Para comprobar que un botón decía «Send» en la versión en inglés, el archivo de prueba hacía todo esto: compilar el sitio, generar todas sus páginas en los dos idiomas, ponerlo a funcionar y, apenas entonces, mirar el botón. El siguiente archivo, el del mismo botón en español, repetía todo desde cero. Y el siguiente. Unas doscientas treinta veces.

Es como construir el edificio otra vez antes de revisar cada foco.

Con 60 archivos, ese costo repetido no dolía, y como nadie medía cuánto se iba en preparar y cuánto en probar, nadie lo vio. Con cada archivo nuevo, crecía en proporción. Ese es el defecto de nacimiento: no era un problema de la semana 5, era un diseño que desde la semana 1 incorporaba un costo repetido, que crecería con cada archivo nuevo.

Con eso en la mano, cada parche se lee distinto:

• Partir 4 archivos en 13 convirtió 4 reconstrucciones del sitio en 13.
• Bajar el paralelismo hizo que esas reconstrucciones corrieran más en fila y menos al mismo tiempo.
• Subir el tope le dio más cuerda a todo lo anterior.

Las fallas «sin razón» de la semana 3 también tienen otra lectura. En el escenario, eran compatibles con una máquina saturada. Google documentó en 2016 que, entre varias causas posibles de las pruebas que a veces pasan y a veces fallan con el mismo código, están la concurrencia —varias pruebas que compiten por lo mismo al mismo tiempo— y los problemas de infraestructura [3]; confirmarlo en un caso concreto exige métricas y registros de ejecución. Darles más tiempo sin medir no las curó: les quitó la voz.

¿Por qué ningún parche resolvió el problema?

Porque todos atendían el síntoma —el reloj— y ninguno el trabajo que se repetía.

Ningún parche era incorrecto en sí; a todos les faltó medir antes de decidir.

Un tiempo límite funciona como un detector de humo. Si se sube cada vez que suena, no hay menos fuego: hay menos aviso.

Google lo describe con números en su propia operación: alrededor del 1.5 % de todas sus ejecuciones de pruebas reportaba un resultado inestable, y casi el 16 % de sus pruebas tenía algún grado de inestabilidad [3]. Lo más relevante para usted es la consecuencia que señalan: con tantos falsos positivos, es común que se ignoren fallas legítimas [3]. Y advierten que apartar en automático las pruebas inestables puede enmascarar con facilidad un error real del código [3]. Tolerar una alarma tiene un precio, aunque no aparezca en ninguna factura.

Por eso la moraleja de esta historia no es «la suite creció hasta romperse». Es más incómoda: nació con el defecto, y cada parche que no midió la causa la hizo más lenta.

¿Qué dice la práctica de la industria sobre cuánto debe tardar una entrega?

Que la validación que corre con cada cambio debe rondar los diez minutos, y que cuando empieza a crecer se actúa de inmediato, no cuando ya no cabe.

Martin Fowler, en su artículo sobre integración continua, retoma la guía de la programación extrema (XP) de un build de diez minutos y dice que, para la mayoría de los proyectos, es perfectamente razonable [1]. Y pide vigilar los tiempos del build y actuar en cuanto empiecen a superar la regla de los diez minutos [1]. También observa que, al menos en aplicaciones empresariales, el cuello de botella habitual son las pruebas [1].

DORA describe la integración continua en términos parecidos: las pruebas deben correr en unos cuantos minutos, con un límite superior de unos 10 minutos [2]. Y fija una disciplina de equipo: si las pruebas automáticas fallan, el equipo deja lo que está haciendo para arreglarlo de inmediato; si el build no se puede arreglar en unos minutos, se identifica y se revierte el cambio que lo rompió [2]. DORA pide además que las pruebas sean confiables y rápidas, para dar retroalimentación lo antes posible, y propone sacar las pruebas más largas a un build aparte [2]. Ojo con la diferencia: decidir qué pruebas corren con cada cambio y cuáles en otro momento es una decisión de diseño que se toma de antemano; sacarlas porque ya no caben es otro tope que se sube.

Puesto junto al escenario:

Lectura nuestra: diez minutos no es un número mágico, pero la práctica deja claro que la duración se vigila y se defiende como una propiedad del sistema, no como una casilla que se ajusta cuando estorba.

¿Qué tres reglas cambian la historia?

Ninguna es una línea de configuración: las tres son criterio, y caben en una política de ingeniería de una página.

Regla 1. Lo caro se prepara una vez y se reutiliza hasta donde sea seguro

Si las pruebas necesitan el sitio construido, una base de datos con datos de ejemplo o un servicio levantado, identifique qué puede prepararse una vez y compartirse sin romper el aislamiento entre pruebas.

Lo que no cambia, como un sitio ya construido, lo usan todas las pruebas; lo que sí cambia, como una base de datos, se aísla o se reinicia de forma controlada. Nadie reconstruye el mundo para mirar un botón.

No es una idea nueva. Los marcos de pruebas modernos traen un lugar para la preparación global: una función que se ejecuta una vez antes de todas las pruebas [4][5], o recursos cuyo alcance es la sesión completa de pruebas y no cada prueba individual [6]. La documentación de uno de ellos señala que los recursos que requieren acceso a la red suelen ser costosos de crear [6]. El mecanismo cambia de una herramienta a otra: otro de esos marcos recomienda declarar la preparación como un proyecto del que dependen los demás, en lugar de su función global, porque se integra mejor con su ejecutor de pruebas [4].

Y lo preparado no necesariamente queda disponible igual para cada prueba: uno de esos marcos aclara que las variables globales definidas en su preparación no se pueden leer desde las pruebas [5]. Su equipo debe confirmarlo antes de dar el arreglo por hecho.

Regla 2. La suite tiene presupuesto, y se compara versión contra versión

Igual que un proyecto tiene presupuesto de dinero, la etapa de pruebas tiene presupuesto de duración, y se vigila en cada versión.

No basta con que «quepa en el tope». La pregunta es si tarda lo mismo que la versión anterior y, si tarda más, si alguien lo esperaba. Para eso, la cadena de entrega lleva una compuerta: una regla automática que detiene la entrega cuando la duración rebasa la variación permitida. Por ejemplo, si la etapa tardaba 12 minutos y la versión nueva tarda 16 sin que nadie lo hubiera anticipado, eso se ve y se explica antes de seguir.

Es una compuerta, no una estadística que alguien revisa cuando se acuerda. Con ella, este equipo habría podido detectar la desviación en la semana 2, y no en la 5, cuando costó una campaña. Es la instrucción de Fowler de actuar en cuanto el build se empiece a pasar [1], convertida en control automático.

Regla 3. Subir el tope o partir pruebas no cuenta como arreglo

Cuando la suite choca con su presupuesto, la primera pregunta no es «¿cuánto tiempo más le damos?», sino «¿qué se está repitiendo que no debería?».

Subir el tope puede ser una medida temporal válida para una entrega urgente, pero se registra como lo que es, deuda con fecha y con dueño, y la investigación de la causa se abre ese mismo día. Si el tope sube y nadie abre la investigación, no fue una decisión técnica: fue barrer debajo del tapete.

¿Qué papel jugó la inteligencia artificial?

Ninguno que la haga culpable ni inocente: las propuestas atendían la pregunta que el equipo planteaba, y nadie planteó la de la causa.

Culpar a la herramienta o absolverla no le sirve a la dirección. La pregunta que el equipo planteaba era «¿cómo hago que pase?», y las propuestas que obtuvo atendían eso: más tiempo, más pedazos, menos procesos. Respuestas plausibles a la pregunta equivocada.

El problema fue otro: el equipo aceptó cada parche sin preguntar por qué. Cuando una persona con poca experiencia propone subir un tiempo límite, alguien con más oficio suele preguntarle «¿y por qué tarda?». Cuando la propuesta llega al instante y redactada con seguridad, esa pregunta se salta con más facilidad.

La velocidad de los asistentes no elimina la necesidad de criterio: la aumenta, porque ahora los errores también se producen más rápido. La regla que deja esta historia es simple de escribir y exigente de cumplir: un parche que no explica la causa no se acepta, venga de una persona o de una herramienta. La revisión de cambios exige evidencia de la causa, del impacto esperado y de la medición posterior, sin importar el origen de la propuesta.

¿Cómo se ve la versión aburrida de esta historia?

Es la misma semana 2, con una compuerta que hace sonar la alarma a tiempo y alguien que pregunta por qué.

En esa versión, el martes de la semana 2 la compuerta marca que la etapa pasó de 12 a 16 minutos sin explicación. La versión se detiene unas horas. Una persona del equipo mide en qué se va el tiempo y encuentra que casi todo es preparación: cada archivo construye el sitio desde cero.

Esa tarde, el sitio se construye una vez al inicio y todas las pruebas lo usan; la base de datos de ejemplo se reinicia de forma controlada entre pruebas. Tras validar el cambio, la etapa puede volver al presupuesto acordado y el tope se queda donde estaba.

Tres semanas después, el viernes de la campaña, otra canalización ocupa la misma máquina y el build tarda un poco más. Con margen suficiente ante esa carga extra, el riesgo de que la suite detenga la entrega es mucho menor.

Esa es la versión aburrida. Y en una cadena de entrega, aburrido es la meta.

Para llevar

Cuatro preguntas para su próximo comité de tecnología:

1. ¿Cuánto tarda hoy la etapa de pruebas de nuestros sistemas principales, cuánto tardaba hace tres meses y quién vigila esa diferencia?
2. ¿Cuántas veces subimos un tiempo límite este año, y cuántas de esas veces se abrió una investigación de la causa con fecha y dueño?
3. ¿Sabemos qué parte de la duración de nuestras pruebas es preparación y qué parte es prueba?
4. Cuando un asistente de inteligencia artificial propone un parche, ¿nuestro proceso de revisión le exige explicar la causa, o solo que la entrega pase?

¿Qué hace Hábil?

Hábil ayuda a que su cadena de entrega sea rápida y confiable, para que liberar un cambio deje de ser una apuesta.

Una suite de pruebas con duración creciente puede retrasar entregas y generar costos operativos que nadie ve venir. Trabajamos con su equipo en cuatro frentes:

• Pruebas que miden lo que importa. Que cada prueba compruebe algo del negocio y que lo costoso se prepare una vez, no doscientas treinta.
• Presupuesto de duración vigilado. La duración de las pruebas se controla como cualquier otro presupuesto, con una compuerta que la compara versión contra versión.
• Cada alarma con dueño y causa. Las pruebas intermitentes y los tiempos límite se tratan como avisos que se investigan, no como ruido que se silencia.
• Asistentes de IA sin perder el criterio. Su equipo aprovecha la velocidad de los asistentes con una revisión que exige que cada cambio explique su porqué.

Integramos las pruebas y la seguridad dentro del camino de entrega. Vea Nube y DevSecOps.

Si su etapa de pruebas lleva semanas creciendo y ya subieron el tope más de una vez, empecemos por ahí. Platiquemos su caso. La primera conversación es sin costo.

Preguntas frecuentes

¿Subir el tiempo límite del build está mal?

No necesariamente. Puede ser una medida temporal válida para sacar una entrega urgente. El problema aparece cuando se usa como arreglo: si el tope sube y nadie mide en qué se va el tiempo, la causa sigue creciendo. Por eso cada aumento se registra como deuda con fecha y dueño.

¿Cómo sé si mi equipo tiene este mismo defecto?

Una señal clara es la de la semana 5: la duración sube mucho más que el número de pruebas. Otra, que partir archivos lentos no mejore el tiempo total. La comprobación de fondo es medir, por archivo, cuánto se va en preparar el entorno y cuánto en probar. Si la preparación domina y se repite en cada archivo, ahí está el costo.

Fuentes consultadas el 6 de noviembre de 2026. Las citas de documentos en inglés están traducidas.

Dorian Chávez cuenta una versión narrada de este patrón en su Substack, «En construcción»: https://enconstruccionmx.substack.com/p/la-suite-que-se-comio-la-entrega