Que Es el Testing de Regresion?
El testing de regresion verifica que funcionalidad de software previamente funcional no se ha roto por cambios recientes. Cada vez que se modifica codigo — nuevos features, bug fixes, actualizaciones de configuracion — hay riesgo de romper algo que funcionaba. La regresion detecta estos efectos secundarios no deseados.
El termino “regresion” significa retroceder. Una regresion de software es cuando una funcion que funcionaba en la version 1.0 deja de funcionar en la 1.1.
Considera un carrito de compras. La version 1.0 maneja productos, cantidades y totales correctamente. En la 1.1, se agrega codigos de cupon. Ahora el calculo total es incorrecto — el descuento se aplica dos veces. El feature de cupones funciona, pero el calculo original ha regresionado. La regresion habria detectado esto.
Por Que Es Esencial
Los Cambios de Codigo Tienen Efectos en Cadena
El software moderno esta interconectado. Un cambio en un modulo puede afectar modulos aparentemente no relacionados.
El Costo de Regresiones en Produccion
Una regresion detectada en testing cuesta horas. La misma en produccion cuesta dias o semanas — mas confianza del cliente y soporte.
Las Suites Crecen Con el Tiempo
Cada feature nuevo agrega casos. Cada bug fix agrega un chequeo de regresion. Sin un enfoque estructurado, la calidad se degrada.
Estrategias de Seleccion de Tests
Retest All
Ejecutar toda la suite. Maximo para releases mayores. Lento pero completo.
Seleccion por Prioridad
P1 = critico, P2 = alto, P3 = medio, P4 = bajo. Ejecutar los mas altos primero cuando el tiempo es limitado.
Seleccion Basada en Riesgo
Seleccionar tests basados en probabilidad de falla e impacto.
Factores de riesgo: Cercania al cambio, historial de bugs, criticidad del feature, complejidad, tiempo desde ultima prueba.
Seleccion Basada en Cambio
Solo ejecutar tests que ejerciten rutas de codigo afectadas. Eficiente pero requiere herramientas de cobertura.
Automatizando la Regresion
La regresion manual no escala. Lo que toma 2 horas hoy tomara 20 horas el proximo ano.
Que Automatizar Primero
- Smoke tests — verificaciones de ruta critica
- Regresion de alta prioridad — features de ingresos y datos sensibles
- Tests frecuentes — escenarios de cada release
- Features estables — areas que rara vez cambian
- Tests data-driven — muchas combinaciones de entrada
Que Mantener Manual
- Testing exploratorio
- Testing de usabilidad
- Features que cambian frecuentemente
- Tests unicos
Mantenimiento de la Suite
Agregar tests por cada bug fix. Cada bug corregido obtiene un test de regresion para prevenir recurrencia.
Eliminar tests obsoletos. Features eliminados o rediseñados — eliminar tests correspondientes.
Corregir tests inestables inmediatamente. Tests que fallan aleatoriamente entrenan al equipo a ignorar fallas.
Revisar y refactorizar regularmente. Como codigo de produccion, el codigo de tests necesita refactorizacion.
Ejercicio: Prioriza una Suite de Regresion con Seleccion Basada en Riesgo
Eres QA Lead para una aplicacion bancaria. El sprint incluyo:
- Cambio 1: Actualizacion del algoritmo de calculo de intereses
- Cambio 2: Nuevo tema “Modo Oscuro”
- Cambio 3: Fix de bug en email de reseteo de contrasena
Tu suite tiene 200 tests. Tienes tiempo para ejecutar 80 (40%). Selecciona areas y justifica.
| Area | Tests | Ultima Prueba | Tasa de Bugs |
|---|---|---|---|
| Saldo de Cuenta | 25 | 2 semanas | Baja |
| Transferencias | 30 | 1 semana | Media |
| Calculo de Intereses | 20 | 3 meses | Alta |
| Solicitud de Prestamo | 15 | 1 mes | Baja |
| Pago de Servicios | 20 | 2 semanas | Media |
| Autenticacion | 25 | 1 semana | Baja |
| Reseteo de Contrasena | 10 | 3 meses | Media |
| UI/Accesibilidad | 15 | 1 mes | Baja |
| Reportes | 20 | 2 meses | Media |
| App Mobile | 20 | 1 mes | Alta |
Pista
Mapea cada cambio a su area de riesgo. Considera: que tests estan directamente relacionados? Que areas tienen alta tasa de bugs? Cuales no se han probado recientemente? Cuales son mas criticas?Solucion
Debe Probar (directamente afectados):
- Calculo de Intereses: 20/20 (100%) — Cambio 1 directo. Alta tasa bugs. 3 meses sin probar. Critico financiero.
- Reseteo de Contrasena: 10/10 (100%) — Cambio 3 directo. Verificar fix y efectos secundarios.
- UI/Accesibilidad: 10/15 (67%) — Cambio 2 agrego Modo Oscuro.
Alto Riesgo (indirectamente afectados):
- Transferencias: 15/30 (50%) — Transaccion financiera. Calculo de intereses puede afectar.
- Saldo de Cuenta: 15/25 (60%) — Cambios de intereses afectan balances directamente.
Riesgo Medio:
- Autenticacion: 5/25 (20%) — Reset de contrasena es parte del flujo de auth.
- Reportes: 5/20 (25%) — Cambios de intereses afectan calculos de estados de cuenta.
Total: 80 tests
No seleccionados: Solicitud de Prestamo (0), Pago de Servicios (0), App Mobile (0) — bajo riesgo para este sprint.
Regresion en CI/CD
5 min] SMOKE --> UNIT[Unit
3 min] UNIT --> INT[Integracion
15 min] INT --> FAST[Regresion Rapida
P1, 30 min] FAST --> DEPLOY[Deploy Staging] DEPLOY --> FULL[Regresion Completa
Nocturna, 4 hrs]
Tips Profesionales
Tip 1: Tu suite de regresion es tu poliza de seguro. Cada test es una garantia de que algo funciona. Saltar regresion es como cancelar tu seguro.
Tip 2: Mide efectividad. Cuantos bugs detecta tu suite por release? Si detecta cero por varios releases, necesita actualizacion.
Tip 3: Usa analisis de impacto. Herramientas modernas analizan cambios de codigo e identifican automaticamente que tests ejecutar.
Conclusiones Clave
- La regresion verifica que funcionalidad existente sigue funcionando despues de cambios
- Cuatro estrategias: Retest All, Prioridad, Riesgo, Cambio
- Seleccion basada en riesgo ofrece mejor balance de cobertura y eficiencia
- La automatizacion es esencial — la regresion manual no escala
- Mantener la suite: agregar tests por fixes, eliminar obsoletos, arreglar inestables
- Integrar en CI/CD para aseguramiento continuo de calidad