A partir de metodologías Ágiles, la principal desventaja que surge en la automatización es el mantenimiento de los scripts que se generen, es aún mayor cuando se trata de proyectos de aplicaciones web, donde el cambio puede ser constante.
La principal causa de que los casos de automatización fallen es el cambio de los locators (atributos de referencia), que son los que permiten referenciar el objeto dentro del sitio web. Lo ideal en los proyectos es que durante el desarrollo de la aplicación se utilicen estándares para que cada objeto tenga un identificado o nombre, y que estos sean unívocos, pero no siempre es así, por lo cual en muchos scripts se utilizan sentencias XPATH, que se basan en el DOM del código HTML. Esto a su vez suma otra dificultad, no todos los browsers tienen las mismas formas de acceso a los elementos utilizando XPATH, por ejemplo al utilizar Watir, a veces no es lo mismo una referencia en IE y Firefox, por lo que el script termina fallando.
Supongamos que no existiera el problema de las sentencias XPATH, y que nuestro sitio utilice estándares y que todo elemento contenga nombres o identificadores, de todas formas aún tenemos el principal problema, en cuanto uno de estos cambien, también empezaran a fallar nuestros casos automatizados. La principal solución es independizar a los test de los locators, ya sea mediante el uso de variables o archivos de configuración.
Esto permite la abstracción del test, permitiendo que este siempre ejecute las mismas sentencias, pero variando el elemento, vale destacar que si el tipo de elemento no debe cambiar, en caso de que esto pase, si se debe modificar el test.
El uso de un framework de automatización permite cierto grado de abstracción del tipo de elemento, actualmente me encuentro trabajando en un framework llamado Rubidium (http://sourceforge.net/projects/rubidium/) que utiliza Watir, Selenium y Celerity, aún esta en etapa de desarrollo, pero su principal ventaja es la abstracción del objeto a utilizar en el caso automatizado.
La abstracción mediante archivos de configuración, permite la independencia total en el momento de generar el caso de prueba, permitiendo la mayor flexibilidad, y al momento de modificar algo, solo se centra el trabajo en un punto en particular, y no en múltiples lugares.
La principal causa de que los casos de automatización fallen es el cambio de los locators (atributos de referencia), que son los que permiten referenciar el objeto dentro del sitio web. Lo ideal en los proyectos es que durante el desarrollo de la aplicación se utilicen estándares para que cada objeto tenga un identificado o nombre, y que estos sean unívocos, pero no siempre es así, por lo cual en muchos scripts se utilizan sentencias XPATH, que se basan en el DOM del código HTML. Esto a su vez suma otra dificultad, no todos los browsers tienen las mismas formas de acceso a los elementos utilizando XPATH, por ejemplo al utilizar Watir, a veces no es lo mismo una referencia en IE y Firefox, por lo que el script termina fallando.
Supongamos que no existiera el problema de las sentencias XPATH, y que nuestro sitio utilice estándares y que todo elemento contenga nombres o identificadores, de todas formas aún tenemos el principal problema, en cuanto uno de estos cambien, también empezaran a fallar nuestros casos automatizados. La principal solución es independizar a los test de los locators, ya sea mediante el uso de variables o archivos de configuración.
Esto permite la abstracción del test, permitiendo que este siempre ejecute las mismas sentencias, pero variando el elemento, vale destacar que si el tipo de elemento no debe cambiar, en caso de que esto pase, si se debe modificar el test.
El uso de un framework de automatización permite cierto grado de abstracción del tipo de elemento, actualmente me encuentro trabajando en un framework llamado Rubidium (http://sourceforge.net/projects/rubidium/) que utiliza Watir, Selenium y Celerity, aún esta en etapa de desarrollo, pero su principal ventaja es la abstracción del objeto a utilizar en el caso automatizado.
La abstracción mediante archivos de configuración, permite la independencia total en el momento de generar el caso de prueba, permitiendo la mayor flexibilidad, y al momento de modificar algo, solo se centra el trabajo en un punto en particular, y no en múltiples lugares.
Comments (0)
Publicar un comentario