Behavior Driven Development en Control de Calidad Automatizado
Behavior Driven Development en Control de Calidad Automatizado
Behavior Driven Development en Control de Calidad Automatizado
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
INTRODUCCIÓN .................................................................................................................................... 7
1 GENERALIDADES ......................................................................................................................... 8
2 METODOLOGÍA ............................................................................................................................. 8
5 CONCLUSIÓN .............................................................................................................................. 37
6 BIBLIOGRAFÍA ............................................................................................................................. 38
4
5
ÍNDICE DE FIGURAS
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).
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
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.
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.
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:
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.
• Ejecutar característica.
• Código de refactoriza.
• Ejecuta función.
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
• 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
• BDD Frameworks
• Gherkin
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.
• 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.
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
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).
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).
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.
BDD es una práctica colaborativa tanto para los miembros del equipo y el cliente, como para los
miembros del equipo internamente
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
Figura 3 Gherkin Gherkin Básico se trata de lista de pasos que llevan a un resultado
Fuente: ( https://www.bit.es/knowledge-center/bdd)
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.
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.
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.
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'.
Esta metodología tiene sus limitaciones o mejor dicho restricciones que son necesarias para una
buena puesta en práctica.
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
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.
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.
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
Sí las pruebas no son correctamente y cuidadosamente diseñadas haciendo buen uso de las
capas
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.
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.
• Purpose-Based Alignment9.
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).
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.
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
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.
En este punto se define el “Cómo” en lugar de él “Qué” que definen las especificaciones
ejecutables de alto nivel.
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.
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.
11
http://www.thucydides.info/#/
22
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.
Fuente: (https://www.adictosaltrabajo.com/tutoriales/serenity-y-cucumber/)
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:
Figura 8 Reporte de Serenity, se genera un fichero index.hmtl que contiene el reporte detallado.
24
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
• Steps son frases del lenguaje que puede combinar para escribir escenarios a continuación un
ejemplo de una aplicación:
Figura 10 Steps
• Cucumber tiene un plugin para reportes que verificar las ejecuciones de los test que se
ejecutaron exitosamente y los que fallaron.
27
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.
13
https://specflow.org/
28
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
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
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
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.
Figura 17 Write story para iniciar una sesión fallado de una aplicación
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
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.
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.
Figura 20 Este archivo definirá el escenario a probar, en este ejemplo escribiremos escenario
para ingresar inscribirse curso de QA
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
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
Fuente : ( https://www.techbeamers.com/generate-reports-selenium-webdriver/)
34
4 CÓMO IMPLEMENTAR UN PROCESO BDD
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.
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.
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).
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