Pruebas de Humo vs Pruebas de Regresión: Cual es la Diferencia?

La mayoría de los equipos ejecuta toda su suite de Playwright después de cada deploy y lo llama regression testing. Cuando algo falla en producción a las 11pm, una suite de 45 minutos no es útil: necesitas 10 tests que confirmen que el login funciona, que la API responde y que la acción principal del usuario se completa. Este artículo cubre la diferencia de propósito entre smoke testing y regression testing, cómo etiquetar y estructurar ambos en una sola suite de Playwright, y cuándo ejecutar cada uno.

Smoke testing

Un smoke test responde una pregunta: ¿el sistema está funcionando fundamentalmente?

El nombre viene del testing de hardware: enciende un dispositivo, ve si humea. Pasas esa verificación y vale la pena hacer más pruebas. Fallas, y las pruebas más profundas no tienen sentido.

En software, un smoke test es un subconjunto pequeño y rápido de tests que verifica que los caminos más críticos están operacionales. Generalmente 10 a 20 tests, ejecutables en menos de 5 minutos.

Qué cubren los smoke tests

• La aplicación arranca y carga
• La autenticación funciona
• La acción más crítica del usuario se completa (realizar un pedido, enviar un formulario, hacer un pago)
• Los endpoints principales de la API responden

Qué no cubren los smoke tests

• Casos extremos
• Estados de error
• Funcionalidades secundarias
• Rendimiento bajo carga

Cuándo ejecutar smoke tests

• Después de cada deploy (incluso a producción)
• Después de cambios de infraestructura (reinicios de servidor, cambios de configuración)
• Como primer paso en CI, antes de que corra la suite completa
• Cuando necesitas una verificación rápida antes de una demo

Ejemplo de smoke test en Playwright

// smoke.spec.ts
import { test, expect } from '@playwright/test';

test.describe('@smoke', () => {
  test('la app carga', async ({ page }) => {
    await page.goto('/');
    await expect(page).toHaveTitle(/MyApp/);
    await expect(page.getByRole('navigation')).toBeVisible();
  });

  test('el login funciona', async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
    await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
    await page.getByRole('button', { name: 'Iniciar sesión' }).click();
    await expect(page).toHaveURL('/dashboard');
  });

  test('la API principal está respondiendo', async ({ request }) => {
    const response = await request.get('/api/health');
    expect(response.status()).toBe(200);
    const body = await response.json();
    expect(body.status).toBe('ok');
  });

  test('la realización de pedidos funciona de principio a fin', async ({ page }) => {
    // camino crítico abreviado
    await page.goto('/products');
    await page.getByRole('link', { name: 'Laptop Pro' }).click();
    await page.getByRole('button', { name: 'Añadir al carrito' }).click();
    await page.goto('/checkout');
    // ... pasos mínimos de checkout
    await expect(page.getByText('Pedido confirmado')).toBeVisible();
  });
});

Ejecutar solo smoke tests:

npx playwright test --grep @smoke

Regression testing

Una suite de regression testing verifica que la funcionalidad existente sigue funcionando después de un cambio. La preocupación no es "¿el sistema funciona en absoluto?", sino "¿rompimos algo que funcionaba antes?".

Los tests de regresión son más amplios y más lentos que los smoke tests. Una suite de regresión completa puede cubrir cientos de escenarios y llevar entre 20 y 60 minutos en ejecutarse.

Qué cubren los tests de regresión

• Todas las funcionalidades, incluyendo escenarios secundarios y casos extremos
• Manejo de errores
• Condiciones límite
• Comportamiento cross-browser
• Puntos de integración entre servicios

Cuándo ejecutar regression tests

• Antes de cada release
• Después de cambios significativos de código (nuevas funcionalidades, refactoring)
• En la rama principal después de merges de PR
• Nocturnamente para suites grandes

Tipos de regression testing

#### Regresión completa

Todos los tests de la suite. Se ejecuta antes de releases importantes.

#### Regresión parcial / dirigida

Tests en las áreas relacionadas con los cambios recientes. Se ejecuta con más frecuencia. Requiere saber qué tests cubren qué funcionalidades.

#### Regresión automatizada

Tu suite de Playwright. Corre en CI. La mayor parte de la cobertura de regresión.

#### Regresión exploratoria manual

Un QA engineer explorando las áreas con mayor probabilidad de ser afectadas por un cambio. Detecta lo que los tests automatizados no capturan.

Diferencias clave

| | Smoke Testing | Regression Testing |

|---|---|---|

| Propósito | ¿El sistema está vivo? | ¿Rompimos algo? |

| Alcance | Solo caminos críticos | Todas las funcionalidades |

| Velocidad | Rápido (2 a 5 min) | Lento (20 a 60+ min) |

| Frecuencia | Cada deploy | Antes de releases, después de cambios |

| Cantidad de tests | 10 a 30 tests | Cientos a miles |

| Acción ante fallo | Rollback o detener | Corregir antes del release |

Construir la división correcta

La mayoría de los equipos ejecuta toda su suite como regresión y no tiene una capa dedicada de smoke. Esto crea un problema: cuando despliegas a producción y algo falla, no puedes verificar rápidamente los caminos críticos porque tu suite de regresión completa de 45 minutos no es la herramienta adecuada.

Una mejor estructura:

@smoke (ejecutar en cada deploy, máximo 5 min)
├── La app carga
├── La auth funciona
├── La funcionalidad principal se completa

@regression (ejecutar antes del release, 30-60 min)
├── Tests @smoke (incluidos)
├── Todos los demás tests de funcionalidades
├── Casos extremos
└── Cross-browser

Etiqueta tus tests más críticos con @smoke. Ejecútalos después de cada deploy. Ejecuta la suite completa antes de cada release.

Qué no es regression testing

Tests unitarios

Verifican funciones aisladas. No son tests de regresión en el sentido de QA, son tests de desarrolladores.

Tests de performance

Miden velocidad y capacidad, no corrección funcional.

Smoke testing

Como se explicó antes, tiene un alcance y propósito diferentes.

Testing exploratorio

Descubrimiento sin guión de bugs nuevos, no verificación de comportamiento existente.

La confusión viene de sobrecargar la palabra "regresión": en el uso común, cualquier test automatizado que corre después de un cambio se llama test de regresión. En el uso formal, el regression testing significa específicamente verificar que la funcionalidad que funcionaba antes sigue funcionando.

Ambos usos están bien en la práctica. Lo que importa es tener claro qué estás verificando y por qué.