¿Qué es el Desarrollo Guiado por Comportamiento (BDD)?

Coste de arreglar un bug

Cuando desarrollas con una metodología orientada a pruebas (TDD) después de cerrar una especificación,  hay un punto en el que surge un problema: ¿como traducimos los requerimientos del cliente o futuro usuario a pruebas unitarias, de integración o de interficie? Las personas no técnicas usan un lenguaje no técnico, pero se ha de traducir al lenguaje que sea necesario (Java si utilizamos Selenium, etc…) y en la traducción se puede perder información.

Behaviour Driven Development (BDD) es una metodología de de desarrollo de software que nace del Test Driven Development (TDD).

BDD no especifica sets de pruebas a superar, sino que utiliza ejemplos concretos para ilustrar el comportamiento del sistema, y han de estar escritos en un lenguaje normal y comprensible para todos los involucrados en el desarrollo. Además estos ejemplos luego:

  • Serán traducidos en especificaciones que se pueden ejecutar.
  • Se utilizan como pruebas de aceptación.

Características principales

El desarrollo guiado por el comportamiento se centra en:

  1. Permitir que todas las partes implicadas: desarrolladores, analistas y stakeholders, hablen el mismo lenguaje con el objetivo de entregar productos con alto valor. Éste lenguaje debe estar basado en prototipos y descripciones adaptadas al lenguaje del negocio.
  2. Lo que debe hacer un sistema y no cómo debe ser implementado.
  3. Proporcionar una mejor legibilidad y visibilidad en todo el proceso.
  4. No validar sólo el funcionamiento del software, sino también que cumple con las expectativas del cliente.

Origen de BDD

El coste de fijar un bug aumenta exponencialmente cuanto más tarde se detecta y soluciona un defecto  Recordemos lo que dice 6Sigma sobre el coste de arreglar un bug según el momento que se ha detectado.

Coste de arreglar un bug

A menos que se obtengan los requisitos completamente correctos desde el momento inicial (lo cual, sinceramente, nunca he visto ocurrir), cada posible malentendido lleva a un coste mucho mas grande cuanto más tarde se detecte. Y aunque este libre de “errores”, es posible que el producto final puede no cumpla las expectativas del cliente.

Esto ha llevado a buscar una metodología de desarrollo que:

  • Se base en los requisitos.
  • Se mantenga centrada en los requisitos durante todo el desarrollo.
  • Asegura que estos requisitos son satisfechos.

De esta manera emerge el BDD:

  • Deriva ejemplos de diferentes comportamientos esperados del sistema.
  • Permite escribir los ejemplos en un idioma utilizando lenguaje de negocio para garantizar una fácil comprensión por todos los involucrados en el desarrollo, incluidos los clientes.
  • El cliente ratifica los ejemplos directamente en lugar de hacerlo mediante conversaciones con el técnico o analista.
  • Se centra en los requisitos del cliente (ejemplos) a lo largo del desarrollo.
  • Los ejemplos son utilizados como pruebas de aceptación.

Cómo se implementa BDD

Especificación mediante Ejemplo

Especificación mediante ejemplo (SbE) utiliza ejemplos en conversaciones para ilustrar las reglas de negocio y el comportamiento del software que se construirá.

Especificación mediante ejemplo permite a los propietarios de productos, analistas de negocios, testers y  desarrolladores  eliminar malentendidos comunes sobre los requisitos del negocio.

Desarrollo Impulsado por Pruebas

Test Driven Development, en el contexto de BDD, convierte ejemplos en especificaciones ejecutables y legibles por humanos.

En lugar de diseñar las pruebas a superar por el código en el momento de iniciar la implementación, el desarrollador utilizan estas especificaciones como una guía para ir incrementando la funcionalidad del sistema. Como en el momento que cambian la especificacion (los ejemplos) tambien cambian las pruebas, no hay que mantenerlas y actualizar por separado con lo que los costes de mantenimiento y cambio permaneceran más bajos.

Agile BDD

En el desarrollo ágil, el método BDD se utiliza para que todo el mundo entienda de la misma manera las especificaciones pendientes.

Así, en Agile BDD los pasos de ejecución son los siguientes:

  • Los desarrolladores y el product owner escriben juntos las especificaciones pendientes texto plano.
  • El product owner especifica com detalle los comportamientos que esperan del sistema.
  • Los desarrolladores
    • Rellenan las especificaciones con estos detalles .
    • Hace las preguntas necesarias para la comprensión del sistema.
  • Los comportamientos actuales del sistema se consideran para ver si la nueva característica romperá cualquiera de las características existentes.

Manifiesto Ágil y BDD

El Manifiesto Ágil afirma lo siguiente:

“Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

  • A los individuos y su interacción, por encima de los procesos y las herramientas.
  • El software que funciona, por encima de la documentación exhaustiva.
  • La colaboración con el cliente, por encima de la negociación contractual.
  • La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.”

BDD se alinea al manifiesto ágil de la siguiente manera:

Manifiesto ágil Alineación Ágil BDD
Individuos e interacciones sobre procesos y herramientas BDD trata sobre tener conversaciones.
Software de trabajo sobre documentación exhaustiva BDD se centra en facilitar la creación de software de valor y no especificaciones
Colaboración del cliente sobre la negociación contractual BDD se centra en escenarios basados ​​en ideas con una comunicación continua con el cliente a medida que avanza el desarrollo. No se basa en ninguna promesa.
Responder al cambio sobre seguir plan BDD se centra en la comunicación continua y la colaboración que facilita la adopción de los cambios.

Como afrontar el desarrollo a partir de aquí

Así como el BDD nos muestra el marco de interacción con el cliente y participantes del producto, el desarrollo debe seguir realizando con el paradigma del desarrollo orientado a pruebas (TDD), solo que el diseño de las pruebas nos vienen directamente de los casos prácticos acordados con el cliente. Eso no nos ahorrará el trabajo de desarrollar todas las baterías de pruebas unitarias o de integración necesarias, simplemente nos asegura que cuando todas las pruebas son válidas el producto final va a tener la calidad requerida.

Un comentario sobre “¿Qué es el Desarrollo Guiado por Comportamiento (BDD)?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.