La pirámide de pruebas: por qué no todo debe ser E2E

La respuesta corta es esta: no todo debe ser E2E porque una suite equilibrada tiene muchas pruebas unitarias rápidas, algunas de integración y muy pocas de extremo a extremo. Esa proporción, y no otra, es lo que hace que una suite corra en segundos, falle con precisión y merezca tu confianza. Cuando la inviertes, obtienes lo contrario: horas de espera y resultados en los que nadie cree.

Casi todo equipo que sufre con sus pruebas tiene el mismo problema estructural, aunque no lo sepa. No es que les falten pruebas. Es que las tienen en las proporciones equivocadas. Han construido la pirámide al revés.

01 · la formaQué dice la pirámide y por qué es una pirámide

La pirámide de pruebas es una idea que popularizó Mike Cohn y que la industria adoptó porque describe bien una tensión real. En la base van las pruebas unitarias: muchas, pequeñas, que verifican una función o una clase en aislamiento. En el medio, las de integración: menos, que comprueban que dos o más piezas hablan bien entre sí (tu código y la base de datos, tu servicio y una API). En la cúspide, las E2E (de extremo a extremo): poquísimas, que ejercitan el sistema completo como lo haría un usuario, desde el clic hasta la respuesta.

La forma no es decorativa. Es una pirámide porque las proporciones importan: mucho de lo barato y rápido, poco de lo caro y lento. Cada nivel que subes, las pruebas se vuelven más lentas de correr, más difíciles de escribir, más frágiles ante cualquier cambio y más vagas cuando fallan. Una unitaria que se rompe te señala la línea exacta. Una E2E que se rompe te dice que "algo, en algún lado, salió mal".

Cada nivel que subes cuesta más y te dice menos.

02 · el cono de heladoEl anti-patrón: cuando la pirámide se invierte

Ahora dale la vuelta a la figura. Base estrecha de unitarias, un poco de integración, y arriba una montaña ancha de E2E. Eso tiene nombre: el cono de helado (ice cream cone). Es el anti-patrón más común y casi nunca es una decisión consciente; se llega ahí por acumulación.

Pasa así. El equipo tiene prisa. Escribir una prueba E2E "se siente" más completa: abre el navegador, hace clic, comprueba que la pantalla muestra lo correcto. Parece que cubre todo de una sola vez, así que se escriben muchas y se descuidan las unitarias. Encima suele haber una capa de pruebas manuales por arriba de todo, hecha por personas, que es la más lenta y cara de todas.

El resultado se siente en carne propia:

• La suite tarda horas. Cada E2E arranca el sistema entero. Cientos de ellas convierten la validación en una espera de café largo, no de café corto.
• Las pruebas son intermitentes (flaky). Fallan y pasan sin que cambies nada, por una red lenta, un tiempo de espera, un elemento que tardó en cargar. La intermitencia es el veneno de la confianza.
• Nadie confía en el rojo. Cuando la mitad de los fallos son ruido, el equipo aprende a ignorar el rojo. Y una suite que se ignora no protege de nada.
• Cuando algo falla, no sabes dónde. Una E2E rota abarca veinte componentes. Depurarla es una cacería, no una lectura.

03 · las proporcionesCuánto de cada cosa: una regla de bolsillo

No hay una tabla sagrada, pero sí un orden de magnitud útil que muchos equipos usan como punto de partida: alrededor de 70 % unitarias, 20 % integración y 10 % E2E. No lo tomes como ley; tómalo como brújula. Un componente muy visual quizá necesite más E2E; una librería de cálculo casi solo necesita unitarias. Lo que no cambia es la jerarquía: la base siempre pesa más que la cúspide.

La pregunta correcta al escribir una prueba no es "¿qué nivel uso?", sino "¿cuál es el nivel más bajo que puede darme esta confianza?". Si un bug se puede cazar con una unitaria, cázalo con una unitaria. Reserva la E2E para lo que solo se puede verificar de extremo a extremo: que las piezas, juntas y en un entorno real, cumplen el flujo crítico del usuario.

Piénsalo como un presupuesto. Tu suite gasta tiempo de CI en cada corrida, y ese tiempo es dinero y, sobre todo, es velocidad de tu equipo. Cada minuto que una persona espera un resultado es un minuto sin desplegar. Las unitarias compran mucha confianza por muy poco tiempo. Las E2E compran poca confianza por mucho tiempo. Un buen QA administra ese presupuesto con la misma disciplina con la que administrarías dinero: invierte en lo barato y usa lo caro con criterio.

Usa el nivel más bajo que te dé la confianza que buscas. Ni uno más arriba.

Corregir el cono de helado no es tirar las E2E a la basura. Es al revés: es bajar las validaciones al nivel más barato posible y dejar arriba solo el puñado de flujos que de verdad importan. La suite adelgaza donde debe y engorda donde conviene. El día que tu CI vuelve a correr en minutos y el rojo vuelve a significar algo, sabes que la pirámide está parada sobre su base otra vez.

04 · el estándarPor qué esto también es una decisión de calidad, no solo de velocidad

Podría parecer que todo esto va de ir rápido. Va de algo más grande. La norma ISO/IEC 25010 define la calidad del software en atributos como fiabilidad y mantenibilidad. Una suite equilibrada sirve directamente a ambos: es fiable porque su rojo es señal y no ruido, y es mantenible porque cuando algo se rompe, te lleva a la causa en vez de a una cacería.

El ISTQB, en su cuerpo de conocimiento para probadores, insiste en que probar es una actividad de gestión de riesgo, no de acumulación. No se trata de tener más pruebas, sino las pruebas que reducen el riesgo que de verdad te preocupa, al menor costo. La pirámide es, en el fondo, esa idea hecha forma: pon el esfuerzo donde compra más certeza por menos tiempo.

Así que la próxima vez que alguien proponga "cubramos esto con otra prueba E2E", haz la pregunta de siempre: ¿es este el nivel más bajo que nos da la confianza que buscamos? Si la respuesta es no, tienes una unitaria esperando a ser escrita, y una pirámide que agradecerá quedarse de pie.