Automatización como herramienta, no como destino
Sin estrategia, solo estás corriendo scripts. La automatización es un medio, no el fin.
2,347 tests. 78% de cobertura. Suite que tarda 45 minutos.
Y nadie confía en ella.
He visto esta historia repetirse. Equipos que miden éxito por cantidad de tests automatizados, sin preguntarse: ¿estos tests nos dan confianza para deployar?
La automatización sin estrategia es solo código que corre solo.
La trampa del coverage
80% de cobertura suena impresionante hasta que analizas qué cubre:
- Happy paths ✓
- Casos nominales ✓
- Edge cases que rompen producción ✗
- Flujos de error complejos ✗
El 80% que tienes testea lo que siempre funciona. El 20% que falta es donde viven los bugs.
Cuándo automatizar
Automatiza cuando:
- El test correrá frecuentemente (CI/CD, regresión)
- El resultado es determinístico (no depende de timing, orden, estado externo)
- Mantenerlo cuesta menos que ejecutarlo manualmente
No automatices cuando:
- Estás explorando funcionalidad nueva (primero entiende, luego automatiza)
- El comportamiento cambia cada sprint
- Requiere juicio humano: "¿esto se ve bien?", "¿la UX tiene sentido?"
La pirámide no es dogma
/\ Pocos E2E (críticos, lentos, caros)
/ \
/----\ Más integración (contratos, boundaries)
/ \
/--------\ Muchos unit (rápidos, aislados)
Pero hay contextos donde más E2E tiene sentido. MVPs. Aplicaciones pequeñas. El punto no es seguir la pirámide. Es tener una razón para tu distribución.
Mi regla
Antes de automatizar cualquier test, pregunto:
¿Qué riesgo mitiga esto? ¿Qué decisión me permite tomar con confianza?
Si no puedo responder, probablemente no vale la pena automatizarlo todavía.
La automatización amplifica lo que ya tienes. Si tienes estrategia, amplifica valor. Si no la tienes, amplifica caos.