Desarrollo Dirigido por el Comportamiento o BDD (Behavior Driven Development)

Ha trabajado duro. Ha tecleado hasta que todo ha quedado bien. Se recuesta en su silla, sonriendo. Sí, está contento con el resultado.

Un par de días después, sus hombros están caídos. El cliente no estaba contento. No es lo que quería.

Qué mala suerte.

Pero anímese, hay una respuesta: El Desarrollo Dirigido por el Comportamiento o BDD para abreviar.

Siga leyendo para saber qué es, cómo beneficia a los desarrolladores, a los probadores y al negocio por igual, y qué implica hacerlo. Empecemos por lo que es.

¿Qué es el desarrollo dirigido por el comportamiento en Ágil?

La definición más sucinta de Desarrollo Dirigido por el Comportamiento que he encontrado es ésta:

BBD es un proceso diseñado para ayudar a la gestión y la entrega de proyectos de desarrollo de software mejorando la comunicación entre los ingenieros y los profesionales de la empresa. De este modo, el BDD garantiza que todos los proyectos de desarrollo se centren en la entrega de lo que realmente necesita la empresa y en el cumplimiento de todos los requisitos del usuario.

El Desarrollo Dirigido por el Comportamiento no es sobre las pruebas

Sí, practicar BDD significa que va a especificar y ejecutar pruebas. Pero las pruebas no son el objetivo.

Porque al igual que su compañero TDD (Test Driven Development) o Desarrollo Dirigido por Pruebas, BDD no es sobre las pruebas. Se trata de alcanzar los objetivos de negocio y los resultados de los clientes a nivel de la aplicación. Tal y como la definición establece claramente.

¿Cuál es la relación entre BDD y Ágil?

Bueno, con BDD se asegura el funcionamiento del software por encima de la documentación exhaustiva a nivel de aplicación y se sigue obteniendo esa documentación.

Además, Ágil tiene fuertes raíces en eXtreme Programming. Y Dan North -que originó BDD- es un entusiasta de eXtreme Programming desde hace mucho tiempo.

Los Three Amigos como idea central del Desarrollo Dirigido por el Comportamiento

La idea central del diseño orientado al comportamiento es que ninguna persona o campo tiene la respuesta completa a nada.

Se necesitan Three Amigos: profesionales de la empresa, desarrolladores y probadores, para obtener buenas respuestas.

Y lo que es más, se necesita que colaboren. Porque es el ida y vuelta entre personas con diferentes estilos cognitivos y diferentes perspectivas y antecedentes, lo que produce la magia. Magia que le aporta soluciones mejores, más sencillas y más valiosas.

Lo que cada uno de los Three Amigos aporta a la mesa:

• Los profesionales de los negocios aportan las necesidades de la empresa y los requisitos de los clientes. Están en la mejor posición para decidir cuán deseable es una historia en comparación con otras.
• Los desarrolladores son los expertos en software y oportunidades tecnológicas. Están en la mejor posición para calibrar lo fácil o difícil que será implementar una historia.
• Los probadores son indispensables por su capacidad de detectar, casi instintivamente, los obstáculos y las lagunas. Identificarán los casos límite antes de que causen problemas más adelante.

¿Cuáles son los beneficios del BDD? 

Al adoptar el desarrollo dirigido al comportamiento, puede esperar estos beneficios:

• Poner en primer plano los objetivos empresariales y los requisitos de los clientes.
• Pautas para estructurar la conversación entre los Three Amigos. Esto hace que éstas sean más eficaces y productivas.
• Definir los criterios de aceptación antes de comenzar el desarrollo.
• Evitar el esfuerzo en características que no contribuyen a los objetivos de negocio.
• Evitar interpretaciones erróneas que lleven a rehacer el trabajo más adelante.
• Lenguaje omnipresente. Un lenguaje específico del dominio que se utiliza en todas partes en el software.
• Especificaciones que las personas no técnicas pueden entender fácilmente.
• Especificaciones ejecutables.
  • Pruebas de aceptación automatizadas que proporcionan una retroalimentación rápida para mantener la implementación en el camino.
  • Especificaciones vivas que nunca se desactualizan.
  • Documentación técnica y de usuario final generada automáticamente, que tampoco se desactualiza.

Las Fases del Desarrollo Dirigido por el Comportamiento

En BDD se pasa por tres fases para cada historia que se quiera implementar.

Estas fases son:

• Descubrimiento. Aquí se explora una historia en una conversación estructurada. Tiene dos objetivos. Uno es asegurar que la historia contribuirá a los resultados del negocio. Por ejemplo, con el método de los cinco porqués. El otro objetivo es asegurar la comprensión compartida de lo que se necesita, esbozando ejemplos concretos de escenarios específicos.
• Formulación. Aquí es donde se reformulan (formulan) los ejemplos en un lenguaje estructurado y se convierten en especificaciones ejecutables.

These follow the given-when-then pattern:

el escenario (dado)— el estado inicial, por ejemplo «el usuario está conectado»,

el evento (cuando)— lo que ocurre, por ejemplo «el usuario pulsa el botón de cierre de sesión», y

el resultado (entonces)— la respuesta esperada, por ejemplo «se muestra la página de inicio de sesión».

• Automatización. Aquí es donde se convierten las especificaciones ejecutables en pruebas de aceptación automatizadas. Utilizando herramientas como Cucumber, se trata de conectar la herramienta con el software.

Software de trabajo: Las pruebas de aceptación guían su trabajo de implementación del software.

Un ejemplo de BDD 

Repasemos las fases de Descubrimiento y Formulación para dar un ejemplo.

Título: Bloquear a otros usuarios.

Narración: Como miembro, quiero bloquear a los usuarios para que no me molesten más.

Descubrimiento 

La historia parece bastante sencilla, pero los interrogantes surgen en cuanto se empieza a pensar en ella:

• Qué resultado comercial se sirve?
• ¿Qué significa bloquear? Qué implica eso? Qué se necesita para que eso ocurra?
• ¿Qué significa «no me molestes más»? Qué aspecto tiene eso? Qué tiene que pasar o no pasar?

La lista es interminable.

Después de hablar con el cliente, resulta que simplemente no quiere ver las actualizaciones de un usuario bloqueado en su feed de actividad.

como miembro, quiero silenciar a los usuarios, para que mi feed de actividad no muestre sus actualizaciones. Una cuestión mucho más sencilla de abordar y de mucho menor alcance.

Aun así, incluso ahora, no está del todo claro qué hay que hacer y qué no. Es hora de aclararlo con ejemplos desde la perspectiva del usuario.

• Cuando silencio a otro usuario, y ese usuario envía una actualización, no quiero verla en mi feed.
• Cuando silencio a otro usuario, y vuelvo a desplazarme por mi feed, no quiero ver ninguna actualización de ese usuario.

Formulación

Ahora se escribe cada ejemplo en la notación estructurada que puede ser leída y ejecutada por el software.

• Dado que he silenciado a |algún usuario|, cuando visito mi feed de actividad, el feed no debería contener actualizaciones de |algún usuario|.
• Dado que he silenciado a algún usuario, cuando éste envíe una actualización, no debería añadirse a mis notificaciones.

Cómo no sacar el máximo partido al BDD

Los errores más comunes en el desarrollo dirigido al comportamiento son:

• Dejar de lado a los probadores en las fases de Descubrimiento y Formulación.
• Asumir que escribir los ejemplos es lo que cuenta.
• Renunciar a la fase de Descubrimiento porque se cree que ya se sabe lo que hay que hacer.

Qué es la Prueba Dirigida por el Comportamiento (Behavior Driven Testing)

Las Pruebas Dirigidas por el Comportamiento (BDT) son un proceso menos conocido que conduce a las pruebas de aceptación automatizadas. Al igual que promueve la colaboración entre personas técnicas y no técnicas. Y también utiliza un lenguaje natural formalizado para escribir pruebas que pueden ser fácilmente revisadas y verificadas por profesionales de la empresa.

Pero la BDT se centra más en lo que los usuarios hacen con el software. En lugar de los criterios de aceptación que verifican la implementación de la lógica empresarial.

¿Cuál es la diferencia entre TDD y BDD?

El desarrollo dirigido por el comportamiento y el desarrollo dirigido por las pruebas son similares y diferentes al mismo tiempo.

• Ambas emplean enfoques que dan prioridad a las pruebas, pero no se trata de pruebas.
  • BDD consiste en mejorar la colaboración y la comunicación entre desarrolladores, probadores y profesionales de la empresa. Para que el software cumpla tanto los objetivos de negocio como los requisitos del cliente.
  • TDD trata del diseño y las especificaciones a nivel de código.
• BDD trabaja a nivel de aplicación y requisitos. TDD se centra en el nivel del código que implementa esos requisitos.
• TDD es, o puede ser utilizado como la fase «Hacer que las pruebas pasen» de BDD.
• En TDD se puede, pero no es necesario, utilizar técnicas de BDD hasta el nivel más pequeño de abstracción
• BDD no tiene una fase de refactorización como TDD.

Empiece a Crear Software Útil que los Clientes Quieran

La imagen de arriba ilustra lo difícil que es para un cliente describir lo que quiere, y cómo se estropea a medida que avanza por la línea. Es un cliché por una razón, y uno con una larga historia.

Pero utilizando el Desarrollo Dirigido por el Comportamiento, puede hacer que eso sea una cosa del pasado.

Sí, puede ser difícil detenerse y pensar, «perder» el tiempo teniendo las conversaciones que le ayudarán a hacerlo.

Pero, vale la pena. Usted creará un software útil que los clientes realmente quieren, y lo hará sin tener que rehacer, reparar o rehacer lo que ha hecho antes.