IA en automatización: copiloto, no piloto
La IA puede escribir tests, pero no puede decidir qué testear. Ahí está la diferencia.
Le pedí a un LLM que escribiera tests para una función de login.
Me generó 15 tests en 30 segundos. Cobertura perfecta del happy path. Validaciones de campos. Manejo de errores básico.
Le faltó uno: el test que valida qué pasa cuando el usuario está en dos dispositivos y cambia su contraseña en uno. Ese test requiere entender el negocio, no el código.
La IA puede escribir tests. No puede decidir qué vale la pena testear.
Lo que delego a la IA
- Boilerplate: Setup, mocks, fixtures, estructura inicial
- Traducción spec→código: "Dado un usuario logueado, cuando hace X..."
- Refactoring: Limpiar tests existentes, reducir duplicación
- Edge cases obvios: Nulls, strings vacíos, límites numéricos
Esto acelera mi trabajo un 40%. Es real.
Lo que no delego
- Decidir qué es crítico testear: Eso requiere contexto de negocio
- Entender el "por qué": Por qué este flujo específico importa
- Estrategia de testing: Distribución, priorización, trade-offs
- Evaluar riesgo: ¿Qué pasa si este test falla en producción a las 3am?
Mi flujo
1. Yo defino: ¿Qué riesgo mitigo? ¿Por qué importa?
2. IA genera: Estructura inicial, casos base
3. Yo reviso: ¿Cubre lo importante? ¿Es mantenible?
4. IA refina: Mejoras de código, casos adicionales
5. Yo valido: ¿El test prueba lo que debe probar?
La IA es el copiloto. Yo sigo decidiendo a dónde vamos.
El peligro del "generate and merge"
Tests generados sin contexto = falsa sensación de seguridad.
Coverage alto ≠ confianza alta. Código que no entiendes = deuda técnica disfrazada de productividad.
La habilidad que importa
No es escribir tests.
Es saber qué preguntar:
- ¿Qué riesgo estoy mitigando?
- ¿Cuál es el comportamiento esperado?
- ¿Cómo sé que esto realmente funciona?
El SDET del futuro no compite con la IA. La dirige.