En el desarrollo de software, la falta de pruebas tiene consecuencias desastrosas como estábamos a punto de comprobar en una salida en vivo que nos llevó a una búsqueda frenética de horas para encontrar un defecto.

Eran principios de 2023. Yo trabajaba como gerente de desarrollo de software y me acompañaba un ingeniero de mi equipo. Estábamos en algún lugar de Canadá, en las oficinas de un cliente de la empresa para la que trabajaba. Esa mañana estábamos saliendo en vivo con una actualización de un software.

En el primer minuto, la nueva función del software trabajó correctamente y después las funciones preexistentes comenzaron a fallar. Los errores que veíamos el ingeniero de software que estaba conmigo y yo, no tenían sentido para nosotros.

Lo que habíamos actualizado era un servicio web. Un servicio web es una forma en que dos sistemas o aplicaciones se comunican entre sí por internet para intercambiar información automáticamente.

Por ejemplo, una función del servicio web puede decirte la temperatura de una ubicación, mientras que otra función puede recibir la cantidad de lluvia que ha caído y registrarla en el sistema. Un programa puede usar automáticamente ambas funciones para recibir y enviar información.

El error que veíamos era que cuando el sistema de nuestro cliente llamaba a cualquiera de las funciones preexistentes, el sistema obtenía un error que decía que la respuesta no estaba en el formato esperado. Si llamaba a la nueva función, esta operaba correctamente.

Me invadió la zozobra momentánea. ¿Qué estaba pasando? Necesitábamos resolver el problema en breve, no podíamos detener la operación de los sistemas por mucho tiempo porque se paralizaría toda una planta de manufactura.

¿Cómo habían probado esto?

Las pruebas se habían hecho, como después averigüe, solo con la nueva función. No hubo pruebas de regresión, es decir comprobación de que lo que ya estaba funcionando siguiera funcionando después de agregar la nueva función.

Me tranquilicé rápidamente, tenía que pensar. Cuando tienes una emergencia, necesitas pensar claramente. Para pensar tienes que estar tranquilo y dejar de pensar en todo lo que está alrededor y de las cosas que están siendo afectadas. Es eso o sucumbir a la desesperación.

Bueno, había dos opciones.

Uno: echar para atrás todo, revirtiendo a la versión anterior e iniciar todo el proceso de diagnóstico y correcciones. Luego habría que estimar una nueva fecha para que el cliente tuviera disponible la nueva función.

Dos: la nueva función estaba trabajando bien. Así que pensé que, si podía colocar la versión anterior en un sitio paralelo y dirigir hacia allá las llamadas del sistema del cliente que requiriesen a las funciones anteriores, podría servir temporalmente.


Encontrar el problema y corregirlo no sería un proceso rápido porque no teníamos ni idea de la causa después de haber hecho algunas pruebas, así que me decidí por la opción dos, al final de cuentas teníamos una versión anterior donde el servicio funcionaba y una versión siguiente donde solo la función nueva servía.

Si ponía por separado esas dos piezas, tenía una solución completa que les permitiría seguir adelante, mientras nosotros solucionábamos el problema y generábamos una versión única donde todo funcionara correctamente.

A esta técnica se le llama despliegue azul – verde. El servidor verde es el que ha estado funcionando en vivo o modo productivo y el servidor azul es el que tiene la nueva versión. Usas un mecanismo para dirigir a los usuarios o en este caso programas a la versión que quieres que utilicen.

La diferencia es que esta técnica se usa para probar en el servidor azul, mientras que nosotros utilizaríamos el azul como un ambiente productivo paralelo.

Le describí la opción dos al ingeniero de software.

- ¿Por qué no usamos el servidor de pruebas como el servidor para la versión anterior? Y dirigimos para allá todas las llamadas a las funciones preexistentes. Solo dirigimos la llamada a la nueva función hacia el servidor de producción que es el que tiene la nueva versión.

Nos pusimos en marcha y en unos cuantos minutos teníamos listo el servidor de pruebas con la versión anterior. Hablé con el gerente del proyecto del lado del cliente para comunicarle la situación y el plan de emergencia que teníamos.

En un par de minutos más, estábamos al teléfono con el equipo del sistema del cliente, ubicado en India, dándoles las direcciones de ambos servidores para que enrutaran sus llamadas como había descrito. En menos de treinta minutos todo estaba trabajando bien con esta solución temporal.

Luego el ingeniero de software y yo empezamos el diagnóstico del problema. Era desconcertante, no entendíamos como algo que no había cambiado ahora fallaba. Pero en la asunción que hicimos estaba el problema. Descubrí que sí se había hecho un cambio para refactorizar el código fuente, o sea para modificar la forma en que las instrucciones de programación están estructuradas, haciendo al programa más eficiente o fácil de mantener.

Ese cambio había descompuesto el programa y para mi sorpresa el cambio no se había probado y así se había liberado. Y eso fue lo que nos explotó al intentar usarlo.

Involucré al equipo de desarrollo en las oficinas de la empresa, incluyendo al desarrollador que llevó esto a cabo, a quién le expliqué las consecuencias de no probar, le describí el impacto y les pedí que iniciaran la corrección.

Un día después, teníamos una versión probada, lista para instalar en el ambiente de pruebas de nuestro cliente e iniciar un ciclo de validación.

Cuando falla la aplicación de protocolos y procedimientos de calidad, ocurren serios problemas.

Fotografía: Seljan Salimova