La pirámide de testing suele explicarse como si fuera una estructura fija:

• Unit tests abajo.
• Integration tests en el medio.
• E2E arriba.

Pero en la práctica, la forma real de esa pirámide no depende del testing.
Depende de la velocidad con la que el equipo libera software.

Cada test tiene un costo.
Costo de ejecución.
Costo de mantenimiento.
Costo de diagnóstico cuando falla.
Y ese costo vive dentro del pipeline.

Cuando un equipo libera software pocas veces al año, ese costo pasa desapercibido.

Hay tiempo para correr regresiones amplias, investigar fallos y ejecutar pruebas manuales extensas.

Pero cuando el equipo trabaja con CI/CD y libera software constantemente, la ecuación cambia.

La estrategia de testing correcta

• Cada minuto en el pipeline se multiplica por cada commit.
• Cada test frágil se convierte en ruido.
• Cada suite lenta se convierte en fricción para el equipo.

Por eso, en sistemas que necesitan velocidad de entrega, la estrategia de testing cambia.
La pirámide se vuelve más marcada:

• predominan unit tests
• se priorizan integration tests y API tests
• los E2E quedan reservados para validar flujos críticos

No porque los E2E sean malos, sino porque son los tests más caros de ejecutar, mantener y diagnosticar dentro de un pipeline.

Un E2E mal ubicado no solo tarda más.
Puede frenar merges, ralentizar feedback y aumentar el costo operativo de cada cambio.

La pirámide de testing no debería verse como un diagrama académico

Es una herramienta para equilibrar:

• velocidad de feedback
• costo de mantenimiento
• reducción real de riesgo

Pero hay algo más que muchas veces se pasa por alto.
Para decidir bien qué tipo de tests necesitamos, primero hay que entender qué partes del sistema realmente importan para el negocio.

No todos los flujos tienen el mismo impacto.
Un error en un reporte interno no tiene el mismo riesgo que un error en:

• un proceso de pago
• la generación de una factura
• el cálculo de un beneficio
• la creación de una orden

Cuando QA entiende el negocio, la estrategia de testing cambia.
La pirámide deja de ser un diagrama genérico y pasa a ser una herramienta para proteger lo que realmente importa.

Por eso la pregunta correcta no es:
¿Cuántos tests tenemos?
Ni siquiera:
¿Cuánto cuestan?
La pregunta correcta es:
¿Estamos protegiendo bien los flujos de mayor riesgo para el negocio sin frenar la velocidad del equipo?