{"id":735,"date":"2020-06-03T10:00:43","date_gmt":"2020-06-03T15:00:43","guid":{"rendered":"https:\/\/www.datazucar.cu\/?p=735"},"modified":"2020-06-03T11:26:45","modified_gmt":"2020-06-03T16:26:45","slug":"ejecutando-pruebas-de-funcionalidad-automatizadas-en-el-desarrollo-de-aplicaciones","status":"publish","type":"post","link":"https:\/\/www.datazucar.cu\/?p=735","title":{"rendered":"Pruebas automatizadas en el desarrollo \u00e1gil de software"},"content":{"rendered":"\n

RESUMEN<\/strong><\/h4>\n\n\n\n

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\u00f3n 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\u00f3n de pruebas funcionales. Estas pruebas pueden ser automatizadas, lo cual facilita su ejecuci\u00f3n sistem\u00e1tica y no implica una inversi\u00f3n de tiempo considerable que constituya atraso en los cronogramas. Adem\u00e1s, 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\u00f3mo se lleva a cabo la automatizaci\u00f3n de pruebas funcionales en la Divisi\u00f3n DATAZUCAR y los resultados que se han obtenido hasta el momento actual de desarrollo.<\/p>\n\n\n\n

INTRODUCCI\u00d3N<\/strong>
Como parte del seguimiento a problemas antes planteados y soluciones propuestas, respecto a la necesidad de la ejecuci\u00f3n de pruebas tempranas a los productos de software en paralelo a su desarrollo, la Divisi\u00f3n 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\u00f3n.
Teniendo en cuenta las modificaciones sucedidas en el proceso de desarrollo de aplicaciones y siguiendo el sistema de trabajo de la Divisi\u00f3n DATAZUCAR, regido por la metodolog\u00eda de desarrollo \u00e1gil SCRUM, se impone la revisi\u00f3n continua de funcionalidades antes probadas e incluso liberadas, ya sea por cambios de adici\u00f3n, modificaci\u00f3n o eliminaci\u00f3n; 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\u00f3n, lo cual significa que no es necesario esperar al final del proceso de desarrollo para su ejecuci\u00f3n. Esto no implica agilidad en el proceso de pruebas, ya que actualmente estas se realizan, para la mayor\u00eda 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\u00f3n de pruebas y la comparaci\u00f3n 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.<\/p>\n\n\n\n

DESARROLLO<\/strong>
Las metodolog\u00edas \u00e1giles son una serie de t\u00e9cnicas para la gesti\u00f3n de proyectos basadas en el desarrollo iterativo e incremental, donde el proyecto se divide en distintos bloques temporales denominados iteraci\u00f3n. En una iteraci\u00f3n se repite un determinado proceso de trabajo donde los componentes logran evolucionar el producto dependiendo de los completados en las iteraciones antecesoras, agregando m\u00e1s opciones de requisitos y logrando as\u00ed un mejoramiento.
Espec\u00edficamente Scrum, es un proceso en el que se aplican de manera regular un conjunto de buenas pr\u00e1cticas para trabajar colaborativamente en la entidad donde el desarrollo de un nuevo producto software o la modificaci\u00f3n 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\u00f3n una nueva versi\u00f3n funcional del producto.
Las funcionalidades y especificidades del software que deber\u00e1n ser implementadas, son obtenidas de las experiencias y necesidades de especialistas funcionales, que no son m\u00e1s que personas dotadas de los conocimientos necesarios en la materia, y que podr\u00e1n 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\u00e1n contener Casos de Pruebas, que cubran la verificaci\u00f3n de cada de las funcionalidades adicionadas, modificadas o eliminadas. En el caso del sistema de trabajo de la Divisi\u00f3n DATAZUCAR, se aplican las t\u00e9cnicas de:
\uf0b7 Pruebas de Caja Blanca (caminos b\u00e1sicos, control de flujo, control de datos o pruebas de ramificaci\u00f3n), basadas en el estudio del c\u00f3digo 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\u00f3n y sistema) fundamentalmente se aplican en el \u00e1mbito de las pruebas unitarias y a trav\u00e9s de herramientas de ejecuci\u00f3n autom\u00e1tica de pruebas como por ejemplo Cobertura, que permiten conocer la cobertura de c\u00f3digo de las pruebas dise\u00f1adas. \uf0b7 Pruebas de Caja Negra (particiones de equivalencia, an\u00e1lisis de valores l\u00edmite, pruebas transversales, etc.) tienen una visi\u00f3n externa del producto software y no est\u00e1n centradas en el c\u00f3digo fuente, por lo que se centran en analizar la funcionalidad. Por lo<\/p>\n\n\n\n

que los casos de prueba se basan en las diferentes entradas que puede recibir el software y sus correspondientes valores de salida. Estas t\u00e9cnicas se pueden aplicar a cualquiera de los niveles de pruebas (unitarias, integraci\u00f3n, aceptaci\u00f3n) con diferentes niveles de abstracci\u00f3n en la definici\u00f3n de los casos de prueba.
Por tanto las pruebas dise\u00f1adas, deber\u00e1n cubrir ambas t\u00e9cnicas y los errores o deficiencias detectadas, se recoger\u00e1n como incidencias en el repositorio a trav\u00e9s de la herramienta Gitlab (http:\/\/gitlab.datazucar.cu\/) y por supuesto en la propia descripci\u00f3n del Caso de Prueba en la herramienta AgilePro (http:\/\/agilepro.datazucar.cu\/#), en el que podr\u00e1 existir la referencia al n\u00famero de incidencia en el Gitlab.
Teniendo en cuenta lo antes planteado, los Casos de Prueba ser\u00e1n dise\u00f1ados de acuerdo al tipo de prueba que se realice. Los tipos de pruebas existentes seg\u00fan las caracter\u00edsticas de calidad de la ISO 9126:
<\/p>\n\n\n\n

\"\"
Tabla 1 Tipos de pruebas existentes seg\u00fan las caracter\u00edsticas de calidad de la ISO 9126
<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Por otra parte, los requisitos de calidad definidos para productos de software en la Divisi\u00f3n DATAZUCAR son los siguientes (DATAZUCAR, 2018):
<\/p>\n\n\n\n

\"\"
Tabla 2 Requisitos de calidad definidos para productos de software en la Divisi\u00f3n<\/figcaption><\/figure>\n\n\n\n


Actualmente, en uno de los equipos autogestionados seg\u00fan la metodolog\u00eda de desarrollo, se ha implementado la realizaci\u00f3n de la automatizaci\u00f3n de las pruebas funcionales de:
\uf0b7 Caja Blanca para el nivel de pruebas Unitarias y de Integraci\u00f3n. \uf0b7 Caja Negra para las t\u00e9cnicas de Partici\u00f3n de Equivalencia y An\u00e1lisis de Valores L\u00edmites en las pruebas funcionales.
Pruebas de Caja Blanca. Unitarias y de Integraci\u00f3n
Las pruebas Unitarias, consisten en \u201cejercitar el funcionamiento de una unidad de c\u00f3digo, normalmente una clase, aislada del resto de la aplicaci\u00f3n.\u201d (Cuellar Bravo, 2018). Mientras que las pruebas de Integraci\u00f3n \u201cejercitan el funcionamiento de una o varias clases en el contexto de la aplicaci\u00f3n. T\u00edpicamente, estos tests verifican la interacci\u00f3n con una base de datos, conexiones a sistemas externos, containers, etc.\u201d (Cuellar Bravo, 2018)
La distribuci\u00f3n de las responsabilidades en cuanto a la construcci\u00f3n de las pruebas est\u00e1 enfocada a la implementaci\u00f3n 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\u00f3n, se realizan en el mismo ambiente, d\u00edgase:
<\/p>\n\n\n\n

\"\"
Tabla 3 Entorno de desarrollo de aplicaciones<\/figcaption><\/figure>\n\n\n\n



Para almacenar las pruebas implementadas, se ha creado un espacio en el repositorio de c\u00f3digo, lo cual permite, versionar estas como parte de las iteraciones del desarrollo de las aplicaciones (Ver Ilustraci\u00f3n 1).<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 1 Estructura de c\u00f3digo en el repositorio. Carpeta para pruebas Unitarias y de Integraci\u00f3n<\/figcaption><\/figure>\n\n\n\n


Cada clase implementada, deber\u00e1 contener los posibles escenarios del caso de prueba, d\u00edgase el caso de \u00e9xito base y las posibles salidas ante la introducci\u00f3n de errores (Ver lustraci\u00f3n 2).<\/p>\n\n\n\n


A continuaci\u00f3n, se muestra la forma de ejecutar estas pruebas, haciendo uso de la herramienta de desarrollo PhpStorm, lo cual podr\u00e1 mostrar variaciones en dependencia de la herramienta utilizada. Las pruebas podr\u00e1n ejecutarse una a una o un conjunto de ellas, agrupadas en una misma carpeta. Para ejecutar las mismas deber\u00e1 de seleccionar la prueba deseada, hacer clic derecho sobre ella e indicar la opci\u00f3n \u201cRun\u201d (Ver Ilustraci\u00f3n 3).<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 2 Pruebas Unitarias y de Integraci\u00f3n. Caso de prueba Autenticaci\u00f3n de usuario<\/figcaption><\/figure>\n\n\n\n
\"\"
Ilustraci\u00f3n 3 Ejecuci\u00f3n de pruebas a nivel de carpetas<\/figcaption><\/figure>\n\n\n\n


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

\"\"<\/figure>\n\n\n\n


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

\"\"
Ilustraci\u00f3n 5 Detalles de errores de ejecuci\u00f3n de los test<\/figcaption><\/figure>\n\n\n\n


Debido a que estas pruebas est\u00e1n basadas en el estado actual del c\u00f3digo fuente, en caso de realizar cambios en la implementaci\u00f3n, de una iteraci\u00f3n a la otra en la mayor\u00eda de los casos, tambi\u00e9n habr\u00e1 que realizar cambios en los casos de pruebas. Esto permitir\u00e1 verificar continuamente que las modificaciones por adici\u00f3n, modificaci\u00f3n o eliminaci\u00f3n de funcionalidades, no han afectado al resto y que ellas mismas en cuesti\u00f3n se mantienen estables.<\/p>\n\n\n\n


Pruebas de Caja Negra. T\u00e9cnicas de Partici\u00f3n de Equivalencia y An\u00e1lisis de Valores L\u00edmites<\/strong><\/p>\n\n\n\n


La t\u00e9cnica de Partici\u00f3n 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\u00e1lisis de Valores L\u00edmites consiste en probar la habilidad del programa para manejar datos que se encuentran en los l\u00edmites aceptables. (Pressman, 2010)<\/p>\n\n\n\n

Para la ejecuci\u00f3n de las pruebas de Caja Negra, la responsabilidad en cuanto a la construcci\u00f3n de estas pruebas es del probador del equipo; el cual ha debido integrar las t\u00e9cnicas de Partici\u00f3n de Equivalencia y An\u00e1lisis de Valores L\u00edmites, durante la ejecuci\u00f3n de las pruebas de funcionalidad. Estas han sido dise\u00f1adas, una vez concluida la implementaci\u00f3n de las funcionalidades y construidas las interfaces del sistema.
Para la ejecuci\u00f3n de estas pruebas, se hace uso de los plugins para Firefox:
<\/p>\n\n\n\n

\"\"
Tabla 4 Herramientas de prueba de Caja Negra<\/figcaption><\/figure>\n\n\n\n


Una vez instalados y configurados los plugins, podr\u00e1 verificar que hayan sido a\u00f1adidos a su navegador en las extensiones del mismo (Ver Ilustraci\u00f3n 6).<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 6 Extensiones del navegador<\/figcaption><\/figure>\n\n\n\n


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

\"\"
Ilustraci\u00f3n 7 Plugin Selenium IDE-Button en la barra de herramientas<\/figcaption><\/figure>\n\n\n\n

En caso de seleccionar la segunda opci\u00f3n \u201cAbrir selenium IDE como Sidebar\u201d, se mostrar\u00e1 de la siguiente forma, la cual se recomienda, pues m\u00e1s c\u00f3moda para efectuar la grabaci\u00f3n de las pruebas. Deber\u00e1 tener abierto tambi\u00e9n el sistema web que desee probar, para el presente trabajo, se utiliza el sistema en desarrollo Industrial PLUS.<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 8 Grabaci\u00f3n de pruebas en Selenium<\/figcaption><\/figure>\n\n\n\n

Por lo tanto, en la barra de direcci\u00f3n del Selenium, se mostrar\u00e1 la direcci\u00f3n de publicaci\u00f3n del sistema. Mientras el bot\u00f3n de \u201cGrabar prueba\u201d est\u00e9 activo, toda acci\u00f3n que se realice en el sistema ser\u00e1 grabada de forma autom\u00e1tica en el \u00e1rea de comandos del plugin. Si desea detener la grabaci\u00f3n de la prueba, solo debe hacer clic izquierdo sobre el propio bot\u00f3n.
Por otra parte, es importante destacar, que el plugin contiene un conjunto de funciones predefinidas que facilitan el dise\u00f1o de los test, pero adem\u00e1s se podr\u00e1n adicionar otras nuevas que permitan cubrir fragmentos de prueba espec\u00edficos del sistema a probar. En caso de crear nuevas funciones, deber\u00e1 acceder a la opci\u00f3n del men\u00fa \u201cOpciones\u201d del plugin y especificar la ruta del archivo donde se han escrito dichas funciones (Ver Ilustraci\u00f3n 9).
De igual forma que para las pruebas Unitarias y de Integraci\u00f3n, en el caso de los proyectos de desarrollo de la Divisi\u00f3n DATAZUCAR, se ha creado un espacio en el repositorio, que<\/p>\n\n\n\n

permite, versionar las pruebas y suits de pruebas creadas en cada iteraci\u00f3n, las cuales son enriquecidas a\u00f1adiendo test a las funcionalidades modificadas o a\u00f1adidas (Ver Ilustraci\u00f3n 10).<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 9 Especificaci\u00f3n de archivo .js con funciones adicionales para probar<\/figcaption><\/figure>\n\n\n\n
\"\"
Ilustraci\u00f3n 10 Estructura de c\u00f3digo en el repositorio. Carpeta para pruebas Selenium<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

El test podr\u00e1 ser dise\u00f1ado seg\u00fan sus necesidades, pero se recomienda la creaci\u00f3n 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\u00f3n 11). En caso de existir varios casos de prueba en la misma suit, solo se mostrar\u00e1 activo uno de ellos (destacado en negritas).
Para ejecutar las pruebas dise\u00f1adas, tendr\u00e1 las opciones de ejecutar la suit de pruebas completa o solo uno de los casos de prueba incluidos en ella (Ver Ilustraci\u00f3n 12).<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 11 Suit de pruebas con varios Casos de prueba. Caso de prueba Login Usuario Incorrecto activo<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 12 Opciones de ejecuci\u00f3n de pruebas<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Tambi\u00e9n podr\u00e1 determinar la velocidad de ejecuci\u00f3n de las pruebas, lo cual influye notablemente teniendo en cuenta las prestaciones de la estaci\u00f3n de trabajo en la cual se ejecuten dichas pruebas. En el \u00e1rea inferior de la ventana se muestran los logs de ejecuci\u00f3n de las pruebas en caso de producirse errores durante su ejecuci\u00f3n, lo que le facilitar\u00e1 detectar los errores introducidos y su correcci\u00f3n (Ver Ilustraci\u00f3n 13).<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 13 Descripci\u00f3n \u00e1reas de la ventana<\/figcaption><\/figure>\n\n\n\n


Una vez concluido el dise\u00f1o del caso de prueba, o de la suit de prueba, la cual podr\u00e1 dise\u00f1ar de igual forma, podr\u00e1 guardarla seg\u00fan desee, pero siempre en formato .html, adem\u00e1s tendr\u00e1 la opci\u00f3n de exportar a diferentes lenguajes de programaci\u00f3n. Una vez guardada la prueba, podr\u00e1 volverla a abrir y modificar, seg\u00fan desee o necesite.
Al igual que en el caso de las pruebas Unitarias y de Integraci\u00f3n, deber\u00e1 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 \u00fanico, nombre o por el path del elemento, pues es la v\u00eda de que el plugin interprete qu\u00e9 elementos de la interfaz buscar para ejecutar cada sentencia del test (Ver Ilustraci\u00f3n 14). Por lo que se recomienda el uso de este tipo<\/p>\n\n\n\n

de pruebas para proyectos que inician y no en aquellos que ya tienen un cierto periodo de ejecuci\u00f3n.<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 14 Identificaci\u00f3n de elementos de interfaz<\/figcaption><\/figure>\n\n\n\n


Hasta el momento la ejecuci\u00f3n 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\u00f3n, lo cual ha sido reconocido por el cliente en cada demostraci\u00f3n mensual.
Por otra parte, la ejecuci\u00f3n de las pruebas de Caja Blanca, han asegurado el cubrimiento de un 78.5% de pruebas sobre todo el c\u00f3digo implementado (Ver Anexo 1). El cual deber\u00e1 de ir en aumento, pues en cada iteraci\u00f3n ejecutada se exige por el aumento de la cobertura del c\u00f3digo. Para el c\u00e1lculo de estos porcientos, se hace uso de la herramienta de integraci\u00f3n continua Jenkins (http:\/\/jenkins.datazucar.cu).
En cuanto a las pruebas de Caja Blanca, en cada iteraci\u00f3n 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\u00f3n 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\u00f3n al cliente.<\/p>\n\n\n\n

VALORACI\u00d3N ECON\u00d3MICA Y APORTE SOCIAL<\/strong>
La automatizaci\u00f3n de las pruebas funcionales, no requiere de un esfuerzo cr\u00edtico por parte de los dise\u00f1adores de pruebas, ni requiere de nuevos roles en los equipos de desarrollo, por lo que no implica p\u00e9rdida de tiempo y no representa un incremento en los gastos de la empresa por concepto de pago.
Tampoco implica atrasos en la planificaci\u00f3n de las pruebas, pues los mismos desarrolladores son los encargados de dise\u00f1ar las pruebas de Caja Blanca, y por tanto conocen el c\u00f3digo a comprobar. Adem\u00e1s, debido a la experiencia acumulada y a las habilidades adquiridas por los dise\u00f1adores 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\u00e9n se aprecian beneficios, pues al crear de forma sistem\u00e1ticas las suits de pruebas de cada iteraci\u00f3n, solo es necesario ejecutar las pruebas antes dise\u00f1adas para detectar la posible introducci\u00f3n de errores y a\u00f1adir los test de las nuevas funcionalidades, ganando en tiempo dedicado a estas verificaciones.
Comparando el tiempo promedio dedicado a estas pruebas, tambi\u00e9n es posible notar un avance entre la primera iteraci\u00f3n del proyecto y la \u00faltima concluida (Ver Anexo 3); a lo que de igual forma se puede a\u00f1adir una comparaci\u00f3n con resultados positivos hacia el uso de herramientas automatizadas, pues existe una variaci\u00f3n 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\u00f3n, donde no se hace necesario recrear continuamente los escenarios, pues ya han sido grabados durante la prueba de aceptaci\u00f3n.
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\u00f3n, solo dependen del lenguaje de programaci\u00f3n y no de una herramienta en espec\u00edfico.
En cuanto a la calidad de los productos probados a estos niveles y con estas t\u00e9cnicas, 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.<\/p>\n\n\n\n

CONCLUSIONES<\/strong>
La implementaci\u00f3n de pruebas de Caja Blanca para los niveles Unitarias y de Integraci\u00f3n, reportan beneficios al desarrollo de aplicaciones, pues se reduce la introducci\u00f3n de errores a la hora de liberar cada versi\u00f3n del software.
Estas pruebas, complementadas con las pruebas de Caja Negra, utilizando la combinaci\u00f3n de t\u00e9cnicas Partici\u00f3n de Equivalencia y An\u00e1lisis de Valores L\u00edmites, 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\u00e1s, la ejecuci\u00f3n de estas pruebas, no requiere de la interacci\u00f3n con el dise\u00f1ador de pruebas una vez ejecutadas, pues al ser automatizadas ese es su principal objetivo, su ejecuci\u00f3n sin la intervenci\u00f3n humana.
Su utilizaci\u00f3n en la entidad constituir\u00eda una ventaja favorable teniendo en cuenta la fluctuaci\u00f3n de los recursos humanos en los equipos de desarrollo. Lo cual permitir\u00e1 ganar en tiempo de desarrollo y calidad de software, m\u00e9trica muy acorde con lo establecido por la metodolog\u00eda de desarrollo.
RECOMENDACIONES<\/strong>
Para la ejecuci\u00f3n de las pruebas de Caja Negra, se recomienda su implementaci\u00f3n haciendo uso del Selenium en los proyectos que inician, debido a las caracter\u00edsticas del plugin.
Para las pruebas de Caja Blanca, se recomienda comenzar su implementaci\u00f3n para todos los proyectos en ejecuci\u00f3n.
Continuar con el estudio de herramientas y t\u00e9cnicas con el objetivo de obtener otras herramientas de pruebas automatizadas, que puedan ser ajustadas a las necesidades y caracter\u00edsticas del resto de los productos, constituir\u00e1 una ventaja para el \u00e1rea de desarrollo y para la Divisi\u00f3n DATAZUCAR en cuesti\u00f3n.<\/p>\n\n\n\n

BIBLIOGRAF\u00cdA<\/strong><\/p>\n\n\n\n

  1. Cuellar Bravo, C. (Mayo de 2018). SCRIBD. Obtenido de https:\/\/es.scribd.com\/document\/103373296\/Test-de-Pruebas<\/li>
  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<\/li>
  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\u00e1ticas, vol. 5, no 2.<\/li>
  4. Pressman, R. S. (2010). Ingenier\u00eda del software. Un enfoque pr\u00e1ctico. S\u00e9ptima edici\u00f3n. M\u00e9xico, D. F.: McGRAW-HILL INTERAMERICANA EDITORES, S.A. DE C.V. Obtenido de https:\/\/www.ecured.cu\/Pruebas_de_caja_negra<\/li><\/ol>\n","protected":false},"excerpt":{"rendered":"

    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\u00f3n de sus funciones, sino que […]\n","protected":false},"author":16,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[106,107],"tags":[],"class_list":["post-735","post","type-post","status-publish","format-standard","hentry","category-software","category-pruebas"],"_links":{"self":[{"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=\/wp\/v2\/posts\/735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=735"}],"version-history":[{"count":11,"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=\/wp\/v2\/posts\/735\/revisions"}],"predecessor-version":[{"id":771,"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=\/wp\/v2\/posts\/735\/revisions\/771"}],"wp:attachment":[{"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.datazucar.cu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}