Pruebas de regresión: que arreglar A no rompa B

Una prueba de regresión es una prueba que vuelves a ejecutar después de un cambio para confirmar que lo que ya funcionaba sigue funcionando. Ese es el nombre entero: regresión es cuando el software "retrocede", cuando una función que antes estaba correcta vuelve a fallar por culpa de una modificación reciente. La prueba de regresión existe para atrapar ese retroceso antes de que llegue al usuario.

La escena es clásica. Arreglas el bug A, entregas, y a los tres días alguien reporta que el flujo B, que nadie tocó, dejó de andar. No es mala suerte: es que A y B compartían algo (una función, un dato, un supuesto) y tu arreglo movió el piso bajo los pies de B. La regresión es la disciplina de no confiar en que "eso no lo toqué".

01 · qué esRegresión: cuando el pasado vuelve a romperse

El estándar internacional de vocabulario de testing lo define sin adornos: la prueba de regresión es la que se ejecuta sobre un componente o sistema ya probado, después de una modificación, para verificar que no se introdujeron defectos o que no quedaron al descubierto defectos previos en las partes no modificadas [1]. Fíjate en el matiz: no buscas probar lo nuevo, buscas defender lo viejo.

Un defecto de regresión casi nunca aparece donde trabajaste. Aparece a un costado, en código que ni abriste. La razón es que el software está lleno de dependencias invisibles: una función que otras cinco llaman, una variable global, un formato de fecha, un orden de resultados que alguien asumió constante. Cambias una y las otras cinco se enteran tarde, en producción.

La regresión no prueba lo que hiciste. Protege lo que ya funcionaba de lo que acabas de hacer.

Por eso la regresión es distinta de las demás pruebas en intención. Una prueba nueva pregunta "¿esto que acabo de construir hace lo que debe?". Una prueba de regresión pregunta "¿esto que ya existía sigue haciendo lo que hacía?". La primera valida; la segunda vigila. Y como el producto crece, la lista de cosas que hay que vigilar solo se hace más larga.

02 · por qué creceLa suite engorda al ritmo del producto

Aquí está la trampa que sorprende a todo equipo joven. Cada función nueva que entregas se convierte, a partir de ese momento, en algo que hay que seguir protegiendo en cada release. La suite de regresión no es una lista fija: es la suma de todo lo que alguna vez funcionó y que no quieres perder. Crece con el producto, versión tras versión.

Al principio se puede a mano. Diez pantallas, veinte flujos, un tester los recorre en una mañana. Pero el producto no se queda en diez pantallas. A los dos años tienes cientos de flujos, y "recorrerlos todos a mano antes de cada entrega" se vuelve imposible: tomaría días, nadie lo hace completo, y los defectos de regresión empiezan a colarse justamente por las esquinas que se dejaron de revisar por falta de tiempo.

Este crecimiento explica por qué la regresión es el candidato número uno a automatizarse. Una prueba de regresión es, por definición, algo que ya sabes que debía pasar y que vas a volver a correr muchas veces sin cambios. Es repetitiva, predecible y aburrida: exactamente el trabajo que una máquina hace mejor que una persona. Automatizar lo nuevo y exploratorio es difícil; automatizar lo que ya está estable y solo hay que revisar una y otra vez es donde la automatización rinde de verdad.

La regresión manual escala con el equipo. La regresión automatizada escala con el producto. Solo una de las dos gana esa carrera.

03 · qué reejecutarNo puedes correr todo: hay que priorizar

Aunque automatices, llega un punto en que la suite completa tarda demasiado para correrla ante cada cambio pequeño. Entonces aparece la pregunta central de la regresión madura: de todo lo que podría reejecutarse, ¿qué reejecuto ahora? Correr todo siempre es lo más seguro, pero también lo más lento, y la lentitud tiene un costo: si la regresión tarda horas, la gente deja de correrla.

La respuesta se apoya en dos ideas. La primera es la selección por impacto: priorizas las pruebas que cubren las zonas que tu cambio pudo haber afectado, más las zonas de mayor riesgo (lo que más usan los clientes, lo que más dinero mueve, lo que más veces se ha roto antes). No todas las pruebas valen igual; una que protege el pago pesa más que una que protege una pantalla de ayuda.

La segunda idea es la higiene de la suite. Una regresión que crece sin poda se llena de pruebas frágiles (que fallan por motivos que no son bugs reales) y de pruebas duplicadas. Las pruebas frágiles son peligrosas porque enseñan al equipo a ignorar los fallos rojos, y una alarma que se ignora no protege nada. Mantener la suite significa borrar lo muerto, arreglar lo inestable y no dejar que engorde sin control.

04 · dónde viveLa regresión encaja en la tubería de CI/CD

Todo lo anterior cobra sentido cuando la regresión deja de ser un evento manual y se vuelve parte de la tubería de integración y entrega continua. La idea de la integración continua es que cada cambio que un desarrollador sube dispara automáticamente la construcción y las pruebas del proyecto, para detectar los problemas en minutos y no en semanas [2]. La regresión automatizada es el corazón de ese disparo.

El patrón práctico suele ser en capas. En cada cambio corre una regresión rápida y selectiva (las pruebas de mayor riesgo e impacto, en pocos minutos). Una vez al día, o antes de liberar, corre la suite completa, más lenta, que revisa todo lo demás. Así el desarrollador tiene una respuesta veloz para seguir trabajando, y el producto tiene una red completa antes de llegar al cliente.

Cuando esto funciona, la regresión deja de vivir en la cabeza de una persona y pasa a ser una propiedad del sistema: cada vez que alguien propone un cambio, la tubería contesta "sigue todo verde" o "rompiste esto", y lo hace sin que nadie tenga que acordarse de revisar. Esa es la diferencia entre esperar que el arreglo de A no rompa B, y saberlo antes de entregar.

Que quede la idea firme: la regresión no es un tipo de prueba raro ni avanzado. Es una postura ante el cambio. Cada cosa que hoy funciona es algo que mañana un cambio inocente puede romper, y la única defensa razonable es tener una red que vuelva a verificar lo de siempre, cada vez, de forma automática y priorizada. El pasado vuelve a romperse todo el tiempo. La regresión es lo que te avisa cuando lo hace.