menu_superior

Automatización de Pruebas (I): Cuestiones previas

Después de dar por inaugurada la categoría voy a escribir el primer post afinando un poco más mi planteamiento de cara a automatizar pruebas generando valor añadido. Es importante el matiz de la generación de valor añadido ya que automatizar pruebas sin generar más valor que la ejecución manual tiene poca utilidad y ningún sentido. Se puede hacer, está claro, pero es antieconómico… Dicho de otra manera, es como matar moscas a cañonazos.

[Aunque parece obvio y casi innecesario hacer esta clase de aclaraciones, hay organizaciones en las que automatizar la ejecución de casos de prueba es un fin en sí mismo. A mí esto me parece un error, creo que la automatización es un medio para optimizar la calidad del producto software y de su proceso de construcción.]

Para conocer un poco más qué es la automatización de la ejecución de casos de prueba funcionales he destacado cuatro aspectos que me parecen importantes en un primer acercamiento:

1.- En primer lugar hay que tener claro que estamos hablando de automatizar la ejecución de los casos de pruebas funcionales. Sólo se automatiza la ejecución del caso de prueba, el resto del proceso sigue siendo manual. No hay un botón ni una orden que nos genere casos de prueba automáticos, se podría decir que en realidad más que de una ejecución automatizada estamos hablando de una ejecución de pruebas desatendida.

2.- Automatizar la ejecución de casos de prueba es una tarea ardua y costosa tanto en términos de trabajo como en términos económicos. Para llegar a ejecutar un caso de prueba automático hay que hacer lo mismo que con uno manual y además hay que escribir un script que haga automaticamente lo mismo que hacemos manualmente.

3.- Los scripts que ejecutan casos de prueba tienen mantenimiento. Es importante saber que si tenemos scripts tendremos que ajustar su funcionamiento cuando haya cambios en el aplicativo. Esto supone añadir más carga de trabajo a algo que desde el primer momento ya necesita de mucho esfuerzo.  Es lógico que si el SUT (Software Under Test) es modificado el script que lo prueba también tenga que serlo.

4.- Leyendo lo anterior parece que la automatización es algo que no aporta nada respecto a la posibilidad de ejecutar las pruebas manualmente. La verdad es que la automatización es muy útil  y lo que la hace interesante es la significativa reducción de tiempos por ciclo de pruebas ejecutado. Esta reducción es directamente proporcional al número de veces que se ejecutará el caso cuya ejecución hemos automatizado.

5.- El coste marginal por ejecución cuando las funcionalidades son estables es cero. Es decir, por mucho esfuerzo que haya que invertir en generar un script operativo una vez que funciona lo podemos ejecutar cuantas veces queramos sin costes adicionales. Esto nos abre la puerta para ejecutar los scripts muchas veces sin que haya costes.

Puedes continuar leyendo las siguientes entradas sobre automatización de pruebas: Cuándo Automatizar, Cómo Automatizar y un caso de éxito.

, ,