Automatización de Pruebas

Muchas empresas han visualizado los beneficios de la automatización de pruebas, pero se han encontrado con dificultades para comenzar de una manera eficiente. Esto se debe principalmente a la falta de experiencia y a verse desbordados en su capacidad de ejecución, ya que es necesario continuar con las pruebas rutinarias de siempre, siendo así el testing automatizado un trabajo extra, más que algo que nos ahorrará esfuerzo a mediano y largo plazo. En ese sentido es pertinente lograr que la automatización nos de beneficios en corto plazo, y no tener que esperar al próximo ciclo de pruebas para poder visualizar los beneficios.

 En este artículo mostraré las estrategias que podemos utilizar para lograr estos objetivos en nuestros proyectos de inicio en la automatización de pruebas.

Comenzando

¿Han jugado juegos de estrategia militar, como Starcraft? En estos juegos se trata de ir formando tropas (con naves de distintos tipos) de acuerdo a los recursos que se van obteniendo. Cada nave tiene un costo (en minerales y tiempo de construcción), y obviamente las naves más poderosas tienen un costo más alto que las pequeñas. Entonces, hasta que no se consiguen muchos recursos, es muy difícil tener una de esas naves gigantes. La estrategia que más me servía al jugar esto era construir pequeñas naves, que a pesar de tener menor poder destructivo me servían para defenderme de los posibles ataques, y así darme tiempo de ir fortaleciendo a mi ejército.

 Cuando hablamos de automatización de pruebas podemos usar la misma estrategia. Es preferible comenzar con una nave pequeña, que nos de pequeños beneficios pero en forma inmediata, en vez de esperar a tener una gran nave superpoderosa, que tal vez llega tarde, cuando ya no hay tiempo para defenderse de los problemas, o sea, ¡cuando estemos saliendo a producción! De esta forma aplicamos soluciones suficientemente buenas y no soluciones perfectas, porque estas llegan tarde.

 Para aclarar la idea, veamos un sencillo ejemplo. Vamos a diseñar pruebas para la operación de realizar el alta de un cliente utilizando una forma de registro web. Para ello podemos tomar como referencia una forma sencilla de alta de clientes, tal como la que está disponible en http://samples.genexus.com/ajaxsample/client.aspx?INS,0

 En el caso de prueba simplemente hay que ingresar valores en los distintos campos, confirmar, y luego buscar el elemento creado para verificar que sus valores hayan sido guardados correctamente.

 Esta es una prueba simple, no estamos intentando "romper el sistema", simplemente estamos viendo "la línea amarilla". Mi primera nave de batalla va a ser limitada.

 Para automatizar la prueba no necesitamos mucho más tiempo que el que lleva ejecutar la funcionalidad a mano. Utilizando cualquier herramienta de pruebas automatizadas podemos “grabar” el caso de prueba a partir de una ejecución manual, de manera que no sea necesario tener que desarrollarla completamente desde cero. Entonces, mientras uno graba la prueba, la herramienta captura todas las acciones ejecutadas sobre el sistema y las convierte en comandos que servirán luego para ejecutar las mismas acciones repetidamente. Luego que tenemos esa prueba lista, la podemos ejecutar cada vez que queramos: tenemos nuestra primera nave funcionando y reportándose.

Data-driven testing

Una vez teniendo el script para prueba automatizada, con poco esfuerzo más podemos obtener mucho más beneficio de esta misma nave. En este caso, podemos parametrizar la prueba y hacer que cada valor ingresado en cada campo sea tomado de un data pool (fuente de datos de prueba, tal como una tabla o archivo), y así estar probando distintos escenarios.

 Nuestros datos de prueba necesitan pueden ser una tabla con las siguientes columnas, que corresponden a los campos de la forma de registro de cliente: First_Name, Last_Name, Country_Name, City_Name, Address, Balance.

 Entonces tendremos un datapool con estas columnas. Luego podremos pensar distintas combinaciones de valores para probar. Por ejemplo, valores nulos, o valores muy grandes, strings muy largos, balances negativos, etcétera. Así, la misma prueba la puedo ejecutar con todas las combinaciones de datos que se me ocurran con tan solo ingresar los valores en una tabla. Esta ejecución la puedo hacer cada vez que se necesite, obteniendo información sobre el estado de la aplicación en forma casi inmediata.

 Si esta prueba la tuviera que ejecutar en forma manual con cada dato de prueba interesante, me llevaría más tiempo que ejecutarla automáticamente. O sea, los beneficios de este caso de prueba automatizado se ven directamente en este ciclo de pruebas, y no recién en el siguiente ciclo de pruebas de regresión. Son beneficios a corto plazo, con lo cual, visto de esta forma, es muy conveniente comenzar a automatizar.

 De acuerdo a lo que cuenta Cem Kaner en uno de sus artículos [1] automatizar una prueba lleva entre 3 y 10 veces más que ejecutarla en forma manual (este artículo es de 1997, pero es aún vigente, o en tal caso, el costo es menor). Incluso, si en los siguientes ciclos de prueba tenemos cierto costo de mantenimiento de estos casos de prueba, imaginemos que también de 10 veces más que el costo de ejecución manual, también obtendremos beneficios si ejecutamos 11 veces la prueba de regresión.

 Este enfoque de separar el flujo del caso de prueba de los datos que se utilizan, está basado en la técnica Data-driven
testing [2].

Conclusión

Espero que este ejemplo haya servido para visualizar cómo podemos comenzar nuestros esfuerzos de pruebas automatizadas con algo muy simple que nos da resultados inmediatos, para luego ir mejorándolo para sacarle más jugo. Lo importante es percibir los beneficios desde el principio, para luego hacer crecer el ejército. Esto está basado en nuestra experiencia de trabajo brindando servicios de pruebas funcionales, incluyendo pruebas automatizadas. Lo hemos puesto en práctica en diversos proyectos y siempre obteniendo muy buenos resultados.

Referencias
[1] C. Kaner. “Improving the Maintanability of Automated Test Suites”. Quality Week, 1997. http://swgu.ru/sg40r17
[2] “Data Driven Testing”. Wikipedia. http://swgu.ru/sg40r18