UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

“BEHAVIOR DRIVEN DEVELOPMENT EN

CONTROL DE CALIDAD AUTOMATIZADO ”

TRABAJO FINAL PRESENTADO PARA OBTENER EL

CERTIFICADO DE DIPLOMADO EXPERTO EN DESARROLLO DE
APLICACIONES EMPRESARIALES VERSIÓN I

POSTULANTE : JORGE BELTRAN AGUILAR

TUTOR : LIC. MAURICIO GIOVANNY VISCARRA RIVERA

Cochabamba – Bolivia 2018

 ii

Dedicatoria

Dedico esta tesis a mis padres por siempre apoyarme y darme fuerza para seguir

adelante, ellos me enseñaron que nunca hay que rendirse en esta vida nada es fácil, pero con

esfuerzo y voluntad todo es posible, estoy bien agradecido con Dios por darme una familia

linda y hermosa.
 iii

Agradecimiento

Agradezco A Dios primeramente por guiarme y Al Lic. Mauricio Viscarra por su

paciencia ,comprensión y a mi familia por apoyarme en mi carrera y a las personas que me

apoyaron muchas gracias

 INDICE DE CONTENIDO
RESUMEN .............................................................................................................................................. 6

INTRODUCCIÓN .................................................................................................................................... 7

1 GENERALIDADES ......................................................................................................................... 8

1.1 ANTECEDENTES GENERALES ................................................................................................ 8

1.2 ANTECEDENTES ESPECÍFICOS .............................................................................................. 8

2 METODOLOGÍA ............................................................................................................................. 8

3 BDD (BEHAVIOR DRIVEN DEVELOPMENT) ................................................................................. 8

3.1 DEFINICIÓN DE BDD................................................................................................................. 8

3.2 BDD EN METODOLOGÍAS ÁGILES ........................................................................................... 9

3.3 CARACTERÍSTICA BDD .......................................................................................................... 10

3.4 LOS PRINCIPIOS DE BDD ....................................................................................................... 12

3.5 BENEFICIOS DE BDD.............................................................................................................. 15

3.6 LÍMITES BDD ........................................................................................................................... 17

3.7 ACTIVIDADES PRINCIPALES DE BDD.................................................................................... 18

3.8 HERRAMIENTAS ..................................................................................................................... 21

4 CÓMO IMPLEMENTAR UN PROCESO BDD................................................................................ 34

4.1 DEFINIR LOS ESCENARIOS A DESARROLLAR ..................................................................... 34

4.2 CREAR TEST AUTOMÁTICOS QUE VALIDEN LA FUNCIONALIDAD...................................... 34

4.3 CREAR UN ENTORNO DE TRABAJO...................................................................................... 35

4.4 EVOLUCIÓN Y ADAPTACIÓN.................................................................................................. 35

5 CONCLUSIÓN .............................................................................................................................. 37

6 BIBLIOGRAFÍA ............................................................................................................................. 38

4
 5
ÍNDICE DE FIGURAS

Figura 1 Ciclos de un conjunto de pasos a seguir en BDD ......................................................... 9

Figura 2 Escenario de un login ................................................................................................. 12

Figura 3 Gherkin Básico ........................................................................................................... 14

Figura 4 Historia de usuario en BDD ........................................................................................ 19

Figura 5 Agregando dependencia ............................................................................................. 22

Figura 6 My first feature ............................................................................................................ 22

Figura 7 Estructura de Archivos Serenity .................................................................................. 23

Figura 8 Reporte de Serenity .................................................................................................... 24

Figura 9 Feature file.................................................................................................................. 25

Figura 10 Steps ........................................................................................................................ 25

Figura 11 Step Definition .......................................................................................................... 26

Figura 12 Reportes Cucumber.................................................................................................. 27

Figura 13 Creando un Archivo SpecFLow con Visual Studio .................................................... 28

Figura 14 Creando una carpeta de features con Visual Studio ................................................. 28

Figura 15 Creando feature file con SpecFlow ........................................................................... 29

Figura 16 Feature file de un login ........................................................................................... 29

Figura 17 Write story ............................................................................................................... 29

Figura 18 Map steps to java ..................................................................................................... 29

Figura 19 Reporte story ........................................................................................................... 29

Figura 20 Feature file................................................................................................................ 29

Figura 21 Steps definition ........................................................................................................ 29

Figura 22 Reporte Selenium webdriver .................................................................................... 29

Figura 23 Vario features file ..................................................................................................... 29

Figura 24 Test Automáticos ..................................................................................................... 29

 6
RESUMEN

BDD es uno de los términos de moda en el desarrollo de software en los últimos años, a pesar
de ser un término muy utilizado no todo el mundo sabe exactamente qué es BDD (conocido en
inglés como Behavior Driven Development o por su sigla BDD).

Behavior Driven Development no reemplaza las pruebas unitarias, si no que verifica el

comportamiento que pueden involucran muchos métodos trabajando juntos, las pruebas unitarias
prueban modelos o métodos individuales, lo que se hará es escribir pruebas que verifiquen el
comportamiento del código, si es correcto desde el punto de vista del negocio.

Para escribir las pruebas se lo realiza con el código fuente de la funcionalidad para que estas
pruebas pasen correctamente, después se refactoriza el código fuente en caso de ser necesario.

BDD también es una técnica de desarrollo ágil de software, que fomenta la colaboración entre los
clientes, los desarrolladores y los ingenieros de calidad.

Se puede considerar una evolución del desarrollo guiado por los tests (TDD) en el cual se enfatiza
más en las especificaciones finales del software antes que en detalles técnicos.

Como bien lo indica su nombre BDD, no se trata de una técnica de testing, sino de una estrategia
de desarrollo (así como TDD test driven development), lo que se plantea es definir un lenguaje
común para el negocio y técnicos utilizándolo como parte inicial del desarrollo y permita un
software más sencillo y eficiente.
 7
INTRODUCCIÓN

En la actualidad los sistemas de software desarrollados alcanzan altos niveles de complejidad,

de manera que no se puede descuidar el más mínimo detalle ya que puede ocasionar grandes
impactos negativos en las empresas, Behavior Driven Development es una técnica de desarrollo
ágil orientada al negocio y comportamiento de una aplicación.

También se basa en prácticas ágiles que incluyen en particular, el desarrollo basado en pruebas
(TDD) y el diseño controlado por el dominio (DDD), pero lo más importante es que BDD
proporciona un lenguaje común basado en oraciones simples y estructuradas expresadas en
inglés (o en el idioma nativo de las partes interesadas) que facilitan la comunicación entre los
miembros del equipo del proyecto y las partes interesadas del negocio.

Para comprender mejor las motivaciones y la filosofía que impulsan las prácticas de BDD, es útil
comprender de dónde viene BDD.

Su principal objetivo es preguntar qué debería hacer la aplicación antes y durante el proceso de
desarrollo, esto se consigue mediante tests de comportamiento o especificaciones, que son
escritas por los desarrolladores y que se encargan de implementar un fin común, mejorar la
calidad del software producido.

También ayuda a definir esos flujos, pero no ayuda a diseñar el software, como lo hace TDD, sin
mencionar si se está limitados con los sistemas existentes por tanto, ambas metodologías son
complementarias.

BDD ha evolucionado a partir de prácticas ágiles establecidas y está diseñado para hacerlas más
accesibles y efectivas para los equipos en la entrega de software ágil.

Con el tiempo fue creciendo BDD y abarcando mucho más un amplio análisis ágil y pruebas de
aceptación automatizadas de este modo, permitiendo a los equipos nuevos para el desarrollo ágil
ponerse al día rápidamente utilizando esta técnica extremadamente productiva y eficiente.

De esta manera se puede asegurar el desarrollo de software de calidad, el cual cumpla con los
requerimientos solicitados y que funcione correctamente.

El resultado de la siguiente monografía ayudará y facilitará el comportamiento del sistema

mediante, criterios de éxito y su objetivo principal de todas las empresas está diseñado para
ayudar a los equipos a crear y entregar software más valioso y de mayor calidad de forma más
rápida permitiendo a una empresa tener éxito, garantizando funcionalidad correcta
 8
1 GENERALIDADES

1.1 Antecedentes Generales

En BDD se escriben las pruebas de aceptación como ejemplos para que cualquier miembro del
equipo sea capaz de entender, se hace uso del proceso de escribir ejemplos para obtener
retroalimentación de las partes interesadas del negocio.

Es así que muchos equipos están trabajando exitosamente para desarrollar y entregar software
más efectivo y eficiente, permitiendo de esta forma un aprendizaje constante.

BDD alienta a los analistas de negocios, desarrolladores de software y evaluadores a colaborar

más estrechamente permitiendo de esta forma expresar los requisitos de una manera más
concreta, de forma que tanto el equipo de desarrollo como las partes interesadas del negocio
puedan comprender fácilmente.

1.2 Antecedentes Específicos

BDD ayuda a los equipos a concentrar sus esfuerzos en la identificación, comprensión y construcción de
características valiosas que importan a las empresas, y se asegura de que estas características estén
bien diseñadas y bien implementadas.

Las herramientas de BDD pueden ayudar a convertir estos requisitos en pruebas automatizadas, que
ayuden a guiar al desarrollador, verificar la función y documentar lo referente a la aplicación.

2 METODOLOGÍA
Para el presente trabajo se utilizarán a continuación los siguientes métodos de investigación:

• Método Bibliográfico, debido a que se realizará la lectura y compilación de libros

relacionados al tema de estudio.
• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente
documentos relacionados al tema de estudio, para la redacción del Plan de Emergencia.

3 BDD (BEHAVIOR DRIVEN DEVELOPMENT)

3.1 Definición de BDD
BDD es una metodología ágil de escala múltiple, y de alta automatización, que describe un ciclo
de interacciones con producciones bien definidas, resultando en el envío de software funcional,
probado y trascendente.

En esencia BDD ayuda a la comunicación entre las partes interesados como el “stakeholders”,
establece una conversación común y un lenguaje acordado para que todos se entiendan,
utilizándolo como parte inicial del desarrollo y el testing.
 9
Figura 1 Ciclos de un conjunto de pasos a seguir en BDD.

• Identificar la característica del negocio.

• Identificar escenarios bajo la característica seleccionada.

• Definir los pasos para cada escenario.

• Ejecutar característica.

• Ejecute la función y el código para hacer que los pasos pasen

• Código de refactoriza.

• Ejecuta función.

• Ejecuta función Generar informes de prueba.

Figura 1 Ciclos de un conjunto de pasos a seguir en BDD

Fuente: Libro (John Ferguson Smart BDD in Action)

3.2 BDD en Metodologías Ágiles

Esta estrategia encaja bien en las metodologías ágiles, generalmente en ellas se especifican los
requerimientos como historias de usuario.

Estas historias de usuario deberán tener sus criterios de aceptación, y de ahí se desprenden
pruebas de aceptación, las cual pueden ser escritas directamente en lenguaje Gherkin.
 10
3.3 Característica BDD

Las características de (Behavior Driven Development) son:

• Un lenguaje ubicuo.

Para muchos, el lenguaje usado para expresar un concepto tiene un impacto en la forma en que
se piensa. “Las abstracciones y conceptos que usamos para expresarnos en cualquier lenguaje,
forman el camino sobre el problema que se esta resolviendo”.

Esta teoría está apoyada por la hipótesis del lingüístico Sapir-Whorf, el cual postula que hay “una
relación sistemática entre las categorías gramaticales de la lengua en la que habla una persona
y cómo esta persona entiende el mundo y cómo se comporta”.

Para el software, esto implica que el lenguaje que usamos para describir las construcciones de
software tiene un impacto en cómo creamos estas construcciones; cambiando el lenguaje,
afectamos al código que creamos.

BDD apoya el uso de lenguajes significativos de dos formas primero, se centra en “obtener las
palabras correctas”, motivando nombres apropiados para clases, métodos y variables.

• Centrado en el diseño

“Un diseñador en cascada parte de una comprensión del problema y crea algún tipo de modelo
para una solución, el cual pasa a quien lo implementará.

Un desarrollador ágil hace exactamente lo mismo, pero el lenguaje que usa para el modelo es
código fuente ejecutable en lugar de documentos.”

Una de las consecuencias más importantes de practicar TDD es su influencia en el diseño del
código resultante.

El código test-driven tiene menos defectos que el código no dirigido por pruebas y normalmente
es más cohesivo y está menos ligado que el no dirigido por pruebas.

Sin embargo, el énfasis en las pruebas limita la eficacia de TDD en diseño dirigido, BDD reconoce
que el diseño es uno de las aportaciones más importantes de las pruebas, produciendo un
lenguaje y herramientas que soportan la creación de código bien diseñado.

• Centrado en el comportamiento

Centrándose en el comportamiento, los frameworks de BDD rompen el tradicional mapeo 1 a 1

de las clases de pruebas unitarias para una clase de producción, BDD anima a usar un mapeo M
 11
a N, permitiendo tantas clases de especificación como sean necesarias para especificar el
comportamiento requerido.

• BDD Frameworks

Los primeros frameworks de BDD se centraron en el nivel de compresión de aceptación algunos

frameworks como JBehave 1 permiten que el comportamiento de una aplicación sea descrito en
2
términos de historias y escenarios Subsecuentemente, los frameworks como RSpec y NSpec
3
se centran más en el nivel de pruebas del código, ofreciendo un equivalente a la característica
de XUnit, para niveles más bajos de especificaciones y ambas aproximaciones son legítimas y
usan lenguaje ubicuo para describir el comportamiento deseado del sistema en el nivel apropiado.

• Gherkin

Gherkin, es un lenguaje comprensible por humanos y por ordenadores, se trata de un lenguaje

describe las funcionalidades y define el comportamiento del software, sin entrar en la
implementación.

Como también es un lenguaje fácil de leer, fácil de entender y fácil de escribir, es un lenguaje
denominado por Martin Fowler Como: 'Business Readable DSL', es decir, 'Lenguaje Específico
de Dominio legible por Negocio'.

Otro aspecto interesante es que Gherkin puede ser utilizado en otros idiomas, no sólo en inglés,
actualmente Gherkin soporta más de 60 idiomas.

Las principales características de Gherkin se utiliza 5 palabras, que construye sentencias que
describe las funcionalidades:

• Feature: Indica el nombre de la funcionalidad a probar, debe ser un título claro y explícito.
Incluimos aquí una descripción en forma de historia de usuario: “Como [rol] quiero

1
Jbeahave es un framework Java para mejorar la colaboración entre desarrolladores

2
RSpec es una herramienta de desarrollo basada en el comportamiento para los programadores
de Ruby

3
NSpec es un marco de prueba de batalla endurecido para C #
 12
[característica] para que [los beneficios]”, sobre esta descripción se empezará a construir
nuestros escenarios de prueba.

• Scenario: Describe cada escenario que vamos a probar.

• Given: Provee contexto para el escenario en el que se ejecutara el test, incluye los pasos
necesarios para poner al sistema en el estado que se desea probar.

• When: Especifica el conjunto de acciones que lanzan el test, la interacción del usuario
que acciona la funcionalidad que deseamos testear.

• Then: Especifica el resultado esperado en el test, observamos los cambios en el sistema

y vemos si son los deseados.

Para automatizar estas pruebas se necesita trabajar herramientas, como Cucumber, que
entiende perfectamente el lenguaje Gherkin, en el ejemplo siguiente;

Figura 2 Escenario de un login Escenario de un login; pasos para ingresar a una aplicación en el
cual se utilizó el lenguaje de Gherkin

Figura 2 Escenario de un login

Fuente: (Elaboración propia)

3.4 Los principios de BDD

BDD pretende ayudar a poner foco en la entrega de valor de negocio, que fue priorizado y verifica
a través de la utilización de un vocabulario en común (el lenguaje ubicuo al igual que DDD).

Para alcanzar tal objetivo se construye los siguientes pilares:

• El análisis por anticipado, diseño y planeamiento.

 13
Con este primer pilar nos estamos refiriendo en cierta manera al viejo método de cascada en el
cual todo el relevamiento de requerimientos se realizaba dentro de una primera etapa y no se
podía modificar durante el desarrollo de las siguientes etapa.

La idea de no realizar demasiado el exceso detallado, permite que las metodologías ágiles
propone minimizar el tiempo y el alcance, buscando la manera de verificar los más pronto posible,
esto realizar estimaciones más certeras en base a las condiciones actuales.

• Tanto el “Negocio” como los “técnicos” debe referirse al mismo sistema de la misma
manera.

Todo es acerca del sistema que debería estar haciendo, BDD es tal como mencionamos antes
acerca de obtener la palabra indicada y logra a través del lenguaje consistente de la comunicación
de forma tal que las diferencias entre la gente de negocio y los técnicos (en este caso incluiría
también a los BA y QA, no solo a los DEV).

Al definir un sistema en términos de su comportamiento, sirve porque posee distinta importancia

en cada nivel de abstracción, sirve porque es lo que tiene en común el sistema que todos los
participantes entienden de la misma manera.

• Los sistema debería tener un valor de negocio identificable y verificable.

El comportamiento de un sistema, es porque se agrega específicamente un valor de negocio al

sistema.

La idea es evitar incorporar nuevas funcionalidades o características a un sistema por el simple

motivo que esté “de moda” o la competencia les brinden cuando en realidad dichas características
no brindan al negocio un valor.

Es por ello que BDD es de suma importancia al valor asociado a cada historia de usuario, ya que
esta información puede ser utilizada en la toma de decisiones de planeamiento y para guiar a
todos hacia un buen entendimiento de los costos/beneficios.

• Trabajar de manera colaborativa.

BDD es una práctica colaborativa tanto para los miembros del equipo y el cliente, como para los
miembros del equipo internamente

• Aceptar y trabajar la incertidumbre.

Es una realidad que los equipos que trabajan siguiendo las prácticas de BDD, saben que no
pueden adelantarse a todos los imprevistos que conlleva un proyecto, por ello se ayudan con
 14
métodos tales como el feedback 4continuo del trabajo, que les indica que tan encaminados se
encuentran en la solución y además brindan una herramienta para adelantarse a posibles
inconvenientes.

• Utilizar ejemplos.

Los ejemplos son la herramienta más importante en BDD y cumplen un rol principal dentro de la
metodología, ya que son una forma efectiva de comunicar los requerimientos de manera precisa
y

clara sin ambigüedades.

En BDD se escriben en el lenguaje ubicuo mencionado anteriormente y se conoce como Gherkin

se trata de un lenguaje con el que describir las funcionalidades y define el comportamiento del
software, sin entrar en su implementación.

Figura 3 Gherkin Gherkin Básico se trata de lista de pasos que llevan a un resultado

Figura 3 Gherkin Básico

Fuente: ( https://www.bit.es/knowledge-center/bdd)

• Escribir especificaciones ejecutables y no pruebas automatizadas.

Esta diferencia es vital para el desarrollo de BDD como práctica en un equipo, si bien parece a
primera impresión que ambas cosas son lo mismo o tienen el mismo valor, esto no es así.

4
Feedback es una realimentación o respuesta para la mejora continua
 15
Pruebas automatizadas puede ser cualquier tipo de prueba que se ejecuta de forma automatizada
utilizando alguna herramienta.

En cambio, especificaciones ejecutables son pruebas automatizadas que ilustran y verifican como
la aplicación entrega un requerimiento específico de negocio, involucran tanto la validación como
la comunicación, ya que el propósito es que los reportes que se generen como resultado de la
ejecución deben ser entendibles por todos los involucrados en el proyecto.

• Escribir especificaciones de bajo nivel y no pruebas unitarias.

BDD no solo se trata de definir especificaciones ejecutables sino también de contar con calidad
de código, es por ello que hablamos de especificaciones de bajo nivel.

En este punto es donde entra en juego la integración con TDD, aunque con una pequeña
variación,

el DEV no piensa en término de pruebas unitarias, sino que escribe especificaciones técnicas que
describen como la aplicación se tiene que comportar, como dado un valor de entrada tiene que
producir un valor determinado de salida.

• Entregar documentación.

Los reportes que se obtienen de la ejecución de las especificaciones, no son simplemente

reportes técnicos, ya que como mencionamos anteriormente estos reportes deben ser
entendibles por todo.

Decimos que las documentación es porque se actualiza luego de cada ejecución, que al ser
automatizada se ejecuta de manera continua y constante en el tiempo.

3.5 Beneficios de BDD

Siendo BDD una metodología que toma buenas prácticas ya probadas provenientes de otras
metodologías conocidas, es de asumir que los beneficios de utilizarla son muchos y variados.

Aquí hay que tener en cuenta que, si bien es una metodología con sus principios definidos, todo
lo que plantea BDD al igual que otras metodologías ágiles, son guías prácticas, buenas prácticas
para equipos.

Dependerá entonces de cada equipo, sus características y su puesta en práctica de las guías
planteadas, los beneficios específicos que el equipo tendrá, además dependerá también de las
necesidades que tenga ese equipo.
 16
A continuación, mencionaremos los principales beneficios que surgen de implementar BDD:

• Reducción de costos: Con este punto hacemos referencia tanto a los costos monetarios
para el negocio que se reducen gracias a que existe un mayor foco en lo que el negocio
necesita y espera del producto.
Al comprender la visión y el objetivo del negocio, no se desperdicia tiempo (se prioriza de
manera efectiva) en implementar cosas que no tengan un valor para el negocio y que le
permitan alcanzar el objetivo.
Pero también se hace referencia a los costos en cuanto a una reducción en el porcentaje
de errores y defectos que se producen en cada iteración de implementación, esto se debe
principalmente a que todos los miembros del equipo de desarrollo tienen conocimiento
desde el comienzo como el sistema debe comportarse.
• Los cambios son más fáciles y seguros de realizar: Gracias a que existe feedback
constante, que permite llevar un seguimiento del estado del proyecto, la implementación
es flexible para adaptarse rápidamente a los cambios, ya que al contar con
especificaciones ejecutables y especificaciones de bajo nivel, se puede implementar un
cambio volver a ejecutar todo y asegurarnos que el cambio no introdujo errores y se
implementó con éxito.
• Releases más rápidos: para los clientes en el mayor aspecto positivo de tener
rápidamente un requerimiento en funcionamiento.
El hecho que los releases sean más rápidos se deben principalmente a las pruebas
automatizadas que permita acelerar el ciclo de los releases y también al hecho de saber
y comprender qué es lo que se espera que el sistema haga.

• No necesita escribir tests manuales, puesto que los mismos features files tienen los test
cases descritos.

• QA manuales se escribir los test cases ya que BDD usa lenguaje natural, y no
necesariamente deben saber de código.

• Ayuda en la documentación del sistema, puesto que ahí están descritos los escenarios y
podría contener casi todas las descripciones de los requerimientos funcionales como
también te dan la oportunidad de saber cómo se trabaja en la vida real.

• Las pruebas de aceptación ayuda con los requerimientos ejecutables y también realiza
pruebas de regresión para que los releases sea más confiable.

• BDD permite una mejor comunicación entre todas las partes interesadas de un proyecto
 17
• BDD ayuda a centrarnos en lo que es verdaderamente importante para el 'negocio'.

• Evita entregar algo no deseado y aumenta la confianza del desarrollador a la hora de

introducir cambios en la aplicación.

3.6 Límites BDD

Esta metodología tiene sus limitaciones o mejor dicho restricciones que son necesarias para una
buena puesta en práctica.

• BDD requiere un alto compromiso y colaboración por parte del negocio.

Uno de los puntos más importantes en BDD es la comunicación entre el equipo de desarrollo y el
negocio, que está dado gracias a la utilización de un lenguaje ubicuo de comunicación.

Pero más allá de ello, se requiere que el negocio (los expertos del dominio, los interesados y
stakeholders) se comprometan a formar parte de manera activa y colaborativa, sí esto último no
es posible, ya sea porque esperan a último momento para hacer un feedback

También porque no se encuentran disponibles para realizar workshops o reuniones de

especificación, entonces será difícil obtener de BDD los beneficios esperados.

Cabe destacar también que el compromiso y colaboración tiene estar dentro de los miembros del
equipo, ya que en caso de no ser así también dificulta la puesta en práctica de BDD.

• BDD funciona mejor en un contexto Agile.

Si bien BDD se puede poner en práctica no sólo en proyectos ágiles, el marco que brindan
Scrum5, Kanban 6u otra metodología iterativa de trabajo para la gestión de proyectos.

Es un marco lo suficientemente sólido para dar soporte al desarrollo e implementación de BDD.

5
Scrum es un proceso de la Metodología Ágil que se usa para minimizar los riesgos durante la
realización de un proyecto, pero de manera colaborativa.
6
Kanban es una metodología ágil, cuyo objetivo es gestionar de manera general cómo se van
completando las tareas.

Se destaca por ser una técnica de gestión de las tareas muy visual, que permite ver a golpe de
vista el estado de los proyectos, así como también pautar el desarrollo del trabajo de manera
efectiva.
 18

• El costo de mantenimiento de las pruebas puede ser muy alto.

La creación de pruebas automatizadas de aceptación requiere de ciertas habilidades deseables

por parte del equipo de desarrollo.

Sí las pruebas no son correctamente y cuidadosamente diseñadas haciendo buen uso de las
capas

de abstracción y la expresividad, a lo largo del tiempo producen que el costo de mantenimiento

crezca de manera exponencial.

Si bien BDD utiliza ejemplos para definir el comportamiento del sistema y obtener una buena
comunicación entre las partes involucradas en la creación del mismo, no debemos perder de vista
que las pruebas automatizadas son una pieza muy importante para alcanzar el objetivo de
negocio.

3.7 Actividades principales de BDD

BDD posee un conjunto de actividades que pasaremos a explicar más en detalle.

• Identificar y entender los objetivos del negocio.

Los objetivos del negocio son el punto de inicio y principal input para dar comienzo a BDD.

Para ello BDD hace buen uso de prácticas de relevamiento de requerimientos como:

• feature injection7
• impact mapping 8

7
Feature injection es una técnica que intenta identificar el valor que el proyecto, intenta entregar
y las features capaces de entregar dicho valor.

El objetivo es complementar el conjunto de features que proveerán el mayor beneficio en pos de

alcanzar los objetivos del negocio.
8
Impact Mapping es una práctica que permite visualizar las relaciones entre los objetivos del
negocio detrás del proyecto, los actores que se verán afectados y las features que permitirán al
proyecto entregar los resultados esperados.
 19

• Purpose-Based Alignment9.

Lo que interesa en esta primera etapa es conocer y definir de manera clara:

La visión (que es lo queremos lograr) Los objetivos (como queremos lograr beneficiar al
negocio) Los stakeholder (a quienes beneficia) Las capacidades (que es lo que necesitamos
construir).

• Definir e ilustrar los features.

Una feature es un trozo de funcionalidad de software que ayuda a los usuarios u otros stakeholder
a alcanzar un objetivo de negocio, para satisfacer una capacidad que el sistema debe cumplir.

Una feature no es necesariamente una historia de usuario, sino que muchas veces la descripción
de la feature está dada por un conjunto de historias de usuario.

Para ilustrar las features nos hacemos uso de los ejemplos, que pasarán a ser descriptos como
escenarios utilizando Gherkin.

Figura 4 Historia de usuario en BDD que sirve para expresar los distintos escenarios que pueden
presentarse.

Figura 4 Historia de usuario en BDD

Fuente: ( https://www.bit.es/knowledge-center/bdd)

9
Purpose-Based Alignment Model es otra técnica gráfica que permite definir cuánto esfuerzo hay
que invertir para cada feature.

Los modelos hacen más sencillas las discusiones sobre los presupuestos que sustentan el valor
propuesto para cada feature, y previenen que feature de bajo valor pasen inadvertidas
 20

• Crear especificaciones ejecutables.

Una vez ya armados los escenarios, definimos los steps definition10 que pasarán a ser
especificaciones ejecutables.

Los step definitions son los intermediarios entre los escenarios que se encuentran definidos en
alto nivel y las especificaciones de bajo nivel, son el nexo que conectan los mismos, estas
especificaciones ejecutables son automatizadas, ya que de esta manera nos permiten tener un
feedback rápido y constante.

• Crear especificaciones de bajo nivel.

Las especificaciones ejecutables si bien se encuentran automatizadas y escritas en algún

lenguaje de programación utilizando alguna herramienta de BDD, requieren de un paso más para
poder conectarse con la aplicación, las especificaciones de bajo nivel (en donde mencionamos
que se aplica TDD) y más técnico de todos para llegar al sistema.

En este punto se define el “Cómo” en lugar de él “Qué” que definen las especificaciones
ejecutables de alto nivel.

Figura 5 Capas de Abstracción, el Qué y el Cómo Capas de Abstracción, el Qué y el Cómo,

podemos observar la imagen como se relaciona con las distintas capas de abstracción.

Figura 5 Capas de Abstracción, el Qué y el Cómo

Fuente: Libro (John Ferguson Smart BDD in Action)

10
Step Definition son trozos de código que interpretan el texto de la definición del escenario y que
saben que especificación de bajo nivel llamar.
 21
Figura 6 Actividades en BDD y sus relaciones Actividades en BDD y sus relaciones como se
observar la imagen cada actividades están relacionada, las principales actividades y resultados
de BDD, se toma en cuenta que actividades se producen repetida y continuamente a lo largo del
proceso.

Este no es un proceso simple al estilo de cascada, sino una secuencia de actividades que practica
para cada característica que implementa.

Figura 6 Actividades en BDD y sus relaciones

Fuente: Libro (John Ferguson Smart BDD in Action)

3.8 Herramientas
A continuación, se mostrarán las herramientas BDD disponibles en el mercado:

Serenity BDD.11

Serenity BDD es una librería de código abierto que ayuda a escribir las mejores pruebas de
aceptación automatizadas de alto nivel y en menor tiempo.

Permite la creación de pruebas de forma tal que sea fácil y flexible su mantenimiento y además,
provee reportes ilustrados, permite mapear las pruebas con los requerimientos o capacidades,
entre otras funcionalidades.

Para preparar un proyecto en Serenity incluimos la dependencia de Serenity-cucumber, a

continuación mostraremos la Figura 7 Agregando dependencia en el pom.xml

11
http://www.thucydides.info/#/
 22

Figura 5 Agregando dependencia

Fuente: (https://www.adictosaltrabajo.com/tutoriales/serenity-y-cucumber/)
También se puede crear un feature en los resources de la parte de test del proyecto maven y
describimos un escenario a continuación.

Figura 6 My first feature

Fuente: (https://www.adictosaltrabajo.com/tutoriales/serenity-y-cucumber/)

La estructura de archivos para definiciones de pasos, pasos y clases de prueba en ejecución se

ve así en Serenity:
 23

Figura 7 Estructura de Archivos Serenity

Fuente: (https://www.romexsoft.com/serenity-test-automation-tutorial/)

En cuanto a los informes y resultados de las pruebas serenity proporciona informes detallados
sobre los resultados y la ejecución de las pruebas que incluye:

• Una narrativa para cada prueba

• Captura de pantalla para cada paso en la prueba

• Resultado de la prueba , incluidos los tiempos de ejecución y los mensajes de errores si

falla una prueba

Figura 8 Reporte de Serenity, se genera un fichero index.hmtl que contiene el reporte detallado.
 24

Figura 8 Reporte de Serenity

Fuente: (https://www.romexsoft.com/serenity-test-automation-tutorial/)

Cucumber. 12

Es una herramienta de código abierto para especificaciones ejecutables, que fue diseñada
específicamente para asegurar que las pruebas de aceptación sean fáciles de leer por cualquier
miembro del equipo.

Actualmente brinda soporte para múltiples lenguajes de programación como son: Ruby, Java,
.net, php, etc.

12
https://cucumber.io/
 25
Los componentes básicos son:

• Feature es un pedazo del sistema que entrega valor a uno a más Stakeholders,
representan las especificaciones ejecutables

• Feature File es el archivo que describe una feature o parte de ella con ejemplos
representativos de la salida esperada, cucumber usa este archivo para validar la
funcionalidad del sistema contra las especificaciones, estos son archivos plano
almacenados en el mismo sistema de control de versiones del proyecto relacionado

Figura 9 Feature file

Fuente: (Elaboración propia)

• Escenario es una captura de un ejemplo de una feature y se incluye en el feature file

como también es una forma en la que el sistema representa algún valor al stakeholder y
una unidad de especificación para cucumber

• Steps son frases del lenguaje que puede combinar para escribir escenarios a continuación un
ejemplo de una aplicación:

Figura 10 Steps

Fuente: (Elaboración propia)

 26
• Step Definition son componentes reutilizables de la automatización, en donde se
ejecutan los pasos que componen un escenario, indicando a cucumber qué hacer cuando
se implementan los escenarios y verifica que los mismo funcionan según la forma
esperada y una vez implementados estas definiciones pueden ser reutilizables por otros
escenarios

Figura 11 Step Definition

Fuente: (Elaboración propia)

• Cucumber tiene un plugin para reportes que verificar las ejecuciones de los test que se
ejecutaron exitosamente y los que fallaron.
 27

Figura 12 Reportes Cucumber

Fuente: (Elaboración propia)

SpecFlow 13

Es un framework BDD de código abierto para .Net, así como también Cucumber utiliza el lenguaje
Gherkin y provee integración para Silverlight, Window Phone.

Un feature file es un punto de entrada a la prueba donde un archivo describe sus pruebas en
lenguaje descriptivo (como inglés).

Es una parte esencial de SpecFlow, ya que sirve como una secuencia de comandos de prueba
de automatización, así como documentos en vivo.

Un archivo de características puede contener un escenario o puede contener muchos escenarios

en un solo archivo, pero generalmente contiene una lista de escenarios, a continuación
mostraremos como se crear un archivos con visual studio.

13
https://specflow.org/
 28

Figura 13 Creando un Archivo SpecFLow con Visual Studio

Fuente: (http://toolsqa.com/specflow/feature-file/)

Para crear un feature Specflow primeramente se crea una carpeta para los archivos de feature
mostraremos en la imagen a continuación

Figura 14 Creando una carpeta de features con Visual Studio

Fuente: (http://toolsqa.com/specflow/feature-file/)
 29
En Visual Studio para agregar un feature file se agrega de la siguiente manera, en la carpeta
agregamos un nuevo elemento, a continuación mostraremos en una figura

Figura 15 Creando feature file con SpecFlow

Fuente: (http://toolsqa.com/specflow/feature-file/)

Los feature file es utilizados por SpecFlow para especificar los criterios de aceptación para las
características (casos de uso, historias de usuarios) en su aplicación se definen usando la sintaxis
de Gherkin.

Figura 16 Feature file de un login pasos para ingresar sesión en un sitio web de una aplicación

Figura 16 Feature file de un login

Fuente: (http://toolsqa.com/specflow/feature-file/)

SpecFlow genera una llamada dentro del método de prueba de unidad para cada paso de
escenario.
 30
La llamada es realizada por el tiempo de ejecución de SpecFlow que ejecutará la definición del
paso que coincida con el paso del escenario.

La coincidencia se realiza en tiempo de ejecución, por lo que las pruebas generadas se pueden
compilar y ejecutar incluso si el enlace aún no se ha implementado, los pasos del escenario son
la forma principal de ejecutar cualquier código personalizado para automatizar la aplicación.

JBehave14
Es un framework BDD para el lenguaje Java (creado por Dan North), también se integra con
Maven y Ant

JBehave también consiste en un sistema para hacer BDD en Java, en otras palabras: permite
definir en un lenguaje no formal el comportamiento de la aplicación, utilizando expresiones
regulares para transformarlo en un lenguaje formal.

Al igual que muchas herramientas basadas en Java, JBehave usa anotaciones para vincular el
texto en los archivos de características a los métodos de Java que los implementan.

Cuando comenzamos a definir las historias a través de escenarios que expresan el

comportamiento deseado en un formato textual, por ejemplo:

Figura 17 Write story para iniciar una sesión fallado de una aplicación

Figura 17 Write story

Fuente: (https://jbehave.org/reference/stable/developing-stories.html#writing)

En JBehave se asigna los pasos de texto a los métodos de Java a través de CandidateSpetps.

El escritor de escenarios sólo necesita proporcionar métodos anotados que coincidan, mediante
patrones de expresiones regulares, con los pasos textuales, a continuación un ejemplo.

14
https://jbehave.org/
 31

Figura 18 Map Steps to Java

Fuente: (https://jbehave.org/reference/stable/developing-stories.html#writing)

Un informe es un elemento esencial de BDD, ya que permite controlar el resultado de las historias
que se han ejecutado, el corazón de los informes de JBehave es Story Reporter en la cual se
informa de los eventos a medida que ocurren.

Figura 19 Reporte Story

Fuente: (https://martinzimmermann/2013/02/24/behavior-driven-development-mit-jbehave/)

Selenium

Es un conjunto de herramientas de software open source que sirven para facilitarnos la tarea de
automatizar pruebas desde un navegador, selenium es el framework con el que podrás programar
pruebas en diferentes lenguajes.

Inicialmente se desarrolló para Java pero se amplió para poder usarlo en Php, C#, Python, Perl
o Ruby.

Su primera versión se llamó SELENIUM REMOTE CONTROL y consistia en un “servidor” o

“remote control” que se encargaba de abrir, navegar, realizar acciones y cerrar nuestro navegador
automáticamente.
 32
La segunda y actual versión se llama SELENIUM WEBDRIVER, se caracteriza por tener un
lenguaje de programación orientado al objeto, por no necesitar de un servidor “remote control”
arrancado para poder realizar las pruebas, ya que nuestro código fuente al ejecutarse será capaz
de levantar nuestro browser y realizar las pruebas.

También se mejora la capacidad de poder lanzar varias pruebas simultáneamente en diferentes

pc’s, ya que en su primera versión solo se podía realizar mediante SELENIUM GRID.

Figura 20 Este archivo definirá el escenario a probar, en este ejemplo escribiremos escenario
para ingresar inscribirse curso de QA

Figura 20 feature file

Fuente : (Elaboración propia )

Figura 21 Step definition en este archivo implementamos los pasos indicados en el archivo de
características, en este archivo tendrá la función de poder ingresar a la páginade curso online de
QA
 33

Figura 21 Steps definition

Fuente : (Elaboración propia)

Selenium Webdriver genera un reporte que se encuentra en un archivo html llamado

"STMExtentReport.html" en su carpeta de prueba-salida

Copie la ubicación del archivo STMExtentReport.html y ábralo con cualquier navegador, podrás
ver hermosos informes html como se muestra en la figura 22

Figura 22 Reporte Selenium Webdriver

Fuente : ( https://www.techbeamers.com/generate-reports-selenium-webdriver/)
 34
4 CÓMO IMPLEMENTAR UN PROCESO BDD

4.1 Definir los Escenarios a Desarrollar

Es la parte fundamental del proceso de BDD ya que en este caso saldrán los escenarios que
guiarán todo el desarrollo del producto y serán los que generen el lenguaje común que se usará
en el proyecto.

Los Acceptance Criteria (AC) deben de definirse antes de cada sprint y deben definir de forma
clara e inequívoca cuáles serán las historias de usuario que servirán para dar por válido un sprint,
por tanto, debe implicar a todos los stakeholders del proyecto.

La definición debe realizarse utilizando el lenguaje Gherkin y al final de la sesión debe de existir
uno o varios archivos "features" que incluyan las features y los escenarios que deberán ejecutarse
en ese sprint.

Estos archivos no deberán modificarse a lo largo del desarrollo salvo para una refactorización o
una simple aclaración o corrección de los parámetros.

Figura 23 varios features files

Fuente :(Elaboración propia)

4.2 Crear Test Automáticos que validen la funcionalidad

Una vez que ya se han definido las features el siguiente paso es definir una serie de tests
automáticos que validen estos escenarios.
 35

Figura 24 Test Automáticos

Fuente: (Elaboración propia )

4.3 Crear un Entorno de Trabajo

Casi tan importante como crear test automáticos que validen el producto es, tener un entorno que
permita que estos test se ejecuten de manera correcta, eficiente y eficaz.

Para crear un entorno de trabajo eficiente hay que pensar en dónde se ejecutarán los tests (en
una máquina local, en una máquina de integración continua) y con qué frecuencia se ejecutarán
(se ejecutará en cada commit, de manera nocturna, cada cierto tiempo).

La idea primero es que estos tests serán indicadores para saber si el sprint está terminado y es
válido, por lo que los desarrolladores ejecutarán estos test cuando lo quieran y que los resultados
que proporcionen debe ser real y dónde lo estés ejecutando.

Para ayudar con esto existen herramientas como Vagrant o Docker que permiten definir máquinas
virtuales de manera sencilla y ligera que permiten al desarrollador tener un entorno "de
producción" en su propio ordenador.

4.4 Evolución y Adaptación

Siguiendo los principios que Beck define en el Agile Manifestó (Beck, Manifestó for Agile Software
Development, 2001) hay que poner a las personas antes que a las herramientas.

Es importante analizar cómo se adapta el equipo a este proceso e ir adaptándolo según vaya
evolucionando el proyecto para cubrir las necesidades y las peculiaridades de cada equipo.
 36
Es importante que las retrospectivas de cada sprint sirvan para detectar cuáles han sido los
errores y las mejores que se implementaran en el siguiente sprint y además de definir mejor los
escenarios, qué debe cubrir y el trabajo debe mejorarse.
 37
5 CONCLUSIÓN

Respecto a los objetivos específicos que son las BDD, hemos visto cómo se adapta muy bien a
las metodologías ágiles, ayudando a los equipos a mejorar la comunicación entre las diferentes
partes involucradas, definiendo para ello un lenguaje ubicuo llamado Gherkin (puede ser realizado
para un tester sin conocimiento en programación).

La definición de este lenguaje, junto a la creación de test automáticos antes de la codificación,

hace que la codificación sea más sencilla, ya que el equipo sabe con ejemplos qué hay que hacer
y qué se espera de ellos

BDD se puede aplicar en cualquier proceso reduciendo costes operativos y mejorando la

implicación del proyecto.

BDD nos permite construir escenarios completos, complejos y probarlos como TDD, para
construir una clase o un módulo que implementa dichas funcionalidades.

En resumen, gracias al uso de BDD, los analistas y diseñadores son capaces de especificar más
fácilmente los requisitos y los desarrolladores pueden validar con menor dificultad las
funcionalidades de la aplicación, reforzando los principios ágiles de comunicación y de adaptación
a los cambios.

Lo importante de aplicar los test en un desarrollo de software es que ayudar a encontrar errores,
fallas y defectos de dicho sistema y así garantizar un software de calidad, lo cual nos ayudará las
empresas a tener un mejor éxito y una satisfacción dirigido al cliente.
 38
6 BIBLIOGRAFÍA

Dan, N. (2010). Business-driven Devolpment. Abril.

Keogh, B. L. (2009). Translating TDD to BDD. Mayo.

Nort, D. (2006). Betther Software. Marzo.

North, D. (2006). Introduccing BDD.Better Software. Marzo.

Smart, J. F. (2015). BDD in Action Behavior-Driven Develpment . Manning Publications Co.

Wynne, M. (2012). The Cucumber Book Behaviour-Driven Development. Pragmatic Bookshelf

behaviour driven development (lunes17 de septiembre) obtenido https://behaviourdriven.org/

business development (jueves20deseptiembre) obtenido https://www.ibm.com/developerwork/

Behaviour Driven Development&Jbehave (viernes 21 de septiembre ) obtenido

https://www.romexsoft.com/serenity-test-automation-tutorial/

SpecFlow. SpecFlow. obtenido http://www.specflow.org