James Valencia
← Blog
2 min de lectura

La pirámide de pruebas no es un dibujo, es una decisión de costos

QAautomatizaciónpruebas

Cuando alguien nuevo entra a un equipo de calidad, casi siempre ya vio la pirámide de pruebas en algún lado: un triángulo con "unitarias" abajo, "integración" en el medio y "E2E" arriba. La mayoría la trata como un póster. Yo la trato como una hoja de costos.

Cada capa de esa pirámide tiene un precio distinto — no solo en tiempo de ejecución, sino en cuánto se rompe cuando el código cambia. Tocá cada capa:

Capa seleccionada

Unitarias

Costo de mantenerla
Bajo
Velocidad de ejecución
Milisegundos
Cobertura típica
Reglas de negocio, caso por caso
Fragilidad
Baja — aísla una sola unidad de lógica

Por qué el ancho importa

El ancho de cada capa no es estético. Representa cuánta prueba deberías tener ahí, y esa proporción sale directo de la fragilidad:

  • Una prueba unitaria falla solo cuando la lógica que prueba cambió. Corre en milisegundos. Podés tener miles.
  • Una prueba de integración falla cuando cambia el contrato entre dos módulos — más señal, pero también más costo de mantenerla viva.
  • Una prueba E2E falla por cualquier cosa: un selector de UI que se movió, un timeout de red, un dato de prueba que otro test ya modificó. Es la que más confianza da y la que más caro sale sostener.

Cuidado

El error más común que veo en equipos nuevos no es tener pocas pruebas E2E — es tener demasiadas, porque dan la sensación más directa de "esto funciona". Esa sensación se paga en minutos de pipeline y en falsos negativos cada semana.

Un caso concreto

Así se ve, en un framework de API sobre Postman, la diferencia entre verificar solo el status code y verificar el contrato completo:

pm.test("status 200", () => {
  pm.response.to.have.status(200);
});
// Pasa aunque la respuesta venga vacía, mal tipada o
// con un campo renombrado. No prueba el contrato real.

El segundo test es una prueba de integración, no una E2E — corre en segundos, no en minutos, y falla por la razón correcta: el contrato cambió, no porque un botón se movió tres píxeles.

La pregunta que reemplaza al póster

La próxima vez que alguien proponga "agreguemos un test E2E para esto", la pregunta útil no es si el caso importa. Casi siempre importa. La pregunta es: ¿esto necesita confirmar que el sistema completo funciona junto, o alcanza con confirmar que esta pieza cumple su contrato? La mayoría de las veces, alcanza con lo segundo — y sale más barato mantenerlo vivo.