¿Qué es regression testing?

Que es el Regression Testing?

El regression testing es la practica de volver a ejecutar los tests existentes despues de un cambio para confirmar que el codigo que antes funcionaba sigue funcionando. El nombre viene de la palabra "regresion", que significa un paso atras: una feature que pasaba ayer y falla hoy. Cada vez que arreglas un bug, agregas una feature, refactorizas un modulo, actualizas una dependencia o cambias configuracion, corres el riesgo de romper algo que se comportaba correctamente. El regression testing es la red de seguridad que atrapa esas roturas no intencionadas antes de que lleguen a los usuarios.

Una regression test suite madura se convierte en la memoria ejecutable de un producto. Cada defecto entregado deja un test que lo reproduce, de modo que el mismo bug nunca puede volver en silencio.

Por que ocurren las regresiones

El software esta muy interconectado, y un cambio rara vez es tan aislado como parece. Las causas comunes incluyen:

• Codigo compartido y efectos secundarios. Una funcion helper o una columna de base de datos compartida la usan mas modulos de los que crees, asi que una edicion local se propaga hacia afuera.
• Fixes incompletos. Un fix resuelve el caso reportado pero rompe un edge case adyacente o reintroduce un defecto antiguo.
• Refactoring. Reestructurar sin cambiar comportamiento es la intencion, pero se cuelan diferencias sutiles, sobre todo en orden, manejo de null y rutas de error.
• Dependencias y entorno. Actualizar una libreria o un runtime puede cambiar defaults o eliminar APIs.
• Conflictos de merge. Dos cambios que pasan por separado pueden chocar al combinarse en la rama main.

Que cubre el regression testing

El regression testing no es una tecnica unica sino un proposito. Cualquier test puede cumplir un rol de regresion una vez que protege comportamiento ya verificado. Una suite abarca tipicamente:

• User journeys centrales como registro, login, checkout y busqueda, que nunca deben romperse.
• Reglas de negocio como precios, impuestos y permisos, donde un cambio silencioso cuesta dinero real.
• Reproducciones de bugs que fijan cada defecto arreglado antes.
• Integraciones y APIs donde un cambio de contrato rompe consumidores externos.
• Comportamiento no funcional como tiempo de respuesta y error rate bajo carga, el area de la regresion de rendimiento.

Tipos de regression testing

Los chequeos de regresion corren en cada nivel de la piramide de tests:

• Regresion unit. Tests rapidos y aislados de una sola funcion. Forman la base porque corren en milisegundos y senalan la unidad exacta que falla.
• Regresion integration. Verifica que modulos, servicios y base de datos sigan cooperando bien tras un cambio.
• Regresion system y end to end. Maneja toda la aplicacion, a menudo por el navegador, para confirmar journeys completos.
• Regresion visual. Compara screenshots pixel a pixel para marcar cambios de CSS o layout no intencionados.
• Regresion de rendimiento. Reejecuta un load test contra un build nuevo y compara latency, throughput y error rate con una baseline.

Regression testing vs retesting

Estos terminos se confunden a menudo, pero responden preguntas distintas. El retesting verifica que un bug concreto esta arreglado reejecutando el caso exacto que fallaba. El regression testing verifica que el fix no rompio nada mas reejecutando la suite alrededor.

Cuando ejecutar regression tests

1. En cada pull request. Un cambio no mergea hasta que la suite pasa.
2. En cada commit a main. Atrapa problemas de integracion de cambios concurrentes.
3. Tras fixes y refactors. Los momentos con mayor riesgo de regresion.
4. Antes de cada release. Una pasada completa contra el release candidate.
5. Segun calendario. Los chequeos caros como browser y rendimiento corren de noche.

Estrategias de seleccion de tests

Al crecer el producto, correr todo en cada cambio se vuelve lento. Tres estrategias equilibran cobertura y velocidad:

• Retest all. Correr la suite completa. Lo mas seguro mientras sea rapida.
• Regresion selectiva. Correr solo los tests del codigo cambiado y sus dependientes, via coverage o test impact analysis.
• Regresion priorizada. Ordenar los tests para que los de mayor riesgo corran primero y den feedback rapido.

Muchos equipos combinan: un subconjunto selectivo en cada pull request y una pasada completa de noche y antes del release.

Manual vs automatizado

El regression testing es repetitivo por naturaleza, lo que lo hace el mejor candidato para la automatizacion en todo el proceso de test. Correr cientos de chequeos a mano en cada cambio es lento y propenso a errores, asi que la regresion automatizada es la norma para chequeos funcionales, de integration, visuales y de rendimiento. La regresion manual sigue siendo util para trabajo exploratorio y features nuevas sin automatizacion estable. La regla: automatiza cualquier chequeo que se repita y reserva la atencion humana para lo que necesita juicio real.

Regression suites en CI/CD

El regression testing moderno vive dentro del pipeline de CI/CD. Cuando alguien hace push, el pipeline construye la aplicacion y corre la suite automaticamente; un fallo bloquea el merge o el deploy. Esto convierte la regresion en un gate continuo e inevitable. Para que funcione, la suite debe ser rapida para que los desarrolladores esperen, deterministica para que un rojo signifique un problema real, y paralelizada para que suites grandes terminen en minutos.

Regresion de rendimiento

La regresion funcional confirma respuestas correctas, pero no dice nada sobre velocidad. Un cambio puede dejar cada test funcional en verde y aun asi duplicar el tiempo de respuesta. La regresion de rendimiento cierra esa brecha reejecutando un load test contra cada build y comparando con una baseline.

En la practica tomas el mismo script que usas para load testing y lo corres a carga identica contra la baseline y el build nuevo. Herramientas como k6 permiten thresholds como http_req_duration: ['p(95)<800'], de modo que un threshold violado fija el exit code y CI atrapa la regresion automaticamente. Correr el mismo chequeo desde varias regiones contra un edge real de CDN, como hace LoadFocus, tambien revela regresiones en rutas geo distribuidas. Combinado con monitores de API programados, la misma idea llega hasta produccion.

Buenas practicas y desafios

• Cada bug se vuelve un test. El fix y un test que reproduce el defecto aterrizan en el mismo cambio.
• Combate los tests flaky. Un test que falla al azar entrena al equipo a ignorar fallos.
• Manten la suite rapida. Paraleliza y usa runs selectivos en pull requests.
• Poda el suite bloat. Borra tests redundantes y obsoletos.
• Incluye rendimiento. Agrega aserciones basadas en carga en CI.

Los mayores desafios son suites lentas y flaky, el costo de mantenimiento y la tentacion de saltarse la regresion bajo presion de fecha, justo cuando mas importa.

FAQ sobre Regression Testing

Cual es el objetivo principal del regression testing?

Confirmar que los cambios recientes no rompieron funcionalidad existente que ya funcionaba, y detectar efectos secundarios no intencionados de fixes, features y upgrades antes de llegar a los usuarios.

Cual es la diferencia entre regression testing y retesting?

El retesting reejecuta el caso que fallaba para confirmar un fix. El regression testing reejecuta la suite mas amplia para confirmar que el fix no rompio nada mas. Los buenos equipos hacen ambos.

Con que frecuencia deben correr los regression tests?

Idealmente en cada pull request y cada commit a main via un pipeline de CI/CD, mas una pasada completa antes de cada release. Los chequeos caros suelen programarse de noche.

Se puede automatizar por completo el regression testing?

La regresion funcional, de integration, visual y de rendimiento casi siempre se automatiza. La regresion manual sigue siendo util para chequeos exploratorios y features nuevas sin cobertura automatizada estable.

Que es la regresion de rendimiento?

Reejecuta un load test contra cada build nuevo y compara latency, throughput y error rate con una baseline. Si el rendimiento se degrada mas alla de un umbral, el build falla.

Por que los regression tests se vuelven flaky, y por que importa?

La inestabilidad suele venir de suposiciones de timing, datos de test compartidos y servicios externos inestables. Importa porque un test que falla al azar erosiona la confianza en toda la suite.