Cuando empiezas a aprender QA, todo parece igual de importante — los tests unitarios, los E2E, los de integración. La pirámide de testing es el concepto que ordena ese caos y te ayuda a entender cuánto de cada tipo necesitas y por qué.
En este artículo te lo explico desde cero con ejemplos reales.
Qué es la pirámide de testing
La pirámide de testing es un modelo visual que describe cómo debería distribuirse el esfuerzo de testing en un proyecto de software. La introdujo Mike Cohn en su libro Succeeding with Agile y desde entonces se ha convertido en uno de los conceptos más referenciados en el mundo del QA.
La idea es simple: imagina una pirámide dividida en tres niveles. En la base están los tests más numerosos, rápidos y baratos. En la cima están los tests más escasos, lentos y costosos. Y en el medio, un nivel intermedio que conecta los dos extremos.
Cada nivel representa un tipo de prueba diferente y la altura en la pirámide indica cuántos tests de ese tipo deberías tener en tu proyecto.
Los tres niveles de la pirámide
Base — Tests unitarios
Los tests unitarios son los que más deberías tener. Verifican que una función o componente individual del código funciona correctamente de forma aislada, sin depender de otros sistemas.
Son los tests más rápidos de ejecutar — pueden correr miles en segundos. Son los más baratos de mantener porque son pequeños y específicos. Y cuando fallan, indican exactamente dónde está el problema.
En la práctica, los tests unitarios los escriben principalmente los desarrolladores. Pero un QA Engineer debe entender cómo funcionan y qué cubren para saber qué queda fuera de su cobertura.
Ejemplo: una función que calcula el precio total de un carrito de compra. Un test unitario verifica que dados tres productos con sus precios, la función devuelve la suma correcta.
Nivel medio — Tests de integración
Los tests de integración verifican que dos o más componentes del sistema funcionan correctamente juntos. No prueban una función aislada — prueban la comunicación entre partes.
Son más lentos que los unitarios porque implican más componentes. Son más costosos de mantener porque cuando algo cambia en cualquiera de los componentes integrados, el test puede verse afectado.
Deberías tener menos tests de integración que unitarios, pero más que E2E.
Ejemplo: verificar que cuando un usuario añade un producto al carrito, el sistema de inventario actualiza correctamente el stock disponible. Aquí intervienen dos componentes — el carrito y el inventario — y el test verifica que se comunican bien.
Cima — Tests E2E
Los tests end-to-end verifican flujos completos de la aplicación desde el punto de vista del usuario, pasando por todas las capas del sistema. Son los que escribes con Playwright.
Son los más lentos de ejecutar porque lanzan un navegador real y recorren toda la aplicación. Son los más costosos de mantener porque cuando la interfaz cambia hay que actualizarlos. Y cuando fallan, a veces es difícil identificar exactamente dónde está el problema.
Por eso deberías tener pocos tests E2E — solo los suficientes para cubrir los flujos más críticos del negocio.
Ejemplo: verificar que un usuario puede registrarse, iniciar sesión, añadir un producto al carrito y completar el pago. Todo el flujo de principio a fin.
Por qué la pirámide importa en la práctica
La pirámide no es solo un modelo teórico — tiene consecuencias prácticas muy concretas en cómo se diseña una estrategia de testing.
Si inviertes la pirámide — muchos tests E2E y pocos unitarios — tu suite de tests será lenta, cara de mantener e inestable. Cada pequeño cambio en la interfaz puede romper decenas de tests. El feedback que recibe el equipo tarda mucho en llegar.
Si sigues la pirámide correctamente — muchos unitarios, algunos de integración y pocos E2E — tienes una suite rápida, estable y fácil de mantener. El feedback es inmediato. Los problemas se detectan en el nivel más bajo posible, donde son más fáciles y baratos de corregir.
La distribución recomendada
No hay una regla fija pero la distribución típica en proyectos maduros es aproximadamente esta:
70% tests unitarios — la base sólida que cubre la lógica del negocio a nivel de código.
20% tests de integración — verifican que los componentes se comunican correctamente.
10% tests E2E — cubren los flujos más críticos desde el punto de vista del usuario.
Esta distribución puede variar según el tipo de proyecto. Una aplicación con mucha lógica de negocio compleja necesitará más unitarios. Una aplicación principalmente de interfaz puede necesitar más E2E.
La pirámide y el rol del QA Engineer
En equipos modernos, la responsabilidad de los tests se distribuye así:
Los tests unitarios los escriben principalmente los desarrolladores. Los tests de integración los escriben desarrolladores y QA trabajando juntos. Los tests E2E los lidera el equipo de QA.
Un QA Engineer que entiende la pirámide puede tomar mejores decisiones sobre qué automatizar y a qué nivel. Si algo se puede verificar con un test unitario, no tiene sentido duplicarlo con un test E2E más lento y más frágil.
El antipatrón: el cono de helado
El opuesto de la pirámide es lo que se conoce como el cono de helado — muchos tests manuales y E2E en la cima, y casi nada en la base.
Es el patrón más habitual en equipos sin una estrategia de testing definida. Todo se prueba manualmente o con tests E2E, los ciclos de testing son lentos, los bugs llegan tarde y el equipo tiene poco margen para iterar rápido.
Reconocer este antipatrón y proponer mejoras es algo que diferencia a un QA Engineer con criterio de uno que solo ejecuta lo que le dicen.
Cómo aplicar la pirámide en un proyecto real
Si llegas a un proyecto sin estrategia de testing definida, estos son los pasos para aplicar la pirámide de forma progresiva.
Primero evalúa qué tests existen ya y de qué tipo son. Si hay muchos E2E y pocos unitarios, tienes un cono de helado que hay que invertir gradualmente.
Luego identifica los flujos más críticos del negocio y asegúrate de que están cubiertos con tests E2E. Son pocos pero imprescindibles.
Después trabaja con los desarrolladores para ir añadiendo tests unitarios en las áreas con más bugs históricos o más lógica de negocio compleja.
Finalmente añade tests de integración en los puntos de comunicación entre componentes más críticos.
No hace falta hacerlo todo a la vez. La pirámide es un objetivo a largo plazo, no algo que se consigue en un sprint.
Si quieres saber más sobre cómo se relaciona la pirámide con los tests E2E puedes leer qué es un test E2E y cómo funciona. Y si quieres entender cómo encaja todo esto en un equipo ágil puedes leer cómo funciona el QA en Scrum.
Si necesitas ayuda para definir la estrategia de testing de tu proyecto puedes ver mis servicios en fatimaqa.com.