Pruebas de regresión: seguro contra romper lo que ya funcionó

La peor categoría de error no es la que se introduce en una nueva función. Es lo que resucita una funcionalidad antigua, que funcionaba perfectamente hasta que alguien cambió algo más.

Es una escena familiar. El equipo soluciona un problema, lo implementa, lo celebra y tres días después descubre que esa solución interrumpió silenciosamente un flujo que nadie pensó en comprobar. El cliente lo encuentra primero. La confianza en el sistema y en el equipo se ve afectada.

Este fenómeno tiene un nombre: regresión. Es el sistema yendo hacia atrás. Y el conjunto de prácticas que existen para evitarlo son las pruebas de regresión, probablemente el tipo de prueba más subestimado y valioso de todos.

¿Qué son las pruebas de regresión?

La prueba de regresión es la reejecución de pruebas en características que ya existían, para garantizar que un cambio reciente no rompiera nada que ya funcionaba. La palabra clave es "ya existía". No verifica lo que acabas de construir; comprueba todo lo que podrías haber roto accidentalmente mientras lo construías.

La premisa es una verdad incómoda del software: cada sistema es una red de dependencias, muchas de ellas invisibles. Cambiar un punto puede afectar a otro que se encuentra a kilómetros de distancia en el código. Nadie puede, con sólo pensar, predecir todas las consecuencias de un cambio. Las pruebas de regresión son la red que atrapa lo que tu cabeza no predijo.

Por qué cada cambio es un riesgo

El software no es estático. Cambia todo el tiempo, correcciones, funciones, actualizaciones de biblioteca, ajustes de configuración. Y todo cambio, por pequeño que parezca, conlleva el riesgo de una regresión.

Lo peligroso es que la magnitud del cambio no predice la magnitud del daño. Un cambio en una línea puede interrumpir un flujo crítico si esa línea se encuentra en un punto compartido por muchas partes del sistema. He visto soluciones triviales que causan incidentes mayores que reescrituras completas.

Ésta es la paradoja del mantenimiento: cuanto más crece y madura un sistema, más valioso se vuelve y más riesgoso resulta cambiarlo, porque hay más cosas que pueden romperse. Sin una red de regresión, el equipo llega a un punto en el que tienen miedo de tocar el producto en sí. El sistema se "congela" no porque esté listo, sino porque es demasiado peligroso tocarlo.

Por qué la regresión requiere automatización

Es posible realizar la regresión manualmente, volviendo a ejecutar manualmente los flujos principales después de cada cambio. Funciona cuando el sistema es pequeño. Deja de funcionar rápidamente.

El problema es de escala y repetición. Es necesario hacer una regresión con cada cambio, en un conjunto que solo crece. Hacer esto a mano, repetidamente, es costoso, lento y, peor aún, sujeto a fatiga humana. El probador manual, al comprobar por centésima vez el mismo caudal, presta menos atención. Es natural.

Es por eso que la regresión es el caso de uso por excelencia de la automatización. Una prueba automatizada no se cansa, no se salta pasos y ejecuta en segundos lo que llevaría horas manualmente. Es exactamente el tipo de comprobación repetitiva y objetiva de que las máquinas funcionan mejor que las personas. La suite de regresión automatizada es la que permite cambiar el sistema con frecuencia y sin miedo.

¿Qué incluye la suite de regresión?

No es necesario que todo esté en la suite. Intentar cubrir todos los caminos posibles crea una suite gigante, lenta y costosa de mantener, que el equipo termina ignorando.

La regla general es priorizar por riesgo y frecuencia. Entran flujos críticos para el negocio, aquellos cuya avería provoca un daño real o pérdida de confianza. También hay áreas que históricamente han fallado: cada error corregido debe convertirse en una prueba de regresión, para garantizar que no vuelva a ocurrir. Este es uno de los mejores hábitos que puede adoptar un equipo.

Lo que tiende a quedar fuera, o a recibir menor prioridad, son las características periféricas, poco utilizadas y de bajo impacto. La cobertura total no es el objetivo; protección de lo que importa.

Los errores que hacen inútil la regresión

El primer error es dejar que la suite se pudra. Las pruebas de regresión reflejan el comportamiento esperado del sistema. Cuando el comportamiento cambia legítimamente y las pruebas no se actualizan, fallan porque están desactualizadas, no debido a un error real. El equipo aprende a ignorar los fallos y la red deja de atrapar cualquier cosa.

El segundo es tolerar las pruebas intermitentes. Una prueba de regresión que a veces pasa y otras falla sin motivo alguno es un veneno: diluye la credibilidad de todo el conjunto. Cuando el rojo deja de significar "algo se rompió", la regresión ha perdido su función.

El tercero es ejecutar la regresión demasiado tarde. Si la suite solo se ejecuta el día antes del lanzamiento, los problemas se acumulan y su seguimiento resulta costoso. Lo ideal es correr con cada cambio, sobre el transportador de integración, para que la rotura se detecte cerca de la causa, cuando aún es barato arreglarlo.

La regresión es lo que da libertad para evolucionar

Existe una interpretación errónea de que las pruebas de regresión son un bloqueo, una burocracia que retrasa la ejecución. Es todo lo contrario. Una buena suite de regresión es lo que le da al equipo la libertad de realizar resultados rápidamente.

Sin él, cada cambio requiere precaución, control manual, miedo. Con él, el desarrollador cambia el código, ejecuta la suite y, en cuestión de minutos, sabe si algo no funciona. Esta confianza es lo que le permite mantener el ritmo de entrega a medida que crece el sistema. La regresión no frena la velocidad; Es lo que hace que la velocidad sea sostenible.

En sistemas que soportan servicios críticos, públicos o privados, esto es aún más decisivo. La capacidad de desarrollar un sistema esencial sin temor a derribar lo que ya funciona es, en esencia, una capacidad de gobernanza. Las pruebas de regresión son una de las herramientas que lo hacen posible.

Al final todo software estable es un sistema que alguien tuvo el coraje de no dejar inactivo. La regresión es lo que hace que este coraje sea responsable en lugar de imprudente.

Si su equipo ya evita tocar partes del sistema por temor a romper algo, este temor es un síntoma de una falta de redes de regresión y es abordable. Tengo otros artículos en el blog sobre calidad, automatización y mantenimiento de software que hablan de este.