Adaptarse y reciclar

Vivimos una época en la que todo avanza rápidamente y salen nuevas tendencias constantemente. En tecnología es más evidente, aparecen nuevas técnicas y metodologías y, como era de esperar, el área de calidad de software no se queda atrás y se tiene que adaptar a esos cambios.

Por ello, hay que ser capaz de realizar cada vez más tareas en el mínimo tiempo posible y, por lo tanto, es necesario aprovechar el tiempo; en definitiva, adaptarse y reciclar.

El planteamiento es aprovechar parte de nuestras tareas de trabajo y reciclarlas para que sean útiles en tareas posteriores de nuestro flujo de trabajo. De esta manera conseguiremos agilizar el trabajo, adaptando tareas y optimizando el tiempo del que disponemos para realizar nuestro cometido.

A continuación detallo algunos ejemplos de reciclaje de tareas que he tenido la oportunidad de realizar para su posterior aprovechamiento:

• Generación de datos

Antes de realizar la ejecución del conjunto de pruebas de regresión, lanzamos un smoke test que tenemos preparado para verificar que el funcionamiento del núcleo de la aplicación es correcto y que se puede iniciar la completa ejecución del juego de pruebas. El reciclaje que llevamos a cabo aquí consistiría en planificar el smoke test de tal manera que nos sirva también para la generación de datos de prueba necesarios para la ejecución posterior. De esta manera, se realiza un ahorro de ese tiempo de preparación de dichos datos.

• Preparación de escenario de pruebas de rendimiento

De la misma manera que en el apartado anterior, antes de realizar la ejecución de una prueba de rendimiento, se ejecuta una prueba smoke test de rendimiento para verificar el correcto funcionamiento de la aplicación bajo pruebas para, a continuación, en el caso de obtener un resultado positivo en este smoke test, realizar la ejecución del escenario de pruebas de rendimiento planificado.

Este smoke test lo aprovechamos para tomar referencias de tiempos en vacío de cada uno de los scripts que forman parte del escenario completo de pruebas. Así, podremos modificar los valores, en caso de ser necesario, para optimizar el escenario y crearlo lo más fiel a la realidad posible.

• Cierre de defectos

En un proyecto de pruebas en el que participé, estaban planificados dos ciclos de pruebas de regresión automáticas en cada subida a Producción. Lo normal sería que, entre cada uno de los ciclos, hubiese un tiempo para que los equipos de Desarrollo revisen y corrijan los defectos encontrados en el primer ciclo de pruebas. Sin embargo, por problemas de calendario de la release, no era posible hacerlo y, por lo tanto, el segundo ciclo se inicia nada más terminar el primero.

Lo que se decidió hacer para reciclar este segundo ciclo es aprovechar su ejecución para poder ir verificando los defectos que nos han ido asignando los desarrolladores como resueltos o no reproducibles, verificar su veredicto y cerrarlos, en caso de que estén correctamente corregidos, o reasignarlos en el caso de que se sigan reproduciendo.

• Acceso a datos de pruebas automáticas

En las pruebas automáticas se suele utilizar un fichero Excel para almacenar los datos de prueba necesarios. Usando este fichero, el acceso a un dato requerido en las pruebas suele ser costoso debido a que es un acceso secuencial. Además, si se tienen que cruzar datos de distintas pestañas del fichero, requiere un gran desarrollo.

La tarea que hicimos fue adaptar ese sistema de datos y transformarlo en una base de datos en el que, lanzando una consulta, te devuelve el dato requerido. Con esta tarea se optimiza el rendimiento de la aplicación, así como el tiempo de ejecución total de la prueba.

• Generación automática de defectos

Las herramientas de automatización de pruebas generan una “descripción” del defecto cuando existe un comportamiento no esperado en la aplicación. La experiencia con diferentes herramientas nos indica que esa descripción no suele ser muy intuitiva, siendo difícil de sacar directamente los pasos y el resumen de la incidencia. Hemos realizado un proceso de transformación y reciclaje de dicha funcionalidad de la herramienta, haciendo un desarrollo de ese log de resultados para que, cuando se detecta un defecto en las pruebas automáticas, saque una descripción exacta de todos los pasos realizados en la aplicación (los datos utilizados para la prueba, las validaciones realizadas, el entorno, la aplicación, la fecha y hora de la prueba, etc.).

Con estas medidas de reciclaje de tareas y cualquier otra que se nos ocurra dependiendo de las necesidades y posibilidades del proyecto, podemos ahorrar tiempo y evitar duplicidades de tareas. Así, se optimiza el flujo de trabajo y se realiza un proceso de calidad del software más ágil, acorde con las nuevas tendencias que el mercado exige.

Alberto Garrido

Ingeniero de Test Senior | Digital Assurance & Testing | SOGETI España