Es verdad que BDD estaba o está pensando como una parte desarrollo de software, principalmente la parte de Testing, no obstante tiene tantos beneficios, que no se debe de marginar o ver como solo una práctica o proceso de testing o calidad de producto.
BDD permite escribir los requisitos (en este caso se refiere a Historias de usuario) y sobre todo los criterios de aceptación en una manera fácil de entender (desde la perspectiva del negocio o usuario) por todas las partes. Y se pueden escribir así (seguro que resulta familiar 🙂):
Given [context], when [event occurs], then [outcomes]
Para crear estos criterios, es importante intentar responder a las siguientes preguntas:
- ¿Quién es el usuario (rol, perfil, etc.) de esta historia?
- ¿Sabemos qué esperan estas personas de esta historia o feature?
- ¿Habrá combinaciones/variaciones en la interacción?
- ¿Qué acciones realizan los usuarios?
- etc.
Luego veremos cómo aterrizar esto o como Gherkin nos permite aterrizar a algo programable y como se pueden automatizar estos criterios
Indice de contenidos
Beneficios de utilizar BDD en el desarrollo de producto
El desarrollo dirigido o guiado por comportamientos ( BDD ) tiene muchos beneficios a nivel de calidad de producto y de desarrollo del mismo, además de muchos otros beneficios y ventajas que mencionaremos a continuación:
Colaboración
Bdd es una manera excelente para colaborar el PO u/y otros stakeholders de negocio con los desarrolladores en refinar algunos Product Backlog Items (PBIs) (en las sesiones de refinamiento del Product Backlog o las propias Sprint Planning). Una manera que puede ayudar para trabajar este refinamiento utilizando BDD (da igual que utilices el marco de trabajo Scrum o el método Kanban ) es utilizar la práctica de Three Amigos
Se puede considerar que bdd es una mejora o evolución de Three amigos ya que nos permitirá aterrizar los criterios de aceptación a posibles pruebas que se pueden automatizar. Esta automatización es una inversión a medio y largo plazo, es verdad que al inicio del desarrollo del producto puede existir la sensación de poco valor o impacto de esta práctica, pero conforme avanzan los desarrollos y saltan los BUGs nos acordaremos de ellas.
Transparencia
Cada comportamiento del producto nos lleva a un escenario con un posible resultado e interacción del usuario. Algo que permite contarnos la experiencia o el comportamiento específico del usuario con el producto. Esto resulta en un entendimiento común entre el Product Owner, Stakeholders y Developers sobre lo que se espera de este PBI y en concreto este criterio de aceptación. Algo muy positivo a la hora de dividir PBIs en los refinamientos 😉
Una buena organización
BDD está pensado para acelerar el ciclo o proceso de desarrollo de software y de producto. Para ellos todas las personas de desarrollo deben de tener la misma base de escenario, que se crearán utilizando el lenguaje Gherkin ( mencionaremos más adelante ). Al utilizar Gherkin para escribir estos escenarios permite agilizar el proceso de automatización de pruebas, detección de fallos en el sistema de un modo temprano, recoger el feedback y mejorar.
Shift Left
Desplazar la parte de pruebas a la izquierda para poder poner foco en las pruebas y su automatización antes del desarrollo, algo que permitirá detectar errores pronto y ajustar.
¿Cómo utilizar Gherkin y BDD?
Primero aclaremos que es Gherkin, Gherkin es un domain-specific language (DSL) que permite definir el comportamiento de un usuario con el producto sin necesidad de llegar a implementarlo. Gherkin utiliza una sintaxis simple y sencilla, es una sintaxis entendible por cualquier persona involucrada en el producto (de negocio o técnica):
Feature:
Scenario:
Given
When
Then
Veamos algún ejemplo de Gherkin
Feature: Buscar vuelo
#Opcional : Como viajero, quiero buscar vuelos disponibles entre Madrid y París para poder reservar un viaje en una fecha determinada.
Scenario: Buscar todos los vuelos disponibles basados en fecha, origen y destino
Given la fecha de viaje «01/01/2023» y el origen «Madrid» y el destino como «Paris».
When clic en el botón Buscar
Then La página de búsqueda mostrará todos los vuelos disponibles
And proporcionar la opción de reservar el vuelo
Un pequeño tip: a la hora de dividir las historias de usuario a veces puede resultar muy complejo dividirlas en unos PBIs que se pueden entregar durante el Sprint, pues cada criterio de aceptación y cada And se pueden convertir en una nueva historia
Ver también como implementar BDD utilizando cucumber
También te puede interesar el tema de Desarrollo dirigido por pruebas o TDD
