Cuando uno testea, es bueno saber de todo un poco, saber programar, saber analizar, saber encontrar, saber….. Todo esto se gana con experiencia y años dedicados a la materia, es como aquel, que después de unos cuantos años, se siente libre de tutear a su jefe o a otras personas de su entorno, se siente cómodo y de a poco y con mucho entusiasmo va ingresando en el mundo de la gestión, pero no la gestión clásica de levantar defecto, generar casos de prueba, diseñar la estrategia…. no, empieza a tener una mirada de la gestión y del trato con otros profesionales luego esta persona probablemente se convierta en una persona que tenga gente a cargo, algo similar pero en un camino bastante distinto le sucede al automatizador.
Comienza realizando pruebas funcionales, o clásicamente llamada manuales, pero de a poco y con o sin darse cuenta, entra en un mundo que muchos lo creían como parte del desarrollo…. si, esta es la primer gran falacia respecto a este perfil, pasa que uno, que no está muy metido en el tema, lo primero que piensa es… “bueno la automatización requiere programación, y si hay programación tiene que estar el sector de desarrollo en esto”. Mentira!!! perdon mi objeción…. pero no es verdad!. Como existe el perfil del tester manual (que lo veremos pronto!) también existe el tester automatizador, y este último se encarga de la programación.
Un tester automatizador, no solo se encarga de programar (aunque hay salvedades), cuando uno comienza a testear manualmente de a poco se va dando cuenta que con herramientas uno puede facilitar las pruebas manuales, por eso uno de los pilares más importante del automatizador es hacerse experto en la herramienta. Si fuese el caso de una herramienta de programación su fuerte sería el uso del lenguaje apropiado junto con el IDE que utilizaría, si fuese un tester en unix su fuerte sería conocer cómo programar shell script y así puedo nombrar una gran variedad de testing que se realizan manualmente y que fácilmente con un herramienta y con ganas de aprender se puede lograr un gran expertise en la rama de la automatización.
Pero como siempre digo en cada uno de los artículos…. ¿y qué hay de los webservices?
Los webservices tiene su rama de automatización, podemos usar una variedad de herramientas:
- SOAtest
- SoapUI
- SoapClient, etc.
Ahora bien supongamos que creo una tabla con 10 casos de prueba a ejecutar, se disparan en 5, 4, 3, 2, 1…….. listo!!! ejecute mi automatización!!!! caen flores desde el cielo……acá es cuando se acerca tu supervisor preguntando y como salieron las pruebas?? uno le contesta re bien 10 ejecutadas, 10 aprobadas!!!. Con el tiempo resulta ser que en producción con una misma combinación de datos no se impactó unos saldos de intereses sobre un usuario, nuestro supervisor se nos acerca contándonos el tema…. y es acá cuando uno dice…. uuuu pero mis pruebas solo incluían ejecutar el webservices y ver mi respuestas…… ERROR y con esto damos paso al segundo gran elemento pilar de este análisis. Uno no puede solo ejecutar ver la respuesta y listo, también debe realizar pruebas para comprobar que los impactos hayan sido los correctos, un caso peor es aquel en donde la respuesta del webservices devuelve además el ok de la respuesta una serie de datos adicionales, muchos no consideran estos datos y esta mal no hacerlo, no es lo mismo realizar una consulta a una biblioteca y que la misma te de ok porque tiene datos para mostrar a que no posea justo el libro que necesitas.
En programación como en la mayoría de herramientas afines a esto se lo conoce como Assertions, que son condiciones que se deben dar por lo general posterior a la ejecución de la prueba, pero debe formar parte de la prueba, osea si la prueba trae datos pero justamente no está el que necesitamos la prueba falla.
Y el tercer y último elemento pilar para la automatización de los webservices es la Documentación, deben quedar logs que permitan rastrear fácilmente un caso de prueba automatizado, además deben generar scripts que permiten comunicarse con otras herramientas que se dedique a la gestión y ejecución de casos de prueba.
Autor:
Leonardo Espindola
QA Automation Engineer | QA Tester
LinkedIn
