¿Qué es regression testing?

¿Qué es regression testing?

Regression testing es la práctica de reejecutar tu test suite existente contra cada cambio de código para confirmar que nada que antes funcionaba se ha roto. La palabra "regresión" significa un paso atrás: una feature que pasó ayer y falla hoy. Los regression tests cazan esos pasos atrás antes de que lleguen a usuarios.

Cada bug entregado se convierte en la semilla de un regression test. El fix aterriza con un test nuevo que reproduce el bug, y desde entonces la suite afirma que ese bug nunca vuelve. A lo largo de años, la regression suite se convierte en la memoria ejecutable de cada defecto que el equipo ha pagado.

Regression testing vs smoke testing vs QA completo

Tres capas, scope creciente:

• Smoke testing: segundos. ¿Arrancó el build? 5-15 checks de critical-path. Solo gate.
• Regression testing: minutos a una hora. ¿Se rompió algo que antes funcionaba? Cientos a miles de tests cubriendo cada feature entregada.
• QA completo / acceptance: horas, a menudo manual. ¿Cumple cada flow la spec para el próximo release? Incluye checks exploratorios + manuales.

Regression se sienta en medio y es el tipo de test en el que la mayoría de equipos más invierten, porque es automatizable, repetible y gatea cada merge.

Funcional vs visual vs regression de rendimiento

• Regression funcional. Tests unit, integration, end-to-end. "Añadir al carrito sigue añadiendo un item." La mayoría de cualquier regression suite.
• Regression visual. Comparación de screenshot; los diffs de píxeles marcan cambios no intencionados de CSS o layout. Tools: Percy, Chromatic, toHaveScreenshot() de Playwright.
• Regression de rendimiento. p95 latency a carga esperada no debe degradarse entre releases. Ejecuta un load test contra el baseline y el build nuevo; afirma que latency, throughput y error rate no empeoraron. Fácil de saltar y lo primero que muerde en producción.

Cuándo ejecutar regression tests

1. En cada pull request. Antes del merge. El PR no mergea a menos que regression pase.
2. En cada commit a main. Caza issues de integración de PRs concurrentes que pasaron individualmente.
3. Pre-release. Un run completo de regression contra el release candidate antes del deploy. A menudo más lento / más exhaustivo que el run per-PR.
4. Nocturno. Las partes caras de la suite (tests browser, regression de rendimiento, integración de larga duración) corren de noche sin bloquear el flow del desarrollador.

Prácticas clave de regression testing

1. Cada bug arreglado obtiene un test. El fix y el regression test aterrizan en el mismo commit. Sin excepciones.
2. Los tests son determinísticos. Tests regression flaky entrenan al equipo a ignorar fallos. Elimina suposiciones de timing, mockea servicios externos, arregla o borra flakes en una semana.
3. Los tests corren rápido. Un run completo de regression que bloquee PRs debería terminar en menos de 10 minutos; si no, los desarrolladores cambian de contexto y pierden flow. Paraleliza.
4. El rendimiento es parte de regression. Un load test en CI/CD con aserciones sobre p95 + error rate caza el drift lento que los tests funcionales pierden.

Cómo ejecutar regression de rendimiento

Toma el mismo script que usas para load testing y ejecútalo contra tanto el build baseline como el build nuevo a carga idéntica. Compara p95, p99, throughput y error rate.

En JMeter, guarda el output JTL y diff las métricas agregadas. En k6, usa thresholds en el script: http_req_duration: ['p(95)<800'] falla el build cuando p95 excede 800 ms. Los thresholds fallidos fijan el exit code, así CI caza la regresión automáticamente.

Para carga multi-región contra un edge real de CDN, ejecuta desde LoadFocus. La regression de rendimiento que corrió desde una sola máquina local pierde regresiones en rutas geo-distribuidas (DNS, edge cache, failover regional de BD).

Si tu equipo no tiene tiempo para construir regression de rendimiento en CI, LoadFocus ofrece load testing services donde los ingenieros diseñan los escenarios de regresión, los cablean en tu pipeline y triajean fallos contra baselines históricos.