Casi todos los equipos con los que hablo tienen el mismo problema antes de empezar a automatizar: una lista larga de “todo esto habría que automatizar” y ningún criterio claro para decidir el orden. El resultado, casi siempre, es que se automatiza lo más fácil primero — y lo más fácil rara vez es lo que más impacto tiene.
El criterio que no funciona: “empecemos por lo simple”
Es la decisión más común y la más comprensible: arrancar por una pantalla chica, un formulario sin mucha lógica, algo que se puede automatizar en un día y mostrar como avance rápido. El problema es que ese tipo de flujo casi nunca es el que más le cuesta al equipo en testing manual, ni el que más riesgo tiene si se rompe.
Automatizar lo fácil primero da una sensación de progreso. No reduce el dolor real del equipo.
Un criterio que sí funciona: impacto × frecuencia × fragilidad
Para decidir qué automatizar primero, hay tres preguntas que importan más que la dificultad técnica:
¿Qué tan seguido se ejecuta este flujo en regresión? Un flujo que se prueba a mano en cada release tiene un retorno de inversión mucho más alto que uno que se prueba una vez cada seis meses, aunque este último sea técnicamente más simple de automatizar.
¿Qué tan caro es que falle sin que nadie lo note? No es lo mismo un bug en un reporte interno que un bug en el flujo de pago. El costo de un escape a producción tiene que pesar en la decisión, no solo el esfuerzo de automatizarlo.
¿Qué tan inestable es el área del producto? Una funcionalidad que cambia seguido (porque el negocio todavía la está iterando) es mala candidata para automatizar primero — vas a estar reescribiendo el test cada dos semanas. Conviene automatizar primero lo que es crítico y estable, y dejar lo crítico-pero-cambiante para una segunda etapa, con una arquitectura de tests que tolere mejor el cambio.
La trampa de “automaticemos lo que más se queja el equipo”
Otra señal engañosa es priorizar por dónde se queja más el equipo de QA manual. A veces la queja es real y apunta a algo crítico. Pero a veces el área que más cansa de probar a mano no es la que más le cuesta al negocio si falla — es simplemente la más tediosa. Tedioso y riesgoso no son lo mismo, y conviene no confundirlos al priorizar.
Cómo se ve esto en la práctica
En un diagnóstico inicial, lo que hago no es preguntar “¿qué quieren automatizar?” sino mapear los flujos de negocio por impacto y frecuencia, cruzarlo con lo que hoy consume más horas de regresión manual, y recién ahí construir el orden. Casi siempre el resultado sorprende: lo que el equipo daba por sentado que había que automatizar primero termina siendo la tercera o cuarta prioridad real.
No automatizar lo correcto en el orden equivocado por mucho tiempo no es gratis: cada release sigue dependiendo de testing manual en las áreas de mayor riesgo, mientras el esfuerzo de automatización se gasta en lo que menos importa.
Si no tenés claro por dónde empezar, esa indecisión tiene un costo medible. Hablemos de tu caso y armamos el orden priorizado por impacto, no por facilidad.