1 Introducción
Dentro del Testing de Software, la automatización de pruebas es una de las actividades que presentan una mayor espectativas. La posibilidad de ejecutar las pruebas de software de manera desatendida, hace que las organizaciones vuelquen sus esperanzas en la automatización como la solución ideal para abaratar los costes y acortar los tiempos de pruebas.
Sin embargo, poner en marcha la automatización no es una tarea sencilla. Es necesario salvar numerosas dificultades para poder llevar a cabo una automatización eficiente y que permita retornar la inversión realizada. Es importante fijar un conjunto de prácticas que agilicen las tareas de mantenimiento y construcción y que aporten una cierta metodología a nuestro proceso de automatización .
Sin embargo, poner en marcha la automatización no es una tarea sencilla. Es necesario salvar numerosas dificultades para poder llevar a cabo una automatización eficiente y que permita retornar la inversión realizada. Es importante fijar un conjunto de prácticas que agilicen las tareas de mantenimiento y construcción y que aporten una cierta metodología a nuestro proceso de automatización .
2 Algunas buenas prácticas
1. Infraestructura de Carpetas.
Los productos de la Automatización deben mantenerse organizados. Scripts, ficheros de datos, aplicaciones de soporte, documentación, ficheros de configuración, etc... deben almacenarse en un sistema de directorios y carpetas que permitan su direccionamiento rápido.
La organización puede depender de los objetivos. Podemos organizar nuestra infraestructura de directorios por aplicación, por plan de pruebas, por sistema, etc...
2. Modularización
Los casos de prueba automatizados pueden modularizarse en base a librerías que realicen funcionalidades más sencillas, de esa forma se agilizará el mantenimiento de los casos.
También es posible construir librerías de propósito general que apliquen a todos nuestros casos automatizados con independencia de la aplicación o proceso. Ejemplos de librerías de propósito general son:
- Control de errores
- Escritura/lectura de ficheros de datos
3. Robustez.
En caso de que se produzca un error no controlado durante la ejecución, la lógica del caso de prueba debe ser capaz de finalizar y dejar el estado del equipo de ejecución estable y listo para continuar con una nuevo caso de prueba.
Una posibilidad es comprobar el estado de la maqueta al comenzar una ejecución, forzando el cierre de aquellas aplicaciones que se encuentren abiertas o levantar o parar aquellos servicios necesarios.
Una posibilidad es comprobar el estado de la maqueta al comenzar una ejecución, forzando el cierre de aquellas aplicaciones que se encuentren abiertas o levantar o parar aquellos servicios necesarios.
4. Sistema de Trazas.
La información que debe aportar un caso de prueba debe ser fiable. En caso de fallo debe informar de manera concreta de lo que ha ocurrido.
Completar la construcción de los casos de prueba con un sistema de trazas que aporten toda la información o suministrar la captura de la pantalla en el momento del error, pueden ayudar a ganar confianza en los casos automatizados.
Completar la construcción de los casos de prueba con un sistema de trazas que aporten toda la información o suministrar la captura de la pantalla en el momento del error, pueden ayudar a ganar confianza en los casos automatizados.
Los casos de prueba automatizados se deben preparar teniendo en cuenta posibles cambios.
Una opción es parametrizar aquellos datos susceptibles de cambios: rutas de acceso, identificadores de usuarios, etc..
6. Mantenimiento de los equipos de ejecución.
La ejecución de casos automáticos suele ser una tarea estresante para los equipos donde corren los casos. Es recomendable programar tareas de mantenimiento como reinicios periódicos, eliminación de ficheros temporales, desfragmentación de discos, etc...
