Automatizar pruebas parece la decisión obvia en cualquier equipo de software moderno, pero hacerlo sin criterio puede generar más problemas de los que resuelve. Cuando cincuenta scripts se rompen cada semana y nadie confía en los resultados, el equipo termina gastando más tiempo reparando automatización que ejecutando pruebas manuales [0:17]. La clave no está en automatizar más, sino en automatizar las pruebas correctas usando señales claras que los datos ya proporcionan.
¿Qué tres señales definen una buena candidata para automatización?
Los mismos indicadores que aparecen en los dashboards de calidad —frecuencia, estabilidad, criticidad— son exactamente las señales que determinan si una prueba merece ser automatizada [0:37].
¿Por qué la frecuencia de ejecución es el primer filtro?
Si una prueba corre cada día, cada integración o cada sprint, automatizarla ahorra tiempo real. Una prueba de regresión diaria que toma treinta minutos genera aproximadamente ciento ochenta horas de ahorro al año. La misma prueba ejecutada una vez al mes solo ahorra seis horas [0:53]. La repetición es lo que paga la inversión; sin ella, no hay retorno.
¿Cómo se mide la estabilidad del resultado?
Una buena candidata produce el mismo resultado cada vez bajo las mismas condiciones. Para evaluarla, se revisa el historial: cuántas veces pasó frente a cuántas falló, y si las fallas fueron por cambios de código o aleatorias [1:18]. Automatizar una funcionalidad que cambia cada semana es como instalar riego automático en un jardín que rediseñas constantemente: termina costando más que hacerlo a mano.
¿Qué papel juega la criticidad de negocio?
Si el login se rompe, nadie accede al producto. Si el flujo de pago falla, se pierde dinero cada minuto. La fórmula de riesgo —probabilidad por impacto— aplica directamente: alta probabilidad de fallo más alto impacto equivale a prioridad de automatización [1:46].
¿Qué pruebas NO deberías automatizar?
Identificar qué excluir es igual de importante que elegir qué incluir [2:06].
- Interfaz cambiante: cuando botones se mueven o selectores dejan de existir, el script se rompe. Esto genera una prueba frágil cuyo costo de mantenimiento se acumula rápidamente.
- Pruebas de una sola vez: si solo corre una o dos veces, el tiempo de escribir el script nunca se recupera.
- Verificaciones subjetivas: la automatización no puede juzgar si una interfaz se siente intuitiva. El testing exploratorio y las revisiones visuales son territorio de personas, no de scripts [2:28].
La trampa más común es calcular el costo de automatización contando solo el tiempo de escritura del script. Eso es como calcular el costo de un auto solo con el precio de compra, sin combustible ni reparaciones [2:47]. Después de escribirlo, se gasta tiempo actualizando selectores, ajustando datos de prueba y arreglando scripts rotos. La meta es que el mantenimiento se mantenga por debajo del veinte por ciento del tiempo total de automatización. Si el equipo supera ese umbral, expandir el alcance empeora el problema.
¿Cómo construir un caso de negocio con ROI?
El ROI se calcula así: beneficios estimados menos costos estimados, dividido entre costos estimados, multiplicado por cien [3:15]. Un ejemplo concreto: si las pruebas de regresión manual cuestan dos mil dólares por sprint y automatizadas cuestan cien, el ahorro mensual puede llegar a casi siete mil ochocientos dólares. Una inversión de treinta mil se recupera en unos cuatro meses.
Pero es fundamental incluir todo en el lado de costos: escritura, ejecución, análisis y mantenimiento a lo largo de la vida del script. Si se omite el mantenimiento, el ROI se ve mejor de lo que realmente es. Lo recomendable es apuntar a un ROI positivo dentro de seis a doce meses [3:38]. Si una prueba no alcanza el punto de equilibrio en esa ventana, la ejecución manual gana.
Las pruebas flaky merecen atención especial: son las que a veces pasan y a veces fallan sin que nada cambie. Son como un detector de humo que solo a veces suena durante un incendio. El equipo deja de confiar y empieza a ignorar fallas reales, generando falsa confianza [3:55]. La tasa de pruebas flaky debe mantenerse por debajo del dos por ciento.
El entregable final no es una lista de pruebas, sino un documento defendible [4:32]: qué pruebas automatizar primero, qué criterios se usaron, ROI estimado con mantenimiento incluido y qué riesgo se acepta al no automatizar el resto. ¿Cuáles serían tus tres primeras candidatas a automatizar y por qué?
