Glosario · Fundamentos de testing
Pruebas de regresión
En inglés: Regression testing
También llamado: regression test, prueba de regresión, test de regresión, suite de regresión
Definición
Volver a ejecutar los tests existentes tras un cambio para confirmar que lo que ya funcionaba sigue funcionando y que la corrección o la funcionalidad no rompió nada más.
Las pruebas de regresión comprueban que un cambio no ha roto algo que antes funcionaba. Una “regresión” es una funcionalidad que funcionaba en un build anterior y ya no lo hace. Se detecta volviendo a ejecutar los tests del comportamiento existente después de cada corrección de bug, nueva funcionalidad, refactorización, actualización de dependencias o cambio de configuración.
Ejemplo
Un equipo añade la opción “pagar con tarjeta regalo” al checkout. La nueva funcionalidad recibe sus propios tests. Las pruebas de regresión se hacen otra pregunta: ¿los pagos con tarjeta, los códigos de descuento, el cálculo de impuestos y los correos de pedido siguen comportándose exactamente igual que antes? Un cambio compartido en el módulo de cálculo de precios podría romper fácilmente cualquiera de ellos sin tocar la nueva ruta de código.
Elegir qué ejecutar
Ejecutar todos los tests en cada commit es la estrategia más sencilla y, con una suite automatizada rápida, suele ser la correcta. Cuando la suite completa es demasiado lenta o en parte manual, los equipos seleccionan:
- Por riesgo. Los flujos críticos para el negocio (registro, pago, exportación de datos) se ejecutan siempre.
- Por impacto. Las áreas que comparten código, datos o servicios con el cambio.
- Por historial. Los módulos que ya han sufrido regresiones tienden a volver a sufrirlas.
Un reparto habitual es un subconjunto rápido de regresión en cada pull request y la suite completa cada noche o antes de una release.
Por qué es lo primero que automatizan los equipos
Los tests de regresión ejecutan los mismos pasos contra los mismos resultados esperados una y otra vez, que es exactamente en lo que destaca la automatización. La regresión manual crece con cada release mientras el tiempo disponible no, así que es lo primero que se recorta. Una suite de regresión automatizada en CI convierte “¿hemos roto algo?” de una semana de comprobaciones manuales en el resultado de un pipeline.
Errores comunes
- Tratar la suite como algo a lo que solo se añade. Los tests obsoletos y duplicados ralentizan cada ejecución. Revisa y poda.
- Tolerar tests flaky. Si los fallos se reejecutan sistemáticamente hasta ponerse en verde, las regresiones reales también desaparecen a base de reejecutar.
- Probar solo a través de la UI. La mayor parte de la cobertura de regresión es más barata y estable a nivel unitario y de API.