AVISO: Esta reflexión es personal y basada  en  mi experiencia, cualquier  parecido  con la realidad  es mera coincidencia .

Hace tiempo leí una frase de un ilustre superviviente, al menos a mi parecer, que se me quedó grabada y me hizo reflexionar un poco, cosa no muy corriente en mi caso. La frase en cuestión es: When we are no longer able to change a situation – we are challenged to change ourselves (Viktor Frankl)… espero no tener que pagar derechos de autor.

Aplicar esto a mi vida personal en momentos claves ha sido bastante útil y necesario, pero, ¿qué tiene que ver esto con el mundo de las pruebas («testing» para  los políglotas)?.

Pues todo se remonta a mis comienzos en el mundo de las telecomunicaciones cuando empecé a trabajar haciendo pruebas manuales de sistemas de red.

Para mí, era lo mejor del mundo: definía las pruebas, las ejecutaba, comprobaba los resultados paso a paso conectándome manualmente a las bases de datos, a los equipos, me las ingeniaba para provocar… y todo lo demás que una persona que se dedique a hacerlas ya sabe y que, para el resto, suena a rollazo.

En esa época, el escuchar «automatización de pruebas», directamente me producía aburrimiento. ¿Qué interés podría tener el automatizar las pruebas y perder el reto que suponía cada prueba unitaria?.

Y llegó el momento en que la vida me llevó por otros derroteros, (aquí va la parte de «when we are no longer able to change a situation») y un día me surgió la posibilidad de trabajar automatizando pruebas.

Ni que decir tiene que no me apetecía nada, pero ¿qué iba a perder por intentarlo? (y aquí viene lo de «we are challenged to change ourselves»). Así que, empecé a automatizar.

Al principio, me costó adaptar los conceptos de una metodología a otra, tengo que reconocerlo, y mis primeras automatizaciones fueron bastante «cutres» por así decirlo, pero una vez que empecé a verlo de otra forma todo se simplificó. ¿Qué ventajas podía sacarle a la automatización?. Una muy útil, es que me podía ahorrar tiempo a la hora de retestear.  Además podía lanzar la misma prueba cambiando simplemente un parámetro. Ya con las pruebas manuales me había tenido que crear algún script para esto y, ¿qué era eso en realidad si no una forma de automatizar?

Desde hace poco más de medio año, trabajo automatizando pruebas con TAST (Test Automation System Tool).

Con TAST no es necesario tener muchos conocimientos sobre scripting para poder diseñar un diagrama de pruebas, ya que, la herramienta es muy versátil y permite facilitar el proceso. Para ello, está claro que detrás de la herramienta hay un buen equipo de desarrolladores.

En cuanto a mi miedo de que cada prueba dejase de suponer un reto, he de reconocer que no ha sido así. El hecho de automatizar una prueba no es tal y como pensaba, ya que quien maneja la herramienta soy yo y puedo complicar o simplificar tanto como quiera. Con la ventaja de que esa misma prueba podré ejecutarla tantas veces como necesite sin la necesidad de realizar cada paso manualmente y de forma unitaria. Incluso puedo reutilizar un diagrama, o parte de él, cuando lo necesite en otro tipo de pruebas.

Resumiendo, desde mi punto de vista, la automatización ahorra tiempo y permite que muchas más personas puedan hacer pruebas sin necesidad de tener unos conocimientos muy específicos. TAST nos facilita la vida y «hace el trabajo sucio».

Aun así, no cambiaría mi época de pruebas manuales, porque me ayudó a desarrollar mi capacidad analítica y a tener la base para entender cómo plantear una prueba y detectar errores e incluso provocarlos.

Dedicado a mis compañeros TASTERS.