Regresión — qué es, por qué ocurre y cómo probarla

Qué es la Regresión en el Desarrollo

Regresión es una situación en la que una funcionalidad que funcionaba en una versión anterior deja de funcionar después de realizar cambios. El cambio puede ser cualquier cosa: corrección de un error, adición de una nueva característica, refactorización, actualización de una librería o incluso un cambio de configuración. La regresión es el principal enemigo de la estabilidad: cada cambio corre el riesgo de romper algo que ya había sido verificado y lanzado.

El término proviene de las pruebas: pruebas de regresión es la re-ejecución de pruebas existentes después de cada cambio. Si una prueba que antes pasaba falla, ha ocurrido una regresión. En un sentido más amplio, la regresión no es solo una falla de prueba, sino cualquier degradación en el comportamiento notada por el usuario o QA. Según Tricentis State of Testing 2023, las regresiones representan el 35–45% de todos los errores encontrados en producción.

Lo que distingue una regresión de un error común es el contexto temporal: un error pudo haber existido siempre, mientras que una regresión siempre es el resultado de un cambio. Esta es una distinción importante porque encontrar la causa de una regresión comienza analizando qué cambió entre “funcionaba” y “dejó de funcionar”. Git bisect es la herramienta estándar para encontrar el commit que causó la regresión.

Tipos de Regresiones y Ejemplos

Regresión local — un cambio en el módulo A rompe la funcionalidad en el mismo módulo A. Ejemplo: un desarrollador reescribe una función de ordenamiento y deja de manejar correctamente un array vacío. La regresión local es la más fácil de detectar y corregir porque la causa y el efecto están cerca.

Regresión remota — un cambio en el módulo A rompe la funcionalidad en el módulo B, que no está conectado directamente por código pero sí por datos o temporización. Ejemplo: cambiar el esquema de base de datos en el módulo “Usuarios” rompe un informe en el módulo “Analítica” que usa la misma tabla. Las regresiones remotas son las más insidiosas: el desarrollador no sospecha que su cambio afectará a otro módulo.

Regresión de efecto secundario — un cambio en un efecto secundario (logging, caché, envío de notificaciones) rompe el comportamiento esperado. Ejemplo: un desarrollador añade caché para acelerar el rendimiento, pero debido a la caché obsoleta, los usuarios ven datos desactualizados. Las regresiones de efecto secundario son difíciles de detectar con pruebas automatizadas porque los efectos secundarios a menudo no están cubiertos por pruebas.

Regresión de rendimiento — el código sigue funcionando correctamente a nivel funcional pero es más lento que antes. Ejemplo: un nuevo algoritmo de cifrado produce los mismos resultados, pero el tiempo de ejecución ha aumentado de 2 ms a 200 ms. Las regresiones de rendimiento no se detectan con pruebas unitarias comunes — se necesitan benchmarks y profiling.

Por Qué Ocurren las Regresiones

La primera causa es el acoplamiento del código. Cuanto más dependen los módulos entre sí, mayor es la probabilidad de que un cambio en uno cause una regresión en otro. Antipatrones clásicos: God Object (un objeto que lo hace todo), Shotgun Surgery (un cambio en un lugar requiere ediciones en una docena de lugares), dependencia circular. Reducir el acoplamiento es cuestión de arquitectura: principios SOLID, Inyección de Dependencias, arquitectura hexagonal.

La segunda causa es la falta de pruebas para la funcionalidad modificada. Si el código no está cubierto por pruebas, el desarrollador solo se entera de una regresión a través de QA o los usuarios. Según Google Testing Blog, los proyectos con >75% de cobertura de pruebas tienen 5 veces menos regresiones que los proyectos con <25% de cobertura. TDD (Test-Driven Development) garantiza que las pruebas se escriban antes del código, no “cuando haya tiempo”.

La tercera causa son los factores humanos. El desarrollador desconoce la funcionalidad relacionada, no comprende todas las dependencias o simplemente tiene prisa. La razón es la falta de intercambio de conocimiento sobre la base de código. Soluciones: revisión de código con desarrolladores de otros módulos, programación en pareja, documentación de arquitectura. El bus factor del proyecto es inversamente proporcional a la cantidad de decisiones arquitectónicas documentadas.

Pruebas de Regresión y su Papel

Las pruebas de regresión son el proceso de re-ejecutar las pruebas existentes después de cada cambio para verificar que la funcionalidad anterior no se haya roto. Es la única forma de garantizar que un cambio nuevo no haya alterado el código existente. Sin pruebas de regresión, cada lanzamiento es una lotería: el desarrollador espera no haber roto nada pero no puede confirmarlo.

Las pruebas de regresión manuales son el enfoque más costoso y menos efectivo. A medida que un proyecto crece, el número de escenarios de prueba de regresión crece linealmente, mientras que el tiempo de ejecución manual crece exponencialmente. Después de 2–3 años de desarrollo, la regresión manual puede llevar 2–3 semanas, haciendo imposibles los lanzamientos frecuentes. La única solución es la automatización.

Las pruebas de regresión automatizadas se dividen en niveles según la pirámide de pruebas:

• Pruebas unitarias — rápidas, aisladas, cubren funciones y métodos individuales
• Pruebas de integración — verifican la interacción entre módulos, bases de datos, servicios externos
• Pruebas E2E — verifican escenarios completos de usuario a través de UI o API
• Pruebas de snapshot — comparan la salida actual de un componente con una referencia

Según Google Testing Blog, la proporción óptima es 70% pruebas unitarias, 20% pruebas de integración, 10% E2E. Desviarse de esta proporción reduce la efectividad de las pruebas de regresión: demasiadas pruebas E2E ralentizan el pipeline, muy pocas pruebas unitarias dejan micro-errores sin detectar.

Estrategias para Automatizar las Pruebas de Regresión

La primera estrategia es la Regresión Completa. Se ejecutan todas las pruebas del proyecto. Es el enfoque más fiable pero también el más lento. Adecuado para proyectos pequeños (hasta 10,000 pruebas, tiempo de ejecución <30 minutos). Para proyectos grandes, la regresión completa puede llevar horas, haciendo que el pipeline CI/CD sea poco práctico.

La segunda estrategia es la Regresión Selectiva. Solo se ejecutan las pruebas relacionadas con el código modificado. Se utiliza un grafo de dependencias del código para determinar las relaciones. Herramientas: Bazel (Google), Nx (JavaScript), sbt (Scala). La regresión selectiva ahorra 60–80% del tiempo de ejecución pero requiere una construcción precisa del grafo de dependencias — los errores conducen a regresiones no detectadas.

La tercera estrategia es la Regresión Priorizada. Todas las pruebas se clasifican por prioridad: ruta crítica (escenarios de usuario más importantes), alto riesgo (código con historial de errores), código modificado (código afectado por el cambio). Las pruebas de mayor prioridad se ejecutan primero — si pasan, el desarrollador recibe retroalimentación rápida. Ejecución con tiempo limitado: las pruebas críticas se verifican en 10 minutos, el resto se ejecuta en segundo plano.

Cómo Prevenir Regresiones en un Proyecto

El primer paso y el más importante es una cultura de escribir pruebas. Cada cambio debe ir acompañado de una prueba que verifique que el cambio funciona y una prueba que verifique que nada se ha roto. TDD (Test-Driven Development) da los mejores resultados: el desarrollador primero escribe una prueba que falla, luego el código que la pasa. Esto garantiza que la prueba existe antes del código.

El segundo paso es un pipeline CI/CD con ejecución obligatoria de pruebas. Una pull request no puede fusionarse hasta que todas las pruebas pasen. Las pruebas no pueden “saltarse” por urgencia — los cambios urgentes pasan por un conjunto de pruebas acelerado pero obligatorio. Según Google DevOps Research, los equipos con CI/CD obligatorio tienen 3 veces menos regresiones en producción.

El tercer paso es la monitorización en producción. Incluso las mejores pruebas no garantizan una protección del 100% contra regresiones. Las herramientas de observabilidad (Sentry, Datadog, New Relic) deben rastrear métricas clave después de cada despliegue: tasa de error, latencia, rendimiento. La reversión automática cuando se superan los umbrales es una red de seguridad si una regresión llega a producción.

El cuarto paso es la revisión de código con mentalidad de regresión. El revisor debe preguntarse: “¿Qué otros módulos podrían romperse con este cambio?”. No basta con verificar que el código sea correcto — hay que verificar que no altere la funcionalidad relacionada. La lista de verificación de revisión de código debe incluir un punto de “verificación de regresión en módulos relacionados”.