Días atrás, hice la primera parte de este artículo, donde escribí sobre lo que se habló en el último meetup al que asistí del grupo Valencia Software Craftsmanship,  y que trataba sobre Estrategia de automatización de aplicaciones de escritorio legadas.

Es esta segunda parte, os contaré lo que nos enseñaron sobre cuándo se deben automatizar las pruebas de software, y una vez claro ese concepto, por dónde empezar.

¿Cuando debemos automatizar?

Ahora que ya sabemos lo que nos va a aportar automatizar las pruebas de nuestro software, y los riesgos que conlleva hacerlo, es importante saber cuándo debemos hacerlo. En líneas generales, se debe automatizar cuando ello suponga un ahorro de tiempo y, por lo tanto, dinero.

Deberíamos automatizar todo aquello que sea imposible, o muy costoso, de hacer manualmente.

En primer lugar, y en mi opinión, el factor más importante, deberíamos automatizar todo aquello que sea imposible, o muy costoso, de hacer manualmente. No olvidemos que una de las ventajas de entregar software de calidad, es la rentabilidad, al ofrecer un producto que en su mayor parte posible esté libre de errores, y por lo tanto, requiera de menos mantenimiento y actualizaciones para corregir sus posibles defectos. Y esa rentabilidad, no debe verse minimizada por tener que realizar las pruebas manualmente cuando se puede obtener el mismo resultado y en un menor tiempo automatizando.

Otro factor importante que nos ayudará a la correcta decisión de automatizar las tareas de pruebas es si éstas, reducen el coste de los test de regresión manuales, donde en muy poco tiempo, podremos verificar que los cambios y/o mejoras que realicemos en nuestro software, no han afectado negativamente al resto del producto, sabiendo que este tipo de test son tan repetitivos.

Por último, y muy obvio, debemos automatizar las pruebas cuando con ello consigamos un aumento en la eficiencia y en la calidad del producto.

¿Por dónde empezar a automatizar las pruebas?

Una vez sabido qué casos se deben automatizar, puede surgir la pregunta de por dónde empezar este tipo de pruebas. Lo que se recomendó en el meetup fué, en un primer momento, evaluar el riesgo que supone un fallo, y que vendrá determinado por la frecuencia de uso del producto o componente de él, la probabilidad de error que tiene, y el impacto que causaría ese error. De donde se obtiene que las pruebas deberían empezar siempre por aquello que tenga una mayor probabilidad de error, junto a un gran impacto en el cliente y/o usuario.

Si no leíste el primer artículo puedes hacerlo aquí, y en el próximo sobre automatización de pruebas, os hablaré sobre la herramienta con la que practicamos automatizando las pruebas y los factores clave que nos ayudarán a que nuestras pruebas automatizadas sean lo más eficientes posibles y nos ayuden a entregar un producto diferenciador y de gran valor.