¿Qué es el regression testing?

¿Qué es el Regression Testing?

El regression testing (pruebas de regresión) consiste en volver a ejecutar las pruebas existentes tras un cambio para confirmar que lo que funcionaba sigue funcionando. Una regresión es un paso atrás: algo que ayer pasaba y hoy falla. Corregir un bug, añadir una función, refactorizar, actualizar una dependencia o cambiar la configuración puede provocarla, y las pruebas de regresión detectan esas roturas involuntarias antes de que lleguen a los usuarios.

Una suite de regresión madura se convierte en la memoria ejecutable del producto: cada defecto publicado deja una prueba que lo reproduce, así que el mismo bug no vuelve en silencio. Complementa las pruebas de carga en el pipeline: la regresión funcional comprueba la corrección y la de rendimiento, la velocidad.

Por qué ocurren las regresiones

• Código compartido y efectos secundarios. Una función auxiliar o una columna de base de datos la usan más módulos de los que el autor cree, y un cambio "local" se propaga.
• Correcciones incompletas. El arreglo cubre el caso reportado pero rompe un caso límite vecino o reintroduce un defecto antiguo.
• Refactorización. La intención es no cambiar el comportamiento, pero se cuelan diferencias sutiles en el orden, los valores nulos y las rutas de error.
• Dependencias y entorno. Actualizar una librería o un runtime puede cambiar valores por defecto, eliminar APIs o alterar el rendimiento.
• Conflictos de integración. Dos cambios que pasan por separado pueden fallar al combinarse en la rama principal.

Qué cubre el regression testing

No es una técnica concreta sino un propósito: cualquier prueba sirve como regresión cuando protege un comportamiento ya verificado. Una suite suele incluir:

• Flujos clave de usuario: registro, inicio de sesión, pago y búsqueda.
• Reglas de negocio: precios, impuestos, permisos y descuentos.
• Reproducciones de bugs de cada defecto ya corregido.
• Integraciones y APIs, donde un cambio de contrato rompe a los consumidores externos.
• Comportamiento no funcional: tiempo de respuesta, throughput y tasa de errores bajo carga.

Tipos de regression testing

• Regresión unitaria. Pruebas rápidas y aisladas de una función; son la base de la mayoría de suites.
• Regresión de integración. Verifica que módulos, servicios y base de datos siguen cooperando.
• Regresión de sistema y extremo a extremo. Recorre toda la aplicación, a menudo desde el navegador, para validar flujos completos.
• Regresión visual. Compara capturas para detectar cambios no deseados de CSS o diseño.
• Regresión de rendimiento. Repite una prueba de carga contra una nueva versión y compara latencia, throughput y tasa de errores con una línea base.

Regression testing frente a retesting

El retesting (prueba de confirmación) repite exactamente el caso que fallaba para comprobar que el bug está corregido. El regression testing ejecuta la suite de alrededor para comprobar que el arreglo no rompió nada más. El primero es estrecho y dirigido; el segundo, amplio y preventivo. Los buenos equipos hacen ambos tras cada corrección.

Cuándo ejecutar las pruebas de regresión

1. En cada pull request. No se fusiona hasta que la suite pasa.
2. En cada commit a la rama principal. Detecta problemas de integración entre cambios simultáneos.
3. Tras correcciones y refactorizaciones.
4. Antes de cada versión. Una pasada completa es la última barrera antes de producción. Una prueba de humo breve tras el despliegue confirma que lo básico responde.
5. Según un calendario. Las pruebas lentas, como las de navegador y rendimiento, suelen ejecutarse de noche.

Estrategias de selección de pruebas

• Repetir todo. La opción más segura mientras la suite sea rápida.
• Regresión selectiva. Solo las pruebas que tocan el código cambiado y sus dependientes; más rápida, con algo de riesgo si el mapeo es incompleto.
• Regresión priorizada. Las pruebas de más riesgo y las que más fallan se ejecutan primero.

Muchos equipos combinan: un subconjunto selectivo y priorizado en cada pull request, y la ejecución completa de noche y antes de publicar.

Manual o automatizado

La regresión es repetitiva por naturaleza, así que es el mejor candidato a automatizar. Lo manual sigue siendo útil para pruebas exploratorias, funciones nuevas sin automatización estable y juicios de usabilidad. Regla práctica: automatiza todo lo que vayas a repetir.

Suites de regresión en CI/CD

La suite debe vivir en el pipeline de CI/CD: con cada push se compila la aplicación y se ejecutan las pruebas, y un fallo bloquea la fusión o el despliegue. Para que funcione tiene que ser lo bastante rápida para que el equipo espere, determinista para que un rojo signifique siempre un problema real, y paralelizada. Si tarda una hora o falla al azar, acaba ignorándose.

Pruebas de regresión de rendimiento

Las pruebas funcionales confirman que las respuestas son correctas, pero no dicen nada de la velocidad: una versión puede pasar todo y duplicar el tiempo de respuesta. Por eso se repite la misma prueba de carga contra la línea base y la nueva versión y se comparan p95, p99, throughput y tasa de errores; si se supera el umbral acordado, la compilación falla.

Con k6 se codifica con umbrales como http_req_duration: ['p(95)<800']; un umbral incumplido devuelve un código de salida distinto de cero y la CI detecta la regresión sola. Ejecutar la prueba desde varias regiones puede además revelar regresiones en rutas distribuidas geográficamente, como DNS, caché de borde y conmutación regional; las pruebas de carga de LoadFocus se ejecutan desde más de 25 regiones en la nube. La monitorización de APIs programada (monitorización de APIs en LoadFocus) lleva la misma idea a producción. Para un ejemplo práctico, consulta cómo detectar una regresión de rendimiento con pruebas automatizadas; para comparar dos ejecuciones, la guía de comparación con línea base. La primera señal suele ser la latencia.

Buenas prácticas y desafíos

• Cada bug se convierte en una prueba. El arreglo y la prueba que lo reproduce van en el mismo cambio.
• Combate las pruebas inestables. Una prueba que unas veces pasa y otras falla sin cambios de código enseña al equipo a ignorar los fallos.
• Mantén la suite rápida. Paraleliza, usa ejecuciones selectivas en pull requests y reserva la suite completa para la noche y las versiones.
• Elimina pruebas redundantes. Las obsoletas ralentizan la suite y ocultan los fallos importantes.
• Incluye el rendimiento. Las comprobaciones basadas en carga detectan la degradación lenta.

Preguntas frecuentes sobre regression testing

¿Cuál es el objetivo principal del regression testing?

Confirmar que los cambios recientes no han roto funcionalidad que ya funcionaba, y detectar efectos secundarios de correcciones, funciones nuevas, refactorizaciones y actualizaciones antes de que lleguen a los usuarios.

¿Cuál es la diferencia entre regression testing y retesting?

El retesting repite el caso que fallaba para confirmar una corrección. El regression testing repite la suite más amplia para confirmar que la corrección no rompió otra cosa.

¿Con qué frecuencia deben ejecutarse las pruebas de regresión?

Idealmente en cada pull request y en cada commit a la rama principal mediante un pipeline de CI/CD, más una pasada completa antes de cada versión. Las pruebas costosas, como las de navegador y rendimiento, suelen programarse de noche.

¿Se puede automatizar por completo?

La regresión funcional, de integración, visual y de rendimiento casi siempre se automatiza. Lo manual sigue siendo útil para pruebas exploratorias y funciones nuevas sin cobertura automática estable.

¿Qué es la regresión de rendimiento?

Repetir una prueba de carga contra cada nueva versión y comparar latencia, throughput y tasa de errores con una línea base. Si empeora más allá del umbral, la compilación falla.

¿Por qué se vuelven inestables las pruebas de regresión?

Suele deberse a supuestos de tiempo, datos de prueba compartidos y servicios externos poco fiables. Importa porque una prueba que falla al azar erosiona la confianza en toda la suite.