Automatización total de pruebas para el aseguramiento de la calidad.

En esta oportunidad voy a compartir con el lector algunas de mis definiciones de “Automatización total”.


En el año 2003, no recuerdo exactamente cuando, pero si algunos sucesos que relaciono con ese año, algunos entendidos de SQA, QC y Software Testing comenzaban a hablar de la virtualización de entornos y automatización de pruebas.

Hablaban sobre estos dos aspectos como “claves” para el futuro, incluso en algún momento llegué a escuchar que, la empresa que no invirtiera en el impulsar estos métodos se vería privada de ciertos niveles de calidad.

En aquel entonces, no comprendía estos mensajes, pensaba que se relacionaban a la automatizar pruebas unitarias o pruebas informales del desarrollador. Tampoco conocía de virtualización más allá de lo que a un microprocesador o equipo se refiere. Y por más que hoy en día resulta obvio, en aquellos momentos no aposté por ninguno de los dos.

Tan solo cuatro años más tarde, me encontraba desarrollando entornos virtualizados y pruebas automatizadas. En el año 2007 ya existían potentes herramientas libres para la automatización y virtualización de pruebas que, las grandes empresas de software llevaban bastante tiempo usando. Era común escuchar que tal o cual empresa poseía n pruebas automatizadas que se ejecutaban en su software antes de hacerlo público.

Solo en aquel momento pude comprender de que hablaban aquellos expertos, la virtualización y automatización fueron un futuro que no se hizo esperar. Para más, el software que yo usaba en el año 2007 se comenzó a distribuir en el año 2005, confirmando de esta manera la poca visión que tuve aquel entonces.

Hoy la evolución natural de estos métodos son la integración continua y automatización total, a diferencia del pasado, en esta ocasión me encuentro definiendo métodos de la automatización total de pruebas. Aprovecho este espacio para compartir con vosotros algunas de estas definiciones.

Automatización total de pruebas
La automatización total, a diferencia de lo que su nombre indica, no es la automatización de todos los casos de prueba. Se refiere a la automatización de todos los casos cuyo coste de automatización se encuentre por debajo del coste de seis meses de ejecución manual. Esta regla se ajusta muy bien a diferentes entornos, duración de ciclos y objetos de prueba. Y en la mayoría de los casos es muy fácil de determinar. Por otra parte, asegura estadísticamente la amortización del trabajo de automatización.

Ampliación de escenarios soportado en automatización
Existen situaciones dónde una clase de equivalencia no nos ofrece condiciones de carrera del mundo real. Por otra parte, la ejecución de estos casos se vuelve excesivamente cara e impracticable.
Esto normalmente se tiene en cuenta durante la etapa de diseño y se apunta como riesgos de instalación, excepciones en las fronteras del test, o ejecuciones no realizadas. La potencia que ofrece la automatización de pruebas, permite crear estos escenarios que, supondrían una tarea colosal. Es requerido tener esto en cuenta a la hora de crear o revisar el caso para la automatización.

Revisión de casos de prueba desde el punto de vista de la automatización
Para lograr una correcta automatización total es imprescindible revisar cada caso desde el punto de vista de la automatización. Lo que voy a describir a continuación, no aplica para aquellos casos dónde la herramienta integra diseño de casos y automatización, o bien se diseñan directamente para ejecución automática: Una vez que el caso de prueba se encuentra diseñado y listo para automatizar, es necesario revisarlo desde el punto de vista de la automatización, esta revisión tratará de buscar variaciones que, sin variar la cobertura funcional, permitan realizar una automatización más natural o simplificada. Este proceso incrementa significativamente la automatización total, no obstante es importante tener en cuenta que, si se realizan variaciones involuntarias que impacten en la cobertura del caso de prueba, se crearán agujeros que degradaran la calidad del plan de pruebas. La ampliación de escenarios de pruebas basados en la automatización no se considera una variación en el caso, por el contrario es una versión diferente del mismo.

Escoger la correcta herramienta de automatización
Aunque parezca trivial y obvio, es sin dudas el punto más importante de la automatización total, siendo esta la piedra angular del método. Es imposible acometer una automatización total sin contar con una herramienta que permita automatizar de manera rentable cada caso. El coste de automatización se relaciona íntimamente con la calidad de la herramienta y la cantidad de casos “automatizables” dependen directamente del costo de la automatización. Es probable que la herramienta que haga posible la automatización total no se encuentre en el mercado, modificar una existente o incluso crear una desde cero es completamente válido, de cualquier forma es fundamental realizar el correcto análisis antes de comenzar la automatización total.

Juegos de datos como estructuras
En varias metodologías de aseguramiento de la calidad del software, el caso de prueba se representa con una estructura rígida que ofrece las precondiciones, acciones y resultados y los datos como una estructura flexible e indexada. En la automatización total esto debe respetarse. Es fácil ver el caso de prueba como un todo y caer en la creación de casos con datos escritos en piedra. Los datos indexados, también conocidos como “escenarios de prueba” permiten al servidor de integración continua realizar una ejecución más precisa. Demás está decir que el respetar esta regla aporta una cuota de reusabilidad y mantenibilidad a cada caso de prueba automatizado.

Perfiles necesarios para acometer la automatización total
El perfil requerido para acometer la automatización total es sin dudas un perfil de analista de calidad del software con capacidades para manejar la herramienta de automatización. Afortunadamente, hoy en día, en la mayoría de los países, es fácil encontrar estos perfiles, incluso con experiencia en alguna herramienta de automatización de pruebas.

Integración continua
Habitualmente, se considera la integración continua una metodología que sirve únicamente al desarrollo ágil, esto se debe a sus orígenes pero no lo considero del todo cierto. Se puede implementar automatización total + integración continua sin importar el peso de los métodos del proyecto. La automatización total debe apoyarse en la integración continua, de forma que el tener un servidor de compilación que preste este servicio, brinde la posibilidad de encontrar los fallos cuanto antes.


Como siempre os digo, quedo a la espera de vuestros comentarios, estaré encantado de responder dudas o cualquier otro comentario que queráis escribir.


A continuación algunos sitios que recomiendo visitar:
http://www.opensourcetesting.org
http://ant.apache.org/index.html
http://continuum.apache.org/
https://hudson.dev.java.net/