Behavior Driven Development: La metodología que conecta a los tres amigos

Compartir esta publicación

Compartir en facebook
Compartir en linkedin
Compartir en twitter
Compartir en email

El objetivo principal de una empresa de software es entregar un producto de calidad. No podemos percibir la calidad sin producto de la misma manera que no se puede entregar un producto sin calidad. Bajo esta premisa, entendemos que la calidad no se fabrica, sino que forma parte del proceso de desarrollo. Con el paso de los años, se han ido estableciendo diferentes roles para poder acotar las responsabilidades. Reduciendo a lo básico, dentro de un equipo de software ágil actual podemos encontrar tres roles principales:

  • Business – Product owner: Capta los requisitos solicitados por el cliente (stakeholders).
  • Developer: Implementa los requisitos captados por negocio para crear el producto.
  • QA: Valida que el producto final concuerda con las especificaciones iniciales.

Una vez establecida esta división, conocida coloquialmente como The three amigos, es necesario acordar un canal de comunicación común. Hay que tener en cuenta, que algunos roles de negocio no tienen por qué ser técnicos mientras que los desarrolladores y QAs dedicados a la automatización de pruebas si lo son. De alguna manera, se tiene que encontrar una metodología que conecte estos dos perfiles, la solución es el BDD.

¿Qué es el BDD?

El Behaviour Driven Development es una metodología de software que nos permite definir y desarrollar el producto en base al comportamiento del sistema. Nace por la necesidad mencionada anteriormente de poder comunicar la parte de negocio con el desarrollo. Este proceso ágil es derivado del conocido Test Driven Development (TDD) cuya diferencia está en el alcance: El TDD se centra más en la del funcionamiento del código mientras que el BDD se enfoca en el comportamiento, desde el punto de vista de usuario. Cabe destacar que ambas metodologías son complementarias, podemos tener un código desarrollado en base al TDD con pruebas unitarias, cuya funcionalidad y automatización de pruebas han tenido en cuenta los escenarios definidos en BDD.

Una iteración completa de un improvement en un ciclo de Agile consiste en:

  1. El PO se reúne con el stakeholder para obtener el requisito funcional.
  2. El PO escribe el requisito en formato de User Stories “As a [user], I want [functionality], so that [Benefit]”
  3. Un representante de cada perfil (PO, DEV y QA) se reúnen refinar, estimar e identificar los escenarios para cubrir la User Story.
  4. Se crean tareas con la definición + escenarios acordados.
  5. Paralelo al punto 6: Los desarrolladores programan la funcionalidad descrita.
  6. Paralelo al punto 5: Los QA automation automatizan los testing scenarios descritos.
  7. Cuando se finalizan el punto 5 y 6 mediante un proceso de CI/CD se deploya el código en un entorno donde se lanzan las pruebas automáticas que validaran el desarrollo.

Behavior Driven Development

Fuente: flatstack.com

Durante el proceso, para que una tarea se pueda empezar a desarrollar, hay que tener siempre en cuenta lo acordado en el DoR. En la metodología BDD, se puede añadir el punto de no empezar el desarrollo y la automatización hasta que el ticket no contenga todos los criterios de aceptación cubiertos por escenarios. De la misma manera, para poder finalizar una tarea hay que cumplir el DoD: Hasta que la build no tenga todos los tests unitarios y escenarios automatizados con una ejecución OK en la pipeline, la tarea no se puede considerar terminada.

Lenguaje Gherkin

El Gherkin es un Lenguaje de dominio específico (DSL) utilizado en la metodología del BDD. El formato utilizado es propio del lenguaje natural, por lo que permite entender la descripción del comportamiento bajo un punto de vista no técnico. De esta manera, se pueden identificar los diferentes escenarios relativos a los casos de uso redactados por el Product Owner, escribirlos en formato Gherkin y pueden ser interpretados, desarrollados y automatizados posteriormente por cualquier integrante del equipo: Perfiles de negocio, desarrolladores o QAs.

Los escenarios descritos en Gherkin tienen una sintaxis muy concreta que conectan el concepto de causa-efecto del lenguaje humano con el concepto de software de input-proceso-output. El standard Gherkin utiliza unas palabras clave características en sus pasos:

GivenPrecondiciones necesarias preparar el estado inicial del sistema para que el usuario pueda interactuar.

WhenAcciones que el usuario ejecutará para obtener el output deseado.

ThenValidaciones que se realizaran para comprobar que el output coincide con la descripción del escenario.

And Extensión de cualquier palabra clave del paso descrito anteriormente.

Ejemplo de la utilización del lenguaje Gherkin para el testeo de una máquina de refrescos

Scenario: Compra de un refresco

Given la máquina esta encendida

And el usuario inserta el importe exacto del coste del producto

When el usuario selecciona el número del producto deseado

Then la máquina entrega el producto seleccionado

Buenas prácticas

Pese a que no hay normas estrictas ni limitaciones técnicas a la hora de escribir escenarios, existen podcasts y blogs de los desarrolladores de Cucumber (herramienta que se utiliza para la automatización de pruebas descritas en Gherkin) donde recomiendan una serie de patrones para que los escenarios sean más entendibles: 

  • Los escenarios tienen que ser cortos, pero con la información necesaria. Se recomienda no utilizar más de 5 steps.
  • Las features, agrupaciones de escenarios, no deben sobrepasar los 10 escenarios.
  • Los steps deben describir el comportamiento del sistema, no acciones concretas del usuario como escribir o clickar.
  • El escenario debe verificar un comportamiento concreto y no hacer varias validaciones a la vez.
  • Como sujeto, es preferible evitar la primera persona del singular “I” y hacer referencia al usuario final en tercera persona.

En caso de que los escenarios no cumplan los estándares mencionados anteriormente, hay que recordar que la metodología promueve una comunicación directa entre PO-DEV-QA. Por lo que, si cualquiera de las partes detecta una mala definición, se puede iterar sobre el escenario modificando sus steps o dividiendo el comportamiento del sistema en más features, si se da el caso de que el requisito presentado inicialmente es muy extenso.

Conclusión

Gracias a la existencia del BDD, se ha conseguido establecer estándares de desarrollo de software que conectan a todos los roles dentro de un equipo Ágil. Frecuentemente, se tiende a aislar algunas partes del proceso creyendo que pueden funcionar de manera independiente. Es un ejemplo el hecho de ver la parte del testing como algo que se debe realizar en la parte final, cuando ya existe algo tangible del producto. Este concepto es un error si tenemos en cuenta que muchos bugs que se encuentran en la última parte del proceso son en realidad un problema de definición, que se realiza al principio. Si tenemos en cuenta el comportamiento del sistema y se hace partícipe en la definición de los casos de uso a todas las partes del equipo, se evitan muchos errores de comunicación entre que es lo que quiere nuestro cliente, como hay que desarrollarlo y que pruebas se van a realizar para validar la calidad del producto.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Suscríbete a nuestro boletín de noticias

Recibe actualizaciones de los últimos descubrimientos tecnológicos

Acerca de Apiumhub

Apiumhub reúne a una comunidad de desarrolladores y arquitectos de software para ayudarte a transformar tu idea en un producto potente y escalable. Nuestro Tech Hub se especializa en Arquitectura de Software, Desarrollo Web & Desarrollo de Aplicaciones Móviles. Aquí compartimos con usted consejos de la industria & mejores prácticas, basadas en nuestra experiencia.

Posts populares
Obtén nuestro Libro: Software Architecture Metrics

Global Software Architecture Summit '22

Reserva tu plaza!

Reserva

¿Tienes un proyecto desafiante?

Podemos trabajar juntos

Secured By miniOrange