Quiero comenzar este texto aclarando que no soy un experto en testing y mucho menos en automatización, así que la idea que voy a exponer puede que suene desatinada.
Siempre que escuché o leí sobre automatización funcional y sobre cuándo era conveniente automatizar, se recomendaba hacerlo en ambientes estables, que no sufrieran muchas modificaciones y sobre lo que serían las pruebas de regresión. La verdad es que nunca estuve de acuerdo con este tema. Me parece que el fuerte de la automatización funcional es aliviar el trabajo repetitivo de recorrer pantallas e ingresar datos y permitir utilizar ese tiempo en analizar resultados o generar algún otro tipo de información más valiosa.
Cuando consulté sobre el porqué de esta recomendación siempre se me dijo que la automatización era costosa en tiempo y que eso hacía poco recomendable implementarla en etapas tempranas del desarrollo. Le di varias vueltas a esto y me parece que el verdadero problema radica en la falta de una herramienta que reduzca esos costos. Es decir no considero que sea un problema de la automatización en sí, como forma o método y entiendo que superado el escollo de la herramienta sería incluso recomendable aplicarla durante todo el proceso de testing.
¿Implicaría esto remover las pruebas manuales? Considero que no, al contrario, creo que muchos defectos se encuentran producto de los errores y la impaciencia del tester y un script o un programa no podría cometer estos fallos muchas veces tan valiosos. Metodológicamente suelo jugar mucho con la aplicación a probar, independientemente de los casos de prueba que se hayan escrito y ejecutado y gracias a esto entré defectos bastante críticos, tanto para el negocio como para la aplicación.
¿Y si hubiese una herramienta que permitiese automatizar este “juego”? Hace poco más de dos años y medio tuve que preparar una demo de automatización para la web de un cliente de la consultora para la que trabajo. Utilicé para eso Selenium Webdriver. Al comienzo los scripts que preparé eran toscos y para nada flexibles, pero una vez que fui comprendiendo cómo funcionaba le fui agregando cosas. Al principio la captura de evidencia, como imágenes y como archivos de texto con los mensajes que salían por pantalla, luego pensé en generar reportes, uno que contuviera la totalidad del a prueba y otro que sólo mostrara el defecto, luego decidí que los datos de prueba ya no podían estar en el script y decidí colocarlos en un Excel, el siguiente paso fue quitar la condición que reflejaba o no la existencia del defecto y colocar esto en ese mismo Excel y así, poco a poco, esos scripts toscos comenzaron a convertirse en una pequeña herramienta más flexible que un script, pero todavía muy limitada a un contexto de prueba. Es decir, esos scripts servían para probar un login, pero sólo para probar ese login, no cualquier login.
Así se comenzó a gestar en mi cabeza la idea de una herramienta, que utilice el api de Selenium para la interacción con el browser, pero que a su vez permita probar cualquier página web. Suena lindo ¿No? El siguiente paso que tuve que encarar fue el de quitar la lógica al script o, mejor dicho, que esta lógica y por ende el script mismo se genere en tiempo de ejecución. Para solucionar este aspecto se me ocurrió combinar archivos xml que contienen un diccionario, la suite con sus casos de prueba y resultado esperado y otro que permita realizar verificaciones no funcionales, como por ejemplo validar resultados de un abm contra una base de datos.
No puedo contar mucho más sobre esto porque no logré avanzar mucho, presenté una demo de mi idea donde se hacía una navegación de páginas webs, gustó, se aprobó y entonces surgieron otras cosas y ahí quedó.
Adjunto a esta nota los tres proyectos que usé para generar la demo, aclaro que le falta muchísimo y que está programado a las apuradas. El generador de diccionarios tiene una interfaz para generar el xml con el diccionario de la web a testear. El proyecto que se llama generador de casos permite armar una lista de casos basados en un diccionario y el generador de scripts es el programa que une los dos archivos, diccionario y casos, y ejecuta el script. Sólo está probada la función de clicks.
Espero sus comentarios respecto a lo expuesto aquí, no sólo a la herramienta, sino a estos conceptos que parecerían relegar a la automatización y ofrecerla como algo “caro”.
Por Martin Cejas
Coordinador/Líder de testing
https://ar.linkedin.com/in/mcejas/en
