Sin nulles

Muchas veces se confunden los términos cuando se habla de multi plataforma, mucho más en aplicaciones web, la automatización multi plataforma permite poder ejecutar los test en ambientes distintos al de QC/QA, por ejemplo, en las integraciones continuas, donde la única interfaz del servidor es solo una terminal; En cambio la automatización multi navegador, permite detectar falencias en aplicaciones web, y verificar que las aplicaciones cumplan estándares web, que los scripts y que su interfaz sea acorde en todos (mantener mismos estilos y operaciones con JavaScript).

Aunque ambas pueden ser requeridas, no siempre pueden ejecutarse a la vez o de la misma forma, por lo cual los objetivos pueden ser variados. El uso corresponde a que tipo de aplicación se este probando y bajo que ambientes.

Herramientas tipo batch, que permitan automatización, y verificación de código son buenas en ambientes en los que se requiera la integración continua, y para que cuando se este por entregar en producción, estos test prueben la correctitud de la aplicación a nivel funcional.

Watir, Selenium entre otras (incluyendo herramientas no open source), se ejecutan de forma visual, permitiendo ver que se esta ejecutando, siendo muy útiles en demos, y ambientes donde se tengan todos los recursos (como por ejemplo el Navegador).

Celerity permite centrarse en la funcionalidad, sin depender del navegador, pudiendo ejecutar test similares, aunque sin tener interfaz.

La selección de estos tipos de herramientas dependen del proyecto y los recursos, además de los tiempos y necesidades de completitud.

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.

El testing automatizado tiene varias aristas negativas, una de ellas es la curva del comienzo, que al empezar a planificar y realizar los casos de prueba, esto se vuelve engorroso y consume demasiado tiempo, la corrección de los test durante la ejecución, aunque tiene un importante impacto, no consumen la cantidad de tiempo que cuando ya se tiene una base.

A partir de herramientas orientadas a BDD (Behavior Driven Development) es sencillo comenzar a realizar test cases mediante la definición de las mismas historias de usuario (user stories), casos de uso, o demás documentos funcionales. La principal ventaja de realizar casos automatizados utilizando una herramienta como por ejemplo, Cucumber, permite que se pueda demostrar que lo que se definió en las user stories como criterio de aceptación se cumplen durante la ejecución de estos casos en la integración.

Los resultados que retornen la ejecución de los tests aunque a veces parezcan ser técnicos, en algunos casos pueden a llegar a ser vistos por los stakeholders, por lo cual la presentación de los resultados, y que estos concuerden con las especificaciones funcionales que se especificaron, producen un mayor grado de conformidad y aceptación de las funcionalidades implementadas.

Las herramientas que utilizan BDD que en realidad estan pensadas para desarrollo, ayudan a generar de forma óptima casos de prueba automatizados para la etapa de testing.