Instituto Tecnológico de Las Américas

Nombre:
Zeyddy K.
Apellido:
Sosa
Matrícula:
2019-9135
Tema:
Caso de estudio de la empresa CTTS
Materia:
Administración de Proyectos de Software
Grupo:
2
Facilitador:
Willis Polanco
Fecha de entrega:
15/08/2022
 Behavior Driven Development
BDD o Behavior Driven Development es un proceso de desarrollo de software nacido
desde el desarrollo guiado por pruebas. El BDD es una práctica derivada del Test-
Driven Development (TDD), que también se guía por el enfoque Specification by
Example (SBE). Dicho método define los requisitos y pruebas funcionales de la
aplicación por medio de ejemplos realistas y no abstractos.

Debido al análisis brindado por BDD sobre el

comportamiento del software en desarrollo, la
documentación creada también se ve
beneficiada. Tal como explica Tricentis, estos
registros son fáciles de mantener y pueden ser
consultados por cualquier persona relacionada
a la aplicación.

Con ello, los marcos BDD buscan una mayor

colaboración y comunicación entre los equipos técnicos y desarrolladores del
software.

Además, BDD es compatible con las principales metodologías y herramientas de

pruebas de automatización.

¿Cómo funcionan?
Como puede intuirse por su propio nombre, el behavior-driven development se guía
por el comportamiento que desea obtenerse del software final. Gracias al llamado
lenguaje ubicuo, una especie de lenguaje común, incluso los no expertos pueden
describir comportamientos específicos. El lenguaje ubicuo nació en el ámbito del
domain-driven design (DDD, diseño guiado por el dominio), una metodología que, al
igual que el BDD, se centra en los ámbitos de aplicación del producto. Ambos
planteamientos tienen en cuenta todas las áreas involucradas en el proyecto de
software y las interconectan más allá de los frameworks, los lenguajes de
programación o las herramientas concretas, todo gracias al lenguaje ubicuo o común.

No obstante, el behavior-driven development no puede prescindir totalmente de las

herramientas y los marcos de trabajo: hay que respetar ciertas reglas para que los
casos de prueba que se definan puedan traducirse a un lenguaje de programación
ejecutable. Por este motivo, las especificaciones en BDD no se expresan en forma de
texto corrido, sino que, con ayuda deherramientas BDD como JBehave, Cucumber o
Behat, se ajustan a una estructura determinada que hace posible su correcta
implementación. Sin embargo, manejar estas herramientas es mucho más fácil que
aprender un lenguaje de programación convencional. A continuación, te explicamos la
estructura que normalmente se sigue en el desarrollo guiado por comportamiento:

Primero, se realiza un análisis de requisitos en el que se especifican las tareas, los

objetivos y las funciones del software. En esta fase, la empresa se pregunta (o
pregunta a los clientes) qué debe ser capaz de hacer el software.

Una vez se han identificado todas las funciones, estas se describen en forma de
escenarios predefinidos: el objetivo es pensar en todas las situaciones posibles en las
que el software debería reaccionar dando una respuesta concreta.

El siguiente paso es establecer la respuesta que se espera en cada escenario o

situación mediante un esquema tipogiven-when-then, es decir, dado-cuando-
entonces: dado describe el estado del software antes del test; cuando describe la
acción durante el test y entonces describe el estado del software tras el test.

Según qué herramienta de BDD se utilice, el vocabulario usado puede variar

ligeramente. Estas herramientas están disponibles para los lenguajes de
programación más comunes, como Java, JavaScript, Python o Ruby.

Preparación de las pruebas en BDD

A partir de la información brindada por Inuuy podemos definir un marco a seguir para
utilizar BDD.

Antes de realizar pruebas usando BDD, es de esperar que los desarrolladores y

testadores de la aplicación conozcan:

❖ El punto de inicio de la prueba.

❖ Lo que se debe probar.
❖ No se debe probar.
❖ La frecuencia con que se debe realizar el proceso.
❖ El nombre de cada prueba y/o compilado de pruebas.
❖ El mecanismo para identificar fallos en las pruebas.

Generalmente, para evitar los problemas más comunes, el BDD usa las pruebas de
unidad y aceptación.

Al realizar pruebas unitarias, se sugiere nombrarlas con oraciones completas. Vale

decir, que el lenguaje con que se programen en este tipo de pruebas sea con verbos
condicionales, como “Should” (en inglés). También se aconseja que las palabras sean
terminologías comerciales claras y en orden de valor comercial. Las tareas de un
software deben programarse según un orden determinado. Al programar un carro de
compra, por ejemplo, se debe probar la función de “agregar productos” a ese carro y
después la función de “comprar productos”.

En el caso de las pruebas de aceptación, al escribirlas deben venir en Scaled Agile

Framework (SAFe) de una historia de usuario. Es decir, el “Interesado/Actor” (entidad
que solicita un software) quiere una “capacidad/característica” que genere
“beneficios/resultados positivos”.

De igual modo, es vital comprender la historia del usuario del proyecto. Esta historia
de usuario es utilizada en la gestión del proyecto y el desarrollo de este. Es una
manera informal de usar el lenguaje natural para describir las características del
sistema de software.

Aunque todo depende del enfoque del proyecto, diferentes integrantes de áreas del
desarrollo de software pueden escribir historias de usuarios. Hablamos de directores,
Líderes de proyecto,
Desarrolladores, Ejecutores de
pruebas, etc.

Gherkin, el lenguaje
programático para BDD
El lenguaje usado para BDD es
Gherkin. Gherkin es un lenguaje
fácil de usar ya que es similar al
lenguaje natural de las personas.
Es posible utilizarlo para la realización de pruebas como para escribir historias de
escenarios de usuarios.

Según el sitio Abstracta, este lenguaje, por su simplicidad, puede ser escrito por
individuos sin grandes experiencias en el área de programación. Además, a pesar de
que es común ver procesos realizados en Ingles, Gherkin permite más de treinta
idiomas para trabajar.

Generalmente las pruebas realizadas con Gherkin son almacenadas en archivos

“.Feature”. Estos archivos deben ser versionados junto al código fuente de la
aplicación que se está testeando.

Estos archivos contienen los siguientes términos:

 ❖ Feature: Es el nombre de la función que se va a testear. También se puede
considerar el nombre de la prueba.
❖ Scenario: Es el escenario de la función a poner a prueba.
❖ Given: Son las condiciones previas a la acción de la función.
❖ When: El conjunto de acciones que se ejecutarán
❖ Then: Los resultados que se esperan con el testeo. A partir de ellos, se realizan
las validaciones.

Un ejemplo explicativo de estos tres últimos parámetros es el que brinda Tricentis:

❖ Given: Dado que me estoy registrando para una prueba gratuita (Contexto)
❖ When: Cuando envío los detalles requeridos (Sucede una acción)
❖ Then: Entonces recibo un enlace a la descarga. (Resultados)

Usualmente debe haber solo una función por archivo y en ella puede haber diversos
escenarios de prueba.

Diseño de pruebas de aceptación bajo el enfoque BDD

A partir de lo indicado por Abstracta, estas pruebas pueden ser escritas por diferentes
integrantes del equipo. Puede ser el Product Owner del proyecto o algún integrante de
las áreas testeo o de desarrollo.

Una práctica aconsejable es que sea un trabajo en conjunto entre diferentes

departamentos, aunque sea el Brainstorming. De este modo, hay una cooperación de
diversos puntos de vista para el diseño de historias de usuarios y pruebas.
Posteriormente, la persona responsable de las pruebas debe verificar que estén bien
escritas y que cubran los parámetros requeridos para testear.

¿TDD o BDD?
Aunque TDD o BDD parecen muy similares, la principal diferencia entre ambas está en
el alcance. TDD es una práctica de desarrollo, enfocada en cómo escribir el código y
cómo debería funcionar. Mientras que BDD es un enfoque de equipo que hace hincapié
en por qué debes escribir ese código y cómo se debería comportar.

En TDD el desarrollador escribe los tests mientras que en BDD el usuario final, junto al
resto del equipo multidisciplinar, escriben los tests.
Si comparamos los 2, podemos decir que TDD se ocupa solo a nivel unitario o una
porción pequeña de la aplicación en desarrollo, y que BDD se va a ocupar de que las
pruebas sobre la integración de esas unidades (a un nivel de negocio), no solo sean
simples pruebas sino también documentación viva de la aplicación al alcance de
cualquier usuario y en su mismo idioma (términos que usa comúnmente).

Mi recomendación se apoya en ambas soluciones: TDD y BDD. Si tienes capacidad de

implicar a toda la organización (clientes, usuarios y dirección con enfoque BDD),
generarán historias de usuario muy enriquecidas con las que podrás definir y acotar
un producto mínimo viable (MVP), además de alinear el objetivo del desarrollo y la
estrategia digital entre todos los implicados.

Una vez esté todo el mundo esté alineado, será el mejor momento para que el director
técnico o el equipo de desarrollo establezca un
enfoque TDD, con lo que podrás prever y definir
con mucho más detalle las principales
características técnicas de tu desarrollo,
adelantándote a errores de programación que el
usuario final podría experimentar.