La mayoría de proyectos de automatización que fracasan no lo hacen por la herramienta, sino por automatizar lo equivocado. Estas son las decisiones que conviene tomar antes de escribir la primera línea.
Define el objetivo de negocio
Reducir el tiempo de regresión, liberar más seguido o bajar defectos en producción. Cada objetivo lleva a una suite distinta.
Empieza por la base de la pirámide
Las pruebas unitarias y de API son más rápidas, estables y baratas que las E2E. Las de interfaz deben ser pocas y cubrir flujos críticos.
Elige por riesgo y frecuencia
Automatiza lo que se ejecuta en cada release y cuyo fallo es costoso: login, pago, alta de cliente.
Integra en CI desde el día uno
Una prueba que no corre automáticamente en cada cambio deja de mantenerse en semanas.
Mide y poda
Elimina o arregla los tests intermitentes de inmediato. Una suite en la que nadie confía no protege a nadie.
Qué no conviene automatizar
- Funcionalidades que cambian cada sprint.
- Validaciones visuales subjetivas o de experiencia de usuario.
- Escenarios que se ejecutan una sola vez.
- Pruebas exploratorias: su valor es precisamente que no están guionadas.
Indicadores de que funciona
| Indicador | Señal saludable |
|---|---|
| Tiempo de la suite en CI | Menos de 15 minutos para la suite de pull request |
| Tests intermitentes | Menos del 2 % de las ejecuciones |
| Defectos detectados por la suite | Crece al inicio y se estabiliza |
| Tiempo de regresión manual | Baja release a release |