Cuando auditamos el estado de QA de equipos nuevos, hay un patrón que se repite demasiado: una suite E2E gigante, casi sin unit tests, y un equipo con miedo de tocar código por temor a romper algo.
Ese miedo no es casualidad. Es una señal de que la estrategia de testing está invertida.
El patrón típico de una pirámide invertida
- 200+ pruebas E2E que tardan 40 o 50 minutos.
- Pocos unit tests o ninguno.
- Pruebas de integración escasas.
- Releases lentos y reintentos constantes en CI.
Cuando el feedback tarda casi una hora y además falla de forma aleatoria, la suite deja de dar confianza. Solo agrega fricción.
Cómo se ve una pirámide sana
No es dogma. Es economía operativa.
- 70% unit tests: validan lógica de negocio en milisegundos.
- 20% integration tests: validan contratos entre módulos/servicios.
- 10% E2E: validan solo flujos críticos de negocio.
La proporción puede variar por tipo de producto, pero el principio no cambia: mientras más abajo en la pirámide, más barato y rápido es el feedback.
Por qué importa de verdad
Un E2E test puede costar cientos de veces más en ejecución y mantenimiento que un unit test equivalente. Si usas E2E para validar lógica que podría estar en unit tests, estás pagando de más por la misma señal.
Ejemplo de costo oculto: si 10 devs esperan un pipeline de 50 minutos cinco veces al día, estás perdiendo más de 40 horas diarias solo en espera.
Por qué los equipos terminan aquí
- Los E2E se ven "más reales" y generan confianza visual rápida.
- Los unit tests obligan a tener código testeable (y eso exige disciplina).
- Nadie mide de forma explícita el costo acumulado de flakiness y tiempo en CI.
Cómo corregirlo sin romper el ritmo
No hace falta borrar todo ni empezar de cero. Funciona mejor por fases.
Fase 1: auditar y clasificar (1-2 semanas)
- Qué E2E cubren lógica que debería estar en unit tests.
- Qué tests tienen más flakiness en los últimos 30 días.
- Qué flujos críticos no tienen cobertura E2E.
Fase 2: frenar deuda nueva (inmediato)
Regla simple de equipo: lógica nueva se prueba primero en unit tests. E2E solo para flujos críticos de extremo a extremo.
Pregunta práctica: "Este bug lo detectaría un unit test?" Si la respuesta es sí, no debería entrar como E2E.
Fase 3: migrar progresivamente (mes 1-3)
- Prioriza tests más flaky.
- Prioriza tests más lentos.
- Prioriza tests que validan lógica aislable.
Con migrar una parte de los E2E redundantes, muchos equipos recortan de forma visible el tiempo de CI y mejoran estabilidad.
La pregunta correcta
No es cuántos tests tienes. Es qué nivel de confianza te dan y cuánto te cuesta mantener esa confianza.
Si tienes muchos tests pero sigues desplegando con miedo, el problema no es la herramienta: es la estrategia.
Checklist rápido
Si reconoces tres o más puntos, vale la pena auditar tu pirámide hoy:
- Tu pipeline tarda más de 20 minutos.
- Reejecutan CI sin cambios de código "a ver si pasa".
- Nadie sabe exactamente qué cubre cada E2E.
- Refactorizar se siente riesgoso.
- Los bugs en producción no bajan pese a tener más tests.
En QAAST hacemos auditorías de estrategia QA para identificar riesgo real y darte un plan concreto por sprints.
Agendar diagnóstico gratuito