Español (pdf)
Articulo en XML
Referencias del artículo
Traducción automática
Enviar articulo por email
Citado por SciELO 
Citado por Google 
Similares en
SciELO 
Similares en Google 
Permalink
1. INTRODUCCIÓN
Un estudio realizado en 2019 por [1] en Europa muestra que el desarrollo de software centra un 59,4 % de esfuerzo en el uso de pruebas de software para asegurar la calidad. Este es el factor principal considerado por las empresas para el rendimiento y la mejora continua de la industria de desarrollo. La implementación de pruebas de software en el desarrollo de productos de software según [2] y [3] es considerada como componente esencial para asegurar su estructura funcional y de calidad, reconocido también como herramienta útil que proporciona información detallada del cumplimiento de requerimientos del tipo funcional, no funcional, estructural y no estructural en la composición de un producto de software durante todo su ciclo de vida.
Según [4] el desarrollo guiado por comportamiento o behaviour-driven development (bdd) es una evolución del desarrollo guiado por pruebas o test-driven development (tdd) con un proceso más efectivo y visto como la nueva metodología ágil de segunda generación basada en automatización de pruebas, con herramientas y procesos de análisis de mejor composición y desempeño del software, que ayuda a prevenir diversos problemas y garantiza la calidad funcional.
Del mismo modo [5] sostienen que es un conjunto de pruebas y técnicas basadas en métricas para evaluar el rendimiento y los atributos de calidad relacionados con un sistema. Algunos análisis con estudios de [6] demostraron que entre el 25 y el 90 % del presupuesto de desarrollo de software es requerido en la fase de pruebas y correcciones debido a la ineficiencia e ineficacia del proceso de desarrollo, y que con el uso correcto de pruebas de software se disminuye la cantidad de posibles errores humanos y el consumo de recursos, y como resultado se obtiene la reducción del costo en el proyecto de elaboración del software.
Dado que la industria de desarrollo tiene un alto margen de crecimiento evolutivo año tras año y la calidad en su estructura es un detalle fundamental en todo el mundo según [7] y [8], se necesita una herramienta como bdd que nos ayude a combatir debilidades en el desarrollo de software y nos permita sacar el mejor provecho a su composición con la mínima tasa de error y con un enorme alcance funcional de toda la estructura de manera que las empresas de desarrollo tengan éxito en sus proyectos de software.
Perú, en 2019, tuvo un ingreso aproximado de US$800 millones en servicios, del cual el 37 % era del rubro moderno, es decir, de la exportación de tecnología como productos de software [9], un indicador que el país tiene crecimiento en ese rubro y, por tanto, genera oportunidades para que el sector tecnológico peruano pueda exportar productos de software, entre otras tecnologías. Según [10] la situación tecnológica peruana ha mejorado, por lo que es necesario garantizar que los productos tecnológicos desarrollados sean eficientes, óptimos y de calidad.
Asimismo [11] indicó que Perú experimenta una transformación con respecto a servicios digitales ante empresas y la sociedad, con una tasa de incremento anual del 14,1 %, con visión de multiplicarse 2,5 veces en 2020 ante el crecimiento que tuvo en 2010. Asegurar calidad estructural y evolución a través de la mejora continua es un argumento puesto en cuestionamiento debido a que en Perú solo el 7 % de las empresas manejan buenas prácticas en el desarrollo de softwaresegún un estudio realizado por [12].
En razón de lo expuesto, esta revisión bibliográfica tuvo como objetivo analizar en profundidad las buenas prácticas del desarrollo basado en el comportamiento en las diferentes etapas de un proyecto de softwarey su contribución para generar un producto de softwarede calidad, en atención a las ilustraciones de documentos experimentales y de revisión, publicados en los últimos cinco años, vinculados a los distintos tipos de pruebas de desarrollo y metodologías para la construcción de software con el fin de obtener una síntesis clara del método.
2.METODOLOGÍA
Para alcanzar el objetivo planteado, y dar respuesta al cuestionamiento ¿qué buenas prácticas tiene el desarrollo basado en comportamiento para asegurar la calidad del software?, se realizó un proceso exhaustivo de aprendizaje y búsqueda para seleccionar la información que forma parte de esta revisión.
Fase 1: Metacognición
Para el desarrollo de la revisión, se realizó un análisis profundo del tema a través del metaaprendizaje, aplicando los principios de la definición investigativa de [13], que referencia hacer uso de metacognición para la correcta identificación de ideas principales, contexto y palabras clave con el fin de tener una síntesis clara y objetiva, las mismas que posteriormente fueron usadas en el desarrollo de esta revisión.
Fase 2: Búsqueda de información
De acuerdo con el estudio de [14] sobre planteamiento de estrategias para la efectividad y eficiencia en investigación, se realizó la búsqueda de datos e información fundamental, se usó la metodología de revisión sistemática de la literatura y se destacaron aquellos artículos escritos en un lenguaje formal-científico tanto en español como en inglés y técnicas de búsqueda para la correcta selección de información de las distintas fuentes bibliográficas, tales como:
Búsqueda en bases de datos con mayor realce en calidad de indexación, citación y contenido: IEEE, ScienceDirect, Scielo, Scopus y Redalyc.
Uso de palabras clave: "behavior driven development", "software quality", "development testing", "software testing" en inglés, y "pruebas unitarias", "pruebas de software", "calidad de software", "automatización de pruebas" y "desarrollo de software" en español.
Asimismo, se utilizó el filtro de búsqueda periódica anual desde 2016 hasta 2020 y se recopiló información actual y trascendental.
La información obtenida fue alojada en el software Mendeley en sus plataformas web y de escritorio, con información relevante de los documentos, de donde se dio lectura y la extracción de ideas y fuentes contextuales de autores seleccionados para la construcción de esta revisión.
Fase 3: Análisis de la información
De acuerdo con las investigaciones y guías de [15] y [16], y su sugerencia de aplicar el desarrollo estructurado de la revisión, se llevó a cabo mediante el análisis de la información obtenida de los artículos científicos, estructurada de manera jerárquica desde la definición como parte principal, seguido de la estructura del tema y, por último, la utilidad a través de buenas prácticas, diseñado estratégicamente para sintetizar de forma correcta la información obtenida.
DESARROLLO DE LA REVISIÓN
[17] sostiene que los productos de software son herramientas que ayudan a que los procesos diarios se den de forma óptima y automatizada, y así disminuir tiempo, costo y recursos en su ejecución. Parte fundamental de los mencionados productos es asegurar su calidad, que de acuerdo con [18], se encuentran expuestos en cualquier etapa del desarrollo del software e, incluso, hasta luego de su despliegue en producción; por ello, indica que es importante conocer los fallos que se van dando y a su vez crear estrategias de reducción de riesgos con la finalidad de asegurar la calidad funcional del software.
Según estudios realizados por [19] y [20], asegurar la calidad del software conlleva diversos métodos, metodologías, herramientas y técnicas que permiten gestionar la calidad del producto; aunque implique mayor tiempo y presupuesto, es la mejor estrategia para desarrollar softwares de calidad totalmente funcionales con el mínimo porcentaje de exposición a fallas. Por ende [21], indica que los procesos como el desarrollo guiado por BDD influyen en el acompañamiento y en la documentación durante el proceso de desarrollo, y de esta manera permite prevenir y verificar fallas, así como garantizar mejora continua a través del autoaprendizaje de errores.
Desarrollo guiado por comportamiento
El BDD es un proceso de desarrollo de softwareágil de segundo plano, que congenia con diversas metodologías ágiles, en especial, en la frecuencia de programación extrema para el desarrollo de software y microservicios, usa el lenguaje específico de dominio o domain-specific language (DSL) para empresas denominado Gherkin, que describe el comportamiento del software de acuerdo con sus funcionalidades, como manifiesta [4]. En otras palabras, [5] lo describe como una descripción del comportamiento del software en lenguaje natural en lugar del uso de un lenguaje de programación.
BDD, al ser un proceso de testeo y planificación de pruebas, es considerado como una herramienta de integración continua y de detección de fallos, que, de acuerdo con el estudio de [22] y [23], estas características permiten alinear el producto de software hacia el aseguramiento de la calidad, en atención a diversas evaluaciones, como aceptabilidad, medición, conformidad y estructura en distintas fases y partes del desarrollo. Por otro lado, [24] y [25] resaltan las características que toma un equipo al emplear desarrollo basado en comportamiento, como gestión de oportunidades, orientación de performance, contribuciones, preferencias y revisión de objetivos, que permite seguimiento y mejora continua.
[26] y [27] indican que, aunque el mayor esfuerzo de BDD sea en la fase de construcción y pruebas, su enfoque se puede aplicar en diversas partes del desarrollo de software. En la fase de planificación, para entender el comportamiento del negocio; en la fase de análisis, para evaluar el comportamiento de negocio y desglosarlas en capturas del comportamiento para el sistema, y en la fase de implementación, en que se llevan a cabo las pruebas de aceptación. Todas estas fases son derivadas de diversos escenarios en diferentes etapas, que siguen un conjunto de reglas de mapeo, del cual se obtiene un pensamiento dirigido por comportamientos para desarrolladores, que facilita visualización de desarrollo, roles, responsabilidades y diversos objetos que ayudan a tener un producto de software más estructurado y dirigido.
Los conceptos mencionados por [4], [5] y [26] detallan que BDD es un proceso que puede ser usado con distintos tipos de metodologías para el desarrollo de software en sus diferentes etapas, y su importancia recae en dirigir correctamente la construcción del software realizando mapeos y mejoras a través de pruebas detalladas de la estructura y componentes, que obtiene como resultado de su implementación una documentación detallada en un lenguaje comprensible como es Gherkin, el cual usa composición lógica de programación que tiene el software y da como resultado documentación sintetizada basada en funcionalidades, que [28] menciona como un refinamiento de buenas prácticas para asegurar la calidad del software.
Estructura del desarrollo guiado por comportamiento
[4] y [28] representan la estructura de BDD a través de un flujograma de procesos, que incluye una sección reiterativa de TDD.
Por otro lado, las investigaciones de [5], [29] y [30] tienen una representación distinta y detallada de BDD basado en las pruebas de carga impulsadas por el comportamiento o behavior-driven load testing (bdlt), colocando, en primera instancia, el escenario donde se probarán las diferentes características, desglosadas en tres especificaciones: Dado (Given) donde van las precondiciones del suceso o la situación a probar, Cuando (When) que define la acción que se realizará ante dicha situación y Entonces (Then) que es el resultado esperado de la acción ejecutada.
De acuerdo con la observación de las figuras 1 y 2, BDD se basa en un análisis a través de escenarios dada la característica o funcionalidad del sistema, que cuenta con tres componentes principales: given, when y then, que prácticamente es la especificación en detalle de una acción dada en un suceso con un resultado esperado, el cual representa cierta funcionalidad del sistema.
Buenas prácticas del desarrollo guiado por comportamiento
Como afirma [31] los escenarios siempre prueban una funcionalidad, son representaciones de historias de usuario en que es necesaria la especificación en detalle de cada componente y método funcional con palabras clave. [32] y [33] argumentan que el uso de Gherkin permite obtener documentación en 60 lenguajes bajo sintaxis descriptiva del comportamiento. Asimismo [34] y [35] expresan que la prueba de escenarios nos facilita conocer ampliamente cada parte funcional del sistema con la posibilidad de observar errores mediante pruebas dirigidas, y así realizar la corrección respectiva de manera anticipada.
Organización de características por carpetas de acuerdo con los escenarios
El conjunto de escenarios son la representación de una característica de nuestro sistema, por tanto, su organización es fundamental. Según [36] y [37] el proceso paulatino de etapas y pruebas del software tiene como resultado la producción de documentación amplia, de diversas funcionalidades, por lo cual es importante su clasificación, no solo para mantener una estructura, sino para ubicar ciertos parámetros de medición para su análisis y aprobación.
Hablar el mismo idioma de los clientes para facilitar la comunicación
[26] y [38] indican que la comunicación con el cliente es vital para la claridad de los requerimientos, debido a que el producto está basado en sus necesidades; BDD con el lenguaje Gherkin permite el diálogo mediante comunicación basada en comportamiento, de manera que guíe y encamine el desarrollo acorde con lo que el cliente solicite. [39] y [40] afirman que la estructura de BDD es entendible ante cualquier tipo de cliente por su lenguaje de representación simple y detallada que a su vez muestra el objetivo y la situación.
Uso de etiquetas en la división de características y escenarios
En diversos proyectos, la estructura interna del código es una característica problemática, ya que algunas funcionalidades representan duplicidad e, incluso, algunas podrían ser parecidas pero usadas para diferentes propósitos. [25] resalta en su proyecto de modelamiento que el uso de etiquetas es fundamental para identificar problemas en el código o duplicidad de métodos, lo cual es respaldado por [41] que indica que estas acciones ayudan a evitar errores como borrar una funcionalidad que parece ser duplicada cuando el propósito es otro, asimismo, generar seguridad, consistencia, eficiencia y calidad en el producto final.
Escenarios independientes para no generar dependencia
La dependencia de funcionalidades es el factor principal por el que los sistemas empiezan a generar fallas según el análisis realizado por [40]. Asimismo, según la investigación de proyección a cambios de [42], indican que la independencia de escenarios es un punto favorable que permite trabajar de manera más ágil el desarrollo del proyecto y realizar correcciones puntuales de fallas, sin afectar la estructura completa o característica del software.
[43] manifiesta en su experimento de integrar BDD en un sistema que genera códigos de prueba a partir de diagramas de problema que el desarrollo basado en comportamiento le sirvió como facilitador del entendimiento general de este y le ofreció una guía intuitiva a las partes interesadas para su respectiva comprensión y solución a los problemas planteados de manera gráfica.
Del mismo modo [44] y [45] indican que su experimentación en la prueba de calidad de los escenarios y las buenas prácticas de la estructura BDD son una representación concisa, confiable, negociable, priorizada, comprobable, pequeña, comprensible, inequívoca y valiosa de todas las características funcionales del software, categorizándolo como una metodología fundamental para el desarrollo de la calidad estructural, funcional y documental de un producto de software. De modo similar a los estudios de [46] y [47], que, aplicando BDD en proyectos de código abierto, resaltan que la integración es beneficiosa para cualquier tipo de metodología, ya que al ser flexible permite aprovechar lo mejor de diversas otras metodologías de manera integrada.
Cada una de las buenas prácticas analizadas conllevan esfuerzo y especialización en el lenguaje Gherkin, tal y como lo experimenta [48] al aplicar BDD en el desarrollo de aplicaciones móviles para reducir errores. Indica que, siendo un lenguaje óptimo de entendimiento, necesita ser realizado con precaución y detalle, de tal forma que permita diferenciarse espacios de códigos, métodos y funcionalidades en diferentes escenarios, para caracterizar el comportamiento del software y asegurar el entendimiento claro del usuario final a través de comunicación directa y lenguaje natural.
En función de las necesidades o funcionalidades que se presentan, se pueden crear escenarios que pueden ser reutilizados, y así permitir ahorrar tiempo en la fase del prediseño o reestructuración de las nuevas pruebas, tomar esto como mejora continua según experiencias y establecer estándares según valores de calidad que permitan medir lo apto y óptimo del código testeado.
Asimismo, los hitos de desarrollo pueden ser referentes de calidad si se incluyen pautas de BDD como el uso de su estructura que intensifica el reconocimiento de errores, mejora la categorización de segmentos de código, organiza el desarrollo del proyecto y ayuda a que el cliente de software también sea partícipe opinando desde su perspectiva en un lenguaje entendible.
CONCLUSIONES
Las buenas prácticas son el referente a seguir para alcanzar el éxito en la práctica de esta metodología. Con esta revisión, se pudo evidenciar que el desarrollo guiado por comportamiento, su composición y estructura permite llegar de manera eficiente a los clientes o interesados, es decir, que la comunicación sea fluida con un lenguaje entendible empresarial como Gherkin. Asimismo, las pautas dadas facilitan estructurar el código y reconocer sus funciones, características y descripciones.
Las buenas prácticas identificadas son uso de etiquetas en la construcción del código, empleo de escenarios para el diseño de las funcionalidades del software, agrupación de los escenarios en carpetas de acuerdo con sus características y hablar el mismo idioma con los clientes para facilitar la comunicación.
Seguir el modelo BDD sería sinónimo de asegurar la calidad funcional de un producto de software con una tasa mínima de errores y un porcentaje alto de funcionalidad total. Buenos conceptos como generar componentes sin dependencia y reutilizar código son bien recibidos en este modelo, con el cual se podrá dirigir en detalle el correcto desarrollo de software y alcanzar la madurez de trabajo personal como también del producto.
