¿Qué es BDD?

En esta entrada hablaremos de Behavior-Driven Development o para abreviar BDD, pero antes de continuar definiéndote qué es BDD, es importante que tengas un contexto previo sobre qué es TDD e igual de importante que logres identificarte con las siguientes preguntas:

  • ¿Haz deseado una manera de mantenerte enfocado en alcanzar la meta (creación de impacto de negocio) en la entrega del producto a tu cliente sin desviarte o desenfocarse en dicha meta?
  • ¿Deseas volverte más eficiente en la comunicación con el cliente en las áreas técnicas y de negocio para así reducir malentendidos o ambigüedades?
  • ¿Deseas un puente que te ayude a la transición del desarrollo de software tradicional al de desarrollo ágil (ejemplo: LEAN, como TDD o DDD)?
  • ¿Deseas fomentar la colaboración y el descubrimiento  de las necesidades de negocio a través de mecanismos que ayuden a ello?
  • ¿Deseas tener un mecanismo o reporte que sea cuantitativo sobre el estado del desarrollo de las funcionalidades solicitadas visualizándolas con una descripción a alto nivel?

 

Mencionaré los factores que dieron origen a BDD.

Origen de BDD

BDD fue creado por Dan North inicialmente como un mecanismo de ayuda en la implementación de TDD, sin embargo en el proceso de creación de ese mecanismo surgieron varias dudas, tanto que evolucionó o complementó TDD. (North menciona su proceso y experiencia en los inicios de la concepción de BDD en su blog en la siguiente entrada Introducing BDD).

Básicamente en esta entrada de North se menciona lo que descubrió al cambiar el paradigma de “pruebas” (sobre métodos o clases) a un enfoque de “comportamiento“, enfoque que ayudó a probar comportamientos definidos en los requisitos o necesidades de negocio para un sistema, probando comportamientos esperados y validando el resultado de ellos llegando a concentrarse en lo que es el valor de negocio, ya que de nada nos sirve probar los diferentes componentes de un sistema y no haber probado o culminado el comportamiento esperado.

ci9dn7vwyaagbuv

O como decía un amigo arquitecto de software “el chat envía pero no conecta”.

Surge una duda respecto a las diferencias entre TDD y BDD, en la siguiente imagen se evidencia el cambio de paradigma que menciona North.

tdd_vs_bdd

North observó que estas pruebas orientadas al comportamiento eran en sí criterios de aceptación o condiciones del requisito del sistema que necesita el cliente, que podían servir como documentación “viva” (en otra entrada hablaremos de ello)  y posteriormente surgió la necesidad de establecer un lenguaje de alto nivel  que eliminara la ambigüedad y fuera entendido por los analista de calidad, los analista de negocio y stackeholders, así como el equipo técnico, (en otras palabras “los tres amigos”), surgiendo así una estructura como la siguiente:

Yo como ROL
Dado 
Cuando
Entonces

En esa estructura se necesitaba adicionalmente que no fuera un ladrillo o mamotreto, y que fuera simple y fácil de entender, para lograr esto se debía romper las restricciones de los requisitos del usuario, o los criterios de aceptación en la historia de usuario en fragmentos, que luego se llamarían escenarios, con la particularidad de que estos escenarios fueran ejecutables.

A continuación un ejemplo de escenario referente a BDD.

Historia: Devoluciones van al inventario

A fin de tener seguimiento del inventario 
Siendo un dueño de tienda
Yo quiero añadir artículos de regreso al inventario cuando sean devueltos

Escenario 1: Artículos reembolsados deben ser regresados al inventario 
Dado que un cliente previamente me compró un suéter negro
Y actualmente me quedan tres suéteres negros en el inventario
Cuando él devuelva el suéter a cambio de un reembolso
Entonces yo debo tener cuatro suéteres en el inventario

Escenario 2: Artículos reemplazados deben ser regresados al inventario
Dado que un cliente compra una prenda azul
Y yo tengo dos prendas azules en el inventario
Y tres prendas negras en el inventario 
Cuando él regresa la prenda para un reemplazo por una negra,
Entonces yo debo tener tres prendas azules en el inventario 
Y dos negras en el inventario

Fuente:
https://es.wikipedia.org/wiki/Desarrollo_guiado_por_comportamiento

Visualizado lo anterior,  nos daremos cuenta que los ejemplos y escenarios son una forma de “documentación viva”. La estructura  fomenta la colaboración y el descubrimiento a través de ejemplos.

Llegando al tema de documentación y reporte, es importante darle relevancia a los diferentes niveles de detalle de estos, ya que según el rol del equipo de trabajo implicado en la creación de componentes que den una solución al negocio, le interesará cierta información especifica, omitiendo la información que no le es relevante.

 

Citando el ejemplo que se menciona en el libro BDD in Action: Behavior-driven development for the whole software lifecycle (por John Ferguson Smart):

Los administradores de proyectos o gerentes, están interesados básicamente en las características de la aplicación que se debe desempeñar y realizarse, y los analistas de negocio y QA en el detalle de cómo se implementa cada escenario de aceptación posible hasta el nivel de la pantalla del usuario.

¡Ahora sí!

Conociendo un poco el origen y las necesidades que buscaba resolver North, entraré a definirles BDD.

Definición de BDD

BDD es un conjunto de practicas o procesos de ingeniería de software (no una metodología) diseñados para enfocarse en la meta de crear impacto de negocio. Se basa en Ágil, en practicas LEAN (TDD y DDD) y en OOAD, sin embargo  el logro más importante que genera BDD, es el de proveer un lenguaje de alto nivel que facilita la comunicación.

BDD NO tiene como objetivo, como lo menciona North en el libro “BDD in Action” lo siguiente:

  • La generación de criterios de aceptación o archivos de características de un sistema.
  • Automatización.
  • Testing.

Sin embargo incluye los puntos anteriores.

Para finalizar esta primera parte sobre BDD. Mencionaré lo siguiente:

Si los factores de éxito de una metodología o marco ágil son la comunicación, el trabajo enfocado al “user-centric” y el feedback oportuno referente a las entregas que le doy a mi cliente o stakeholders, entonces BDD me proporciona un medio o mecanismo para desarrollar y apoyar esa relación enriqueciendo esos factores.

 

Espero que te haya gustado mi primer post , en esta primera parte de BDD, mi objetivo era dar a conocer BDD extractando mis apuntes de estudio que hice en algún momento y plasmarlos de una manera amena de leer (espero haber logrado ese objetivo), para finalizar he citado y referido dando los créditos debidos, sin embargo si ves que me ha faltado referir algo mencionado en este post, por favor házmelo saber.

Enlaces relacionados:

Behavior-Driven Development (BDD) Parte 2