Pruebas automatizadas en el desarrollo ágil de software

RESUMEN

La calidad de los productos de software, es un tema de vital importancia y de continuo seguimiento, pues la premisa siempre debe ser la entrega de productos estables, que cumplan con los requerimientos de los clientes, que cubran sus expectativas y que no constituyan un impedimento para la realización de sus funciones, sino que contribuyan a informatizar procesos que pudieran ser engorrosos. Por lo tanto, los productores de software deben asegurarse de que los productos entregados al cliente presenten la menor cantidad de errores posibles.
Una de las estrategias a seguir para alcanzar este objetivo, lo es la realización de pruebas funcionales. Estas pruebas pueden ser automatizadas, lo cual facilita su ejecución sistemática y no implica una inversión de tiempo considerable que constituya atraso en los cronogramas. Además, pueden ser ejecutadas haciendo uso de herramientas libres, por lo que tampoco implica un gasto para las organizaciones que lo implementen.
El presente trabajo, es una muestra cómo se lleva a cabo la automatización de pruebas funcionales en la División DATAZUCAR y los resultados que se han obtenido hasta el momento actual de desarrollo.

INTRODUCCIÓN
Como parte del seguimiento a problemas antes planteados y soluciones propuestas, respecto a la necesidad de la ejecución de pruebas tempranas a los productos de software en paralelo a su desarrollo, la División DATAZUCAR mantiene como premisa prevenir la entrega no intencional de productos no conformes a sus clientes y para ello define las pruebas y verificaciones que se realizan a los productos de software, antes de que sean entregados a los clientes externos para su uso final o demostrativo, fuera o dentro de la institución.
Teniendo en cuenta las modificaciones sucedidas en el proceso de desarrollo de aplicaciones y siguiendo el sistema de trabajo de la División DATAZUCAR, regido por la metodología de desarrollo ágil SCRUM, se impone la revisión continua de funcionalidades antes probadas e incluso liberadas, ya sea por cambios de adición, modificación o eliminación; esto adicionado al incremento de la complejidad de los productos de software, puede significar un retraso durante la fase de pruebas al tener que verificar una y otra vez dichas funcionalidades.
Las pruebas a funcionalidades, se ejecutan una vez concluida su implementación, lo cual significa que no es necesario esperar al final del proceso de desarrollo para su ejecución. Esto no implica agilidad en el proceso de pruebas, ya que actualmente estas se realizan, para la mayoría de los proyectos, de forma manual. Sin embargo, existen herramientas especializadas que permiten automatizar el proceso de pruebas, y cuyo objetivo final es controlar la ejecución de pruebas y la comparación entre los resultados obtenidos y los resultados esperados.
Por lo que el presente trabajo tiene como objetivo mostrar resultados alcanzados aplicando herramientas de pruebas automatizadas para las pruebas funcionales.

DESARROLLO
Las metodologías ágiles son una serie de técnicas para la gestión de proyectos basadas en el desarrollo iterativo e incremental, donde el proyecto se divide en distintos bloques temporales denominados iteración. En una iteración se repite un determinado proceso de trabajo donde los componentes logran evolucionar el producto dependiendo de los completados en las iteraciones antecesoras, agregando más opciones de requisitos y logrando así un mejoramiento.
Específicamente Scrum, es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente en la entidad donde el desarrollo de un nuevo producto software o la modificación de uno existente se divide en iteraciones, lo cual permite que el desarrollo se realice de forma iterativa/incremental, logrando al final de cada iteración una nueva versión funcional del producto.
Las funcionalidades y especificidades del software que deberán ser implementadas, son obtenidas de las experiencias y necesidades de especialistas funcionales, que no son más que personas dotadas de los conocimientos necesarios en la materia, y que podrán o no ser clientes. Estas especificidades son traducidas a Historias de Usuarios, las cuales se desglosan a nivel de tareas que son asignadas a los desarrolladores de cada equipo.
Estas mismas Historias de Usuario, deberán contener Casos de Pruebas, que cubran la verificación de cada de las funcionalidades adicionadas, modificadas o eliminadas. En el caso del sistema de trabajo de la División DATAZUCAR, se aplican las técnicas de:
 Pruebas de Caja Blanca (caminos básicos, control de flujo, control de datos o pruebas de ramificación), basadas en el estudio del código fuente y utilizadas principalmente desde la perspectiva interna en el desarrollo de software. Aunque las pruebas de caja blanca se pueden aplicar en diferentes actividades de pruebas (unitarias, integración y sistema) fundamentalmente se aplican en el ámbito de las pruebas unitarias y a través de herramientas de ejecución automática de pruebas como por ejemplo Cobertura, que permiten conocer la cobertura de código de las pruebas diseñadas.  Pruebas de Caja Negra (particiones de equivalencia, análisis de valores límite, pruebas transversales, etc.) tienen una visión externa del producto software y no están centradas en el código fuente, por lo que se centran en analizar la funcionalidad. Por lo

que los casos de prueba se basan en las diferentes entradas que puede recibir el software y sus correspondientes valores de salida. Estas técnicas se pueden aplicar a cualquiera de los niveles de pruebas (unitarias, integración, aceptación) con diferentes niveles de abstracción en la definición de los casos de prueba.
Por tanto las pruebas diseñadas, deberán cubrir ambas técnicas y los errores o deficiencias detectadas, se recogerán como incidencias en el repositorio a través de la herramienta Gitlab (http://gitlab.datazucar.cu/) y por supuesto en la propia descripción del Caso de Prueba en la herramienta AgilePro (http://agilepro.datazucar.cu/#), en el que podrá existir la referencia al número de incidencia en el Gitlab.
Teniendo en cuenta lo antes planteado, los Casos de Prueba serán diseñados de acuerdo al tipo de prueba que se realice. Los tipos de pruebas existentes según las características de calidad de la ISO 9126:

Por otra parte, los requisitos de calidad definidos para productos de software en la División DATAZUCAR son los siguientes (DATAZUCAR, 2018):

Actualmente, en uno de los equipos autogestionados según la metodología de desarrollo, se ha implementado la realización de la automatización de las pruebas funcionales de:
 Caja Blanca para el nivel de pruebas Unitarias y de Integración.  Caja Negra para las técnicas de Partición de Equivalencia y Análisis de Valores Límites en las pruebas funcionales.
Pruebas de Caja Blanca. Unitarias y de Integración
Las pruebas Unitarias, consisten en “ejercitar el funcionamiento de una unidad de código, normalmente una clase, aislada del resto de la aplicación.” (Cuellar Bravo, 2018). Mientras que las pruebas de Integración “ejercitan el funcionamiento de una o varias clases en el contexto de la aplicación. Típicamente, estos tests verifican la interacción con una base de datos, conexiones a sistemas externos, containers, etc.” (Cuellar Bravo, 2018)
La distribución de las responsabilidades en cuanto a la construcción de las pruebas está enfocada a la implementación de estas pruebas por parte de los programadores del equipo. Teniendo en cuenta el entorno de desarrollo de las aplicaciones, las pruebas Unitarias y de Integración, se realizan en el mismo ambiente, dígase:

Para almacenar las pruebas implementadas, se ha creado un espacio en el repositorio de código, lo cual permite, versionar estas como parte de las iteraciones del desarrollo de las aplicaciones (Ver Ilustración 1).

Cada clase implementada, deberá contener los posibles escenarios del caso de prueba, dígase el caso de éxito base y las posibles salidas ante la introducción de errores (Ver lustración 2).

A continuación, se muestra la forma de ejecutar estas pruebas, haciendo uso de la herramienta de desarrollo PhpStorm, lo cual podrá mostrar variaciones en dependencia de la herramienta utilizada. Las pruebas podrán ejecutarse una a una o un conjunto de ellas, agrupadas en una misma carpeta. Para ejecutar las mismas deberá de seleccionar la prueba deseada, hacer clic derecho sobre ella e indicar la opción “Run” (Ver Ilustración 3).

Durante la ejecución de las pruebas, se activará un panel que mostrará el proceso y los resultados obtenidos para cada uno de los test ejecutados. A la izquierda se listarán los test ejecutados, y permanecerán listados aquellos en los que se produzcan errores (Ver Ilustración 4).

Mientras que en el área derecha se mostrará el por ciento de avance en la ejecución de las pruebas. En caso de mantenerse en color verde, significa que no se han producido errores en la ejecución de los test, en caso contrario, se mostrará el progreso en color rojo e indicará la cantidad de test que han fallado. En el área inferior a la barra de progreso, se listan los errores producidos para un test en específico, el cual deberá seleccionar previamente en el área izquierda de la ventana (Ver Ilustración 5).

Debido a que estas pruebas están basadas en el estado actual del código fuente, en caso de realizar cambios en la implementación, de una iteración a la otra en la mayoría de los casos, también habrá que realizar cambios en los casos de pruebas. Esto permitirá verificar continuamente que las modificaciones por adición, modificación o eliminación de funcionalidades, no han afectado al resto y que ellas mismas en cuestión se mantienen estables.

Pruebas de Caja Negra. Técnicas de Partición de Equivalencia y Análisis de Valores Límites

La técnica de Partición de Equivalencia se basa en dividir el campo de entrada, en clases de datos que tienden a ejercitar determinadas funciones del software. Y el Análisis de Valores Límites consiste en probar la habilidad del programa para manejar datos que se encuentran en los límites aceptables. (Pressman, 2010)

Para la ejecución de las pruebas de Caja Negra, la responsabilidad en cuanto a la construcción de estas pruebas es del probador del equipo; el cual ha debido integrar las técnicas de Partición de Equivalencia y Análisis de Valores Límites, durante la ejecución de las pruebas de funcionalidad. Estas han sido diseñadas, una vez concluida la implementación de las funcionalidades y construidas las interfaces del sistema.
Para la ejecución de estas pruebas, se hace uso de los plugins para Firefox:

Una vez instalados y configurados los plugins, podrá verificar que hayan sido añadidos a su navegador en las extensiones del mismo (Ver Ilustración 6).

Verificada su existencia, ejecutar el diseño de los test es muy sencillo y no implica una gran inversión de tiempo. A continuación, se detalla el proceso de pruebas.
Primeramente, deberá abrir el navegador y ejecutar el plugin Selenium IDE-Button, en cualquiera de las versiones de Firefox que decida utilizar. Se mostrarán dos opciones que le permitirán abrir el plugins en una ventana independiente a navegador o en el lateral izquierdo del mismo (Ver Ilustración 7).

En caso de seleccionar la segunda opción “Abrir selenium IDE como Sidebar”, se mostrará de la siguiente forma, la cual se recomienda, pues más cómoda para efectuar la grabación de las pruebas. Deberá tener abierto también el sistema web que desee probar, para el presente trabajo, se utiliza el sistema en desarrollo Industrial PLUS.

Por lo tanto, en la barra de dirección del Selenium, se mostrará la dirección de publicación del sistema. Mientras el botón de “Grabar prueba” esté activo, toda acción que se realice en el sistema será grabada de forma automática en el área de comandos del plugin. Si desea detener la grabación de la prueba, solo debe hacer clic izquierdo sobre el propio botón.
Por otra parte, es importante destacar, que el plugin contiene un conjunto de funciones predefinidas que facilitan el diseño de los test, pero además se podrán adicionar otras nuevas que permitan cubrir fragmentos de prueba específicos del sistema a probar. En caso de crear nuevas funciones, deberá acceder a la opción del menú “Opciones” del plugin y especificar la ruta del archivo donde se han escrito dichas funciones (Ver Ilustración 9).
De igual forma que para las pruebas Unitarias y de Integración, en el caso de los proyectos de desarrollo de la División DATAZUCAR, se ha creado un espacio en el repositorio, que

permite, versionar las pruebas y suits de pruebas creadas en cada iteración, las cuales son enriquecidas añadiendo test a las funcionalidades modificadas o añadidas (Ver Ilustración 10).

El test podrá ser diseñado según sus necesidades, pero se recomienda la creación de una suit de pruebas que incluya varios casos de prueba. Cada caso de prueba debe cubrir los posibles escenarios o salidas del sistema, en dependencia de los valores introducidos al sistema (Ver lustración 11). En caso de existir varios casos de prueba en la misma suit, solo se mostrará activo uno de ellos (destacado en negritas).
Para ejecutar las pruebas diseñadas, tendrá las opciones de ejecutar la suit de pruebas completa o solo uno de los casos de prueba incluidos en ella (Ver Ilustración 12).

También podrá determinar la velocidad de ejecución de las pruebas, lo cual influye notablemente teniendo en cuenta las prestaciones de la estación de trabajo en la cual se ejecuten dichas pruebas. En el área inferior de la ventana se muestran los logs de ejecución de las pruebas en caso de producirse errores durante su ejecución, lo que le facilitará detectar los errores introducidos y su corrección (Ver Ilustración 13).

Una vez concluido el diseño del caso de prueba, o de la suit de prueba, la cual podrá diseñar de igual forma, podrá guardarla según desee, pero siempre en formato .html, además tendrá la opción de exportar a diferentes lenguajes de programación. Una vez guardada la prueba, podrá volverla a abrir y modificar, según desee o necesite.
Al igual que en el caso de las pruebas Unitarias y de Integración, deberá modificar estas pruebas, en caso de surgir modificaciones en las interfaces de las aplicaciones. Es importante destacar que, para el correcto funcionamiento de los test, cada elemento de la interfaz debe ser distinguido por un identificador único, nombre o por el path del elemento, pues es la vía de que el plugin interprete qué elementos de la interfaz buscar para ejecutar cada sentencia del test (Ver Ilustración 14). Por lo que se recomienda el uso de este tipo

de pruebas para proyectos que inician y no en aquellos que ya tienen un cierto periodo de ejecución.

Hasta el momento la ejecución de las pruebas automatizadas en el desarrollo del Industrial PLUS, han contribuido al aumento de la calidad de cada una de las versiones creadas por iteración, lo cual ha sido reconocido por el cliente en cada demostración mensual.
Por otra parte, la ejecución de las pruebas de Caja Blanca, han asegurado el cubrimiento de un 78.5% de pruebas sobre todo el código implementado (Ver Anexo 1). El cual deberá de ir en aumento, pues en cada iteración ejecutada se exige por el aumento de la cobertura del código. Para el cálculo de estos porcientos, se hace uso de la herramienta de integración continua Jenkins (http://jenkins.datazucar.cu).
En cuanto a las pruebas de Caja Blanca, en cada iteración se crea una suit de pruebas, que incluye las pruebas de interfaz realizadas en las versiones anteriores. Lo cual representa una ventaja, pues ejecutar la suit correspondiente a la iteración anterior, arroja resultados positivos o no, en cuanto funcionalidades que hayan podido ser afectadas por implementaciones posteriores. Permitiendo detectar errores que deben ser corregidos antes de la demostración al cliente.

VALORACIÓN ECONÓMICA Y APORTE SOCIAL
La automatización de las pruebas funcionales, no requiere de un esfuerzo crítico por parte de los diseñadores de pruebas, ni requiere de nuevos roles en los equipos de desarrollo, por lo que no implica pérdida de tiempo y no representa un incremento en los gastos de la empresa por concepto de pago.
Tampoco implica atrasos en la planificación de las pruebas, pues los mismos desarrolladores son los encargados de diseñar las pruebas de Caja Blanca, y por tanto conocen el código a comprobar. Además, debido a la experiencia acumulada y a las habilidades adquiridas por los diseñadores de pruebas, en este caso desarrolladores, el promedio de tiempo invertido en esta tarea ha disminuido considerablemente (Ver Anexo 2).
En el caso de las pruebas de Caja Negra también se aprecian beneficios, pues al crear de forma sistemáticas las suits de pruebas de cada iteración, solo es necesario ejecutar las pruebas antes diseñadas para detectar la posible introducción de errores y añadir los test de las nuevas funcionalidades, ganando en tiempo dedicado a estas verificaciones.
Comparando el tiempo promedio dedicado a estas pruebas, también es posible notar un avance entre la primera iteración del proyecto y la última concluida (Ver Anexo 3); a lo que de igual forma se puede añadir una comparación con resultados positivos hacia el uso de herramientas automatizadas, pues existe una variación de tiempo notable al ejecutar las pruebas de Caja Negra de forma manual y de forma automatizada (Ver Anexo 4), sobre todo para las pruebas de regresión, donde no se hace necesario recrear continuamente los escenarios, pues ya han sido grabados durante la prueba de aceptación.
Por otra parte, estas pruebas no implican inversiones en cuanto software, pues para el caso de las pruebas Selenium, los plugins son libres de pago. Y en el caso de las pruebas Unitarias y de Integración, solo dependen del lenguaje de programación y no de una herramienta en específico.
En cuanto a la calidad de los productos probados a estos niveles y con estas técnicas, se puede decir que es aceptable, dada las experiencias obtenidas de las demostraciones mensuales a los clientes, en las cuales se detectan pocas deficiencias o errores.

CONCLUSIONES
La implementación de pruebas de Caja Blanca para los niveles Unitarias y de Integración, reportan beneficios al desarrollo de aplicaciones, pues se reduce la introducción de errores a la hora de liberar cada versión del software.
Estas pruebas, complementadas con las pruebas de Caja Negra, utilizando la combinación de técnicas Partición de Equivalencia y Análisis de Valores Límites, permite verificar, a nivel de interfaz, las funcionalidades adicionadas, modificadas o eliminadas para cada una de las iteraciones. Pues su uso es iterativo e incremental, lo cual permite verificar todos los escenarios de cada prueba.
Además, la ejecución de estas pruebas, no requiere de la interacción con el diseñador de pruebas una vez ejecutadas, pues al ser automatizadas ese es su principal objetivo, su ejecución sin la intervención humana.
Su utilización en la entidad constituiría una ventaja favorable teniendo en cuenta la fluctuación de los recursos humanos en los equipos de desarrollo. Lo cual permitirá ganar en tiempo de desarrollo y calidad de software, métrica muy acorde con lo establecido por la metodología de desarrollo.
RECOMENDACIONES
Para la ejecución de las pruebas de Caja Negra, se recomienda su implementación haciendo uso del Selenium en los proyectos que inician, debido a las características del plugin.
Para las pruebas de Caja Blanca, se recomienda comenzar su implementación para todos los proyectos en ejecución.
Continuar con el estudio de herramientas y técnicas con el objetivo de obtener otras herramientas de pruebas automatizadas, que puedan ser ajustadas a las necesidades y características del resto de los productos, constituirá una ventaja para el área de desarrollo y para la División DATAZUCAR en cuestión.

BIBLIOGRAFÍA

1. Cuellar Bravo, C. (Mayo de 2018). SCRIBD. Obtenido de https://es.scribd.com/document/103373296/Test-de-Pruebas
2. DATAZUCAR, G. d. (2018). Alfresco DATAZUCAR. Obtenido de http://portal.datazucar.cu/share/page/site/calidad/documentdetails?nodeRef=workspace://SpacesStore/e2e963e6-9420-475c-ba01a3817062a26a
3. FEBLES ESTRADA, A. e. (2011). Una experiencia novedosa para el testing desarrollada por un departamento de pruebas de software. Revista Cubana de Ciencias Informáticas, vol. 5, no 2.
4. Pressman, R. S. (2010). Ingeniería del software. Un enfoque práctico. Séptima edición. México, D. F.: McGRAW-HILL INTERAMERICANA EDITORES, S.A. DE C.V. Obtenido de https://www.ecured.cu/Pruebas_de_caja_negra