TL;DR

  • Regression testing: Verificar que funcionalidad existente sigue funcionando después de cambios
  • Cuándo correr: Después de cada cambio de código, antes de releases, después de bug fixes
  • Objetivo clave: Detectar bugs introducidos por código nuevo que rompe funcionalidad vieja
  • Estrategia: Automatiza paths críticos, prioriza por riesgo, corre en CI/CD
  • Mejor práctica: Suites pequeños y enfocados superan suites masivos
  • ROI: Regresión automatizada habilita continuous delivery

Tiempo de lectura: 10 minutos

Regression testing es la red de seguridad que mantiene tu aplicación funcionando. Cada cambio de código tiene riesgo de romper algo que funcionaba antes — regression testing detecta estos problemas antes que los usuarios.

¿Qué es Regression Testing?

Regression testing verifica que funcionalidad que funcionaba previamente sigue funcionando después de cambios de código. El término “regresión” significa ir hacia atrás — cuando código nuevo causa que features viejas fallen.

Antes del cambio:   Login funciona ✓ | Checkout funciona ✓ | Search funciona ✓

Después del cambio: Login funciona ✓ | Checkout ROTO ✗ | Search funciona ✓
                                       ↑
                                       Bug de regresión

Tests de regresión re-ejecutan test cases existentes para detectar estas roturas.

Por qué Importa Regression Testing

1. Cambios de Código Rompen Cosas

Cada cambio introduce riesgo:

Tipo de CambioNivel de RiesgoEjemplo de Rotura
Nueva featureMedioRompe workflow existente
Bug fixMedioFix rompe feature relacionada
RefactoringAltoError lógico en código reescrito
Actualización dependenciaAltoCambio de API rompe integración

Incluso cambios pequeños pueden tener efectos secundarios inesperados.

2. La Complejidad Crece

A medida que las aplicaciones crecen, las interacciones se multiplican:

10 features  → ~45 interacciones potenciales
50 features  → ~1,225 interacciones potenciales
100 features → ~4,950 interacciones potenciales

Testing manual no puede cubrir todas estas interacciones consistentemente.

3. Releases Rápidos Necesitan Protección

Equipos modernos despliegan diaria o semanalmente. Sin regression testing:

Lunes:    Deploy feature A → Funciona
Martes:   Deploy feature B → Rompe feature A
Miércoles: Deploy fix → Rompe feature C
...

Regression testing provee confianza para releases frecuentes.

Cuándo Correr Tests de Regresión

Después de Cada Cambio de Código

En pipelines CI/CD, corre regression tests automáticamente:

# GitHub Actions
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run regression tests
        run: npm test

Detecta issues antes del merge.

Antes de Releases

Suite de regresión completo antes de deploys a producción:

Desarrollo → Smoke tests (rápido)
Pull Request → Core regression (medio)
Staging → Full regression (completo)
Production → Smoke tests (post-deploy)

Más crítico = testing más exhaustivo.

Después de Bug Fixes

Al arreglar bugs, regression tests verifican:

  1. El bug está realmente arreglado
  2. El fix no rompió nada más
// Bug: Usuarios no podían loguearse con caracteres especiales
// Después del fix, regression tests verifican:
test('login works with regular password', () => { ... });
test('login works with special characters', () => { ... }); // Nuevo test
test('logout still works', () => { ... }); // Regresión
test('password reset still works', () => { ... }); // Regresión

Tipos de Regression Testing

Regresión Correctiva

Re-ejecutar tests existentes sin modificación cuando cambios no alteran requisitos.

Cambio de código: Optimización de performance
Tests: Correr todos los tests existentes tal cual
Objetivo: Verificar que nada se rompió

Regresión Progresiva

Actualizar tests cuando requisitos cambian junto con código:

Cambio de código: Login ahora requiere 2FA
Tests: Modificar tests de login existentes + agregar nuevos
Objetivo: Verificar nuevo comportamiento + flujos viejos funcionan

Regresión Selectiva

Correr solo tests relacionados con áreas cambiadas:

Archivos cambiados: src/checkout/*
Correr tests: tests/checkout/* + tests/cart/*
Omitir: tests/profile/*, tests/search/*

Más eficiente para test suites grandes.

Regresión Completa

Correr todo el test suite. Usado para:

  • Releases mayores
  • Refactoring significativo
  • Después de largos períodos de desarrollo
# Correr suite completo antes de release
npm run test:regression -- --full

Construyendo un Regression Suite Efectivo

1. Empieza con Paths Críticos

Identifica qué debe siempre funcionar:

Paths críticos e-commerce:
✓ Registro y login de usuario
✓ Búsqueda y display de productos
✓ Agregar al carrito
✓ Checkout y pago
✓ Confirmación de orden

Testea esto primero y más exhaustivamente.

2. Prioriza por Riesgo

Tests de regresión de alta prioridad:

  • Features frecuentemente usadas
  • Funcionalidad crítica para ingresos
  • Áreas previamente con bugs
  • Integraciones complejas
describe('Alta Prioridad - Checkout', () => {
  test('completes purchase with credit card', () => { ... });
  test('applies discount code', () => { ... });
  test('calculates shipping correctly', () => { ... });
});

describe('Prioridad Media - Profile', () => {
  test('updates email address', () => { ... });
  test('changes password', () => { ... });
});

3. Mantén Tests Mantenibles

Tests de regresión deben ser confiables y fáciles de mantener:

// Bueno: Test claro y enfocado
test('checkout calculates total with tax', () => {
  const cart = createCart([
    { name: 'Shirt', price: 50 },
    { name: 'Pants', price: 75 }
  ]);

  const total = checkout.calculateTotal(cart, { taxRate: 0.1 });

  expect(total).toBe(137.50);
});

// Malo: Test poco claro y frágil
test('checkout', () => {
  const result = doCheckout(someData);
  expect(result).toBeTruthy();
});

4. Limpia el Suite Regularmente

Remueve o arregla tests que:

  • Son consistentemente flaky
  • Testean features obsoletas
  • Duplican otros tests
  • Proveen poco valor
Revisión trimestral:
- 500 tests → 450 conservados, 30 removidos, 20 arreglados
- Suite corre 15% más rápido
- Confiabilidad: 95% → 99%

Estrategias de Automatización

Pirámide de Tests para Regresión

Estructura tests de regresión por nivel:

        /\
       /  \     E2E Regresión (pocos)
      /----\    - User journeys críticos
     /      \   - Smoke tests
    /--------\
   /          \ Integration Regresión (medio)
  /            \ - Contratos API
 /______________\ - Interacciones de componentes

Unit Regresión (muchos)
- Lógica de negocio core
- Funciones utilitarias

Más tests rápidos, menos tests lentos.

Ejecución Paralela

Acelera regresión con paralelización:

# GitHub Actions jobs paralelos
jobs:
  test:
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - run: npm test -- --shard=${{ matrix.shard }}/4

4 shards paralelos = ~4x más rápido.

Selección Inteligente de Tests

Corre solo tests relevantes basados en cambios:

// jest.config.js
module.exports = {
  testPathIgnorePatterns: [],
  collectCoverageFrom: ['src/**/*.js'],
  // Solo correr tests relacionados con archivos cambiados
  onlyChanged: true,
};

O usa herramientas como jest --changedSince=main.

Regression Testing en CI/CD

Integración en Pipeline

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:unit

  integration-tests:
    runs-on: ubuntu-latest
    needs: unit-tests
    steps:
      - run: npm run test:integration

  regression-tests:
    runs-on: ubuntu-latest
    needs: integration-tests
    steps:
      - run: npm run test:regression

  deploy:
    needs: regression-tests
    if: github.ref == 'refs/heads/main'
    steps:
      - run: npm run deploy

Tests bloquean deployments.

Manejando Fallos

Cuando tests de regresión fallan:

  1. Bloquea el deployment — No envíes código roto
  2. Investiga inmediatamente — Contexto fresco ayuda al debug
  3. Arregla o revierte — No deshabilites el test
  4. Agrega cobertura — Prevén regresiones similares futuras
// Después de arreglar bug de regresión, agrega test específico
test('prevents XYZ regression (#1234)', () => {
  // Test específico para el bug encontrado
  const result = processOrder({ ...edgeCaseData });
  expect(result.status).toBe('success');
});

Desafíos Comunes

Desafío 1: Test Suites Lentos

Problema: Regresión completa toma demasiado tiempo

Soluciones:

  • Paraleliza tests
  • Corre subset en PRs, suite completo de noche
  • Optimiza tests lentos
Antes: 2 horas regression suite
Después: 15 min (PR) + 2 horas (nocturno)

Desafío 2: Tests Flaky

Problema: Tests pasan/fallan aleatoriamente

Soluciones:

  • Pon en cuarentena tests flaky
  • Arregla o remueve después de X fallos
  • Agrega retry con umbral de fallos
// jest-circus retry configuración
jest.retryTimes(2); // Retry tests fallidos hasta 2 veces

Desafío 3: Mantenimiento de Tests

Problema: Tests se rompen con cada cambio

Soluciones:

  • Usa selectores estables (data-testid)
  • Testea comportamiento, no implementación
  • Crea utilidades de test compartidas
// Frágil: Atado a implementación
expect(component.state.isLoading).toBe(false);

// Estable: Testea comportamiento
expect(screen.queryByText('Cargando...')).not.toBeInTheDocument();

FAQ

¿Qué es regression testing?

Regression testing verifica que funcionalidad existente continúa funcionando correctamente después de cambios de código. La palabra “regresión” significa ir hacia atrás — específicamente, detectar bugs donde funcionalidad que funcionaba se rompe debido a código nuevo, refactoring, bug fixes o actualizaciones de dependencias. Esencialmente es re-ejecutar test cases previos para asegurar que nada que funcionaba antes dejó de funcionar.

¿Cuándo debes correr tests de regresión?

Corre tests de regresión después de cada cambio significativo de código. En pipelines CI/CD, tests de regresión automatizados deben correr en cada pull request. Antes de releases, corre suites de regresión completos. Después de bug fixes, tests de regresión verifican que el fix funciona y no rompió funcionalidad relacionada. La frecuencia depende de la cadencia de releases — deployments diarios necesitan regresión automatizada en cada cambio.

¿Cómo crear un regression suite efectivo?

Empieza con paths críticos de usuario — features que deben siempre funcionar (login, checkout, workflows core). Prioriza tests por riesgo: features frecuentemente usadas, funcionalidad crítica para ingresos, y áreas históricamente con bugs. Mantén tests mantenibles con assertions claras y selectores estables. Regularmente limpia el suite removiendo tests flaky, obsoletos o de bajo valor. Suites pequeños y enfocados son más efectivos que suites masivos.

¿Debería automatizarse regression testing?

Automatización es esencial para regression testing efectivo. Regresión manual es lenta, propensa a errores y no escala. Un regression suite manual que toma 2 días significa que solo puedes testear exhaustivamente antes de releases mayores. Regresión automatizada corre en minutos, detecta issues inmediatamente y habilita continuous delivery. Automatiza paths críticos primero, luego expande cobertura con el tiempo.

Ver También