Load, Stress, Soak y Spike Testing: cuál corrés antes de tu próximo Black Friday

“Corrimos una prueba de carga” no dice nada. ¿La corriste con el tráfico promedio que esperás, o con el doble? ¿La sostuviste diez minutos o seis horas? ¿Simulaste una rampa gradual o una explosión de tráfico sin aviso? Cada una de esas preguntas define un tipo de prueba distinto, con un objetivo distinto y una falla distinta que expone. Confundirlos no es un detalle semántico — es la diferencia entre llegar a Black Friday con datos reales o con la ilusión de que “ya probamos”.

Qué es cada tipo de prueba de carga

Load, stress, soak y spike son cuatro perfiles de carga distintos, cada uno diseñado para exponer un tipo de falla distinto — no son sinónimos intercambiables de “probamos con tráfico”.

• Load testing (o average-load testing): mide cómo se comporta el sistema bajo el tráfico que esperás en un día normal. El perfil sube gradualmente hasta el volumen típico de usuarios, lo sostiene un rato, y baja. Responde: “¿aguanta un día común?”
• Stress testing: mide qué tan estable es el sistema cuando la carga supera lo normal — a veces un poco más, a veces 50-100% más, según el escenario de riesgo que estés evaluando — sostenido entre 5 y 60 minutos con una rampa gradual. Responde: “¿cuánto por encima de lo normal aguanta antes de degradarse?”
• Soak testing (o endurance testing): mide qué le pasa al sistema bajo carga normal sostenida durante horas o incluso días. No busca el punto de quiebre, busca fugas de memoria y degradación lenta que solo aparecen con el tiempo. Responde: “¿aguanta un día normal… sostenido toda una semana?”
• Spike testing: mide la resiliencia del sistema ante un pico de tráfico repentino y extremo, con poca o ninguna rampa de subida, sostenido apenas un par de minutos. Responde: “¿sobrevive si mañana nos viralizamos sin aviso?”

Por qué importa: casi nadie corre los cuatro

Importa porque cada tipo de prueba que no corrés es un escenario de falla que vas a descubrir en producción, no en un ambiente controlado — y en una fecha de pico como Black Friday, ese descubrimiento sale caro.

Fuentes: encuesta de Google Cloud citada por Retail Dive; caso documentado por Rewind (datos de Shopify).

La mayoría de los equipos que “prueban antes de Black Friday” corre exactamente uno de los cuatro: load testing con el tráfico esperado. Es necesario, pero no explica por qué un sistema que pasó ese test igual se cae — porque la falla real no vivía en el escenario que se probó. El caso del retailer de indumentaria deportiva es literal: 8 horas de caída en Black Friday 2015 le costaron unos 143.000 dólares en ventas, con un proveedor externo integrado como causa — exactamente el tipo de punto de quiebre que un stress test, no un load test, está diseñado para encontrar antes de que pase en vivo.

Por qué correr el tipo equivocado te deja ciego

Te deja ciego porque un mismo sistema puede pasar perfecto un load test y caerse igual en Black Friday, por una razón que ese test nunca estuvo diseñado para encontrar.

1. Un load test a tráfico promedio no dice nada sobre 2x o 5x tráfico — ese dato solo lo da un stress test, y es justo el escenario de Black Friday.
2. Black Friday ya no es un día, es una semana (Cyber Week). Sin soak testing, una fuga de memoria que tarda seis horas en manifestarse pasa inadvertida en un test de veinte minutos y aparece recién en producción, a mitad de la semana de mayor venta.
3. Una campaña de email o una mención viral no siguen ninguna rampa gradual — ese es exactamente el escenario que un spike test reproduce y un load test no.
4. No es un problema de tooling, es un problema de criterio. La mayoría de los equipos ya tiene k6, JMeter o Gatling instalado. Lo que falta no es la herramienta — es correr los cuatro perfiles sobre el flujo crítico, no solo el primero.

Cómo lo hacemos: cuatro perfiles, un mismo script

Con k6, los cuatro tipos de prueba son la misma herramienta con distintos scenarios — no hace falta reescribir el test, solo el perfil de carga:

import http from 'k6/http';
import { sleep, check } from 'k6';

export const options = {
  scenarios: {
    // Load / average-load: tráfico típico, sostenido, rampa suave
    load: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 500 },
        { duration: '10m', target: 500 },
        { duration: '2m', target: 0 },
      ],
    },
    // Stress: bien por encima de lo normal, buscando el punto de quiebre
    stress: {
      executor: 'ramping-vus',
      startVUs: 0,
      startTime: '15m', // corre después de "load"
      stages: [
        { duration: '5m', target: 1500 },  // ~3x el tráfico típico
        { duration: '20m', target: 1500 },
        { duration: '5m', target: 0 },
      ],
    },
    // Soak: carga normal sostenida por horas — busca fugas, no picos
    soak: {
      executor: 'constant-vus',
      vus: 500,
      duration: '4h',
      startTime: '45m',
    },
    // Spike: sin rampa, todo de golpe — la campaña de email o el post viral
    spike: {
      executor: 'ramping-vus',
      startVUs: 0,
      startTime: '4h45m',
      stages: [
        { duration: '30s', target: 3000 }, // 6x el tráfico típico, sin aviso
        { duration: '3m', target: 3000 },
        { duration: '30s', target: 0 },
      ],
    },
  },
};

export default function () {
  const res = http.get('https://tu-tienda.ejemplo.com/checkout');
  check(res, { 'checkout responde 200': (r) => r.status === 200 });
  sleep(1);
}

Lo que cambia entre los cuatro no es el request que se prueba, es cuánta gente, con qué rampa y durante cuánto tiempo. Correr los cuatro sobre el mismo flujo crítico —login, carrito, checkout— es lo que separa “probamos” de “sabemos exactamente dónde se rompe y cuándo”.

Si tu próximo evento de tráfico alto es Black Friday, un lanzamiento o una campaña con pico esperado, y tu última prueba de carga fue “levantamos el tráfico normal y no se cayó”, ese es exactamente el tipo de brecha que cerramos con proyectos de performance engineering a medida.

Fuentes

• Types of Load Testing — Grafana k6
• Will retailers avoid Black Friday website outages? — Retail Dive
• Black Friday Cyber Monday downtime case study — Rewind