Debe haber centenares post sobre BDD y sí… este es uno más, con las características especiales de estar en español y estar escrito y pensado para aquellos que desconocíais el tema BDD por completo y queráis en poco tiempo “saber de qué va” esto, de sacar la idea principal de por qué esto del BDD es importante y por qué cada vez se habla más de ello.
En las próximas semanas iré dejando un post sobre BDD y relacionados, este es una primera y básica introducción, el siguiente será probablemente de Cucumber, etc. Me vais a disculpar que no fije un día exacto para esta serie de post “BDD”, pero es que ando demasiado liado para poder comprometerme a un día exacto (de hecho, créeme, este post que lees, y otros restos de la serie, lo empecé en abril y lo he ido terminando a ratos)
Estaría encantado de recibir comentarios, mejoras, detalles, añadidos y demás, sé que entre los lectores del blog hay auténticos expertos en BDD, animaros y me ayudáis a difundir el conocimiento sobre el tema del BDD y de “las buenas pruebas”.
Vamos a ello…
¿Qué es eso de BDD?
Behavior-Driven Development o BDD es un proceso de desarrollo software, si bien se relaciona principalmente con el Testing, que es de donde surge.
BDD busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.
En BDD, las pruebas de aceptación se escriben usando historias de usuario, ya sabes aquello tan usado en agilidad (sino léete el anterior post)… «Como [rol ] quiero [ característica ] para que [los beneficios].»
Y, siguiendo con lo anterior, posteriormente escribir criterios de aceptación para esas historias de usuario, haciéndolo en términos de escenarios:
Dado [contexto inicial], cuando [se produce el evento], entonces [resultados]
Given [initial context], when [event occurs], then [ensure some outcomes].
Así, simplificadamente, el ciclo básico de BDD sería el siguiente…
1 – Escribir las historias de usuario.
2 – Escribir los escenarios.
3 – Automatizar las pruebas de aceptación.
Ya sabes, con la idea final de tener un mismo “framework” de comunicación y colaboración entre desarrolladores, QA y roles no técnicos, o de negocio, en un proyecto de software. Y para tener ese punto común entre todos esos actores, algo clave es tener un lenguaje común, y ahí es donde aparece Gherkin…
Gherkin
Las historias de usuario que comentamos antes, o features (en el mundo BDD puedes encontrar las historias de usuario bajo el nombre de features, hay quien dice que no son exactamente lo mismo, pero para nosotros por ahora sí lo son), lógicamente, las escribe negocio, es responsabilidad del product owner.
En BDD, lo que haremos será, con el objetivo de automatizar el testing, aparte de tener historias en pósit, como ha sido de toda la vida, cada historia de usuario se escribirá usando un lenguaje “de programación”, llamado Gherkin (la traducción es pepinillo), y se guardarán en un fichero, de extensión .feature (normalmente dentro de un directorio llamado “features”, para más datos).
Gherkin es un lenguaje entendible por el negocio, lo que se llama un DSL (Domain-Specific Language), más o menos cercano al lenguaje natural. Está pensado para que lo entienda “negocio”, los usuarios, etc. Su idea es contar como se “comporta” el software sin entrar en detalles de implementación.
Es un lenguaje muy simple. Sólo tienen 5 sentencias:
Feature:
Scenario:
Given
When
Then
Estas features serían historias de usuario. Y como es típico en una historia de usuario, deben tener el “As a / I want to / Because”. Vamos con un ejemplo, la historia de usuario “Tener un Camión”:
Feature: Tener un Camion
As a Rockero
I want to a Camion
Because I want to be happy
Así que Gherkin nos sirve para documentar y para automatizar lo que luego se convertirá en test, haciéndolo con un lenguaje que puede entender negocio, o cualquier product owner, y que además puedes usar en otros idiomas más allá del inglés, hasta la fecha en 40 idiomas.
Luego necesitaremos una herramienta que entienda los .feature, por ejemplo, Cucumber (para Ruby), que cuando lo lanzas genera un informe que verifica si el software se comporta como el fichero Gherkin dice. Para ello, alguien del equipo habrá escrito código que transforma el texto de Gherkin en interacciones con el código a probar, pero antes, para ello, necesitaremos escenarios asociados a cada historia de usuario, que nos den ejemplos de cómo debe comportarse el software implementado para esa historia.
Esos escenarios serán el paso intermedio entre la historia de usuario y la implementación de una prueba automatizada. Pero como este post ya se me a alargado demasiado… los escenarios y herramientas como cucumber… lo dejo para la segunda parte.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Entendiendo qué es BDD (Behavior-Driven ...
Ese «continuará» nos ha dejado con la miel en los labios 🙂
😉
Como siempre, Javier entregand grandes artículos. Una pregunta: Se pude hacer una comparación de BDD con los casos de uso que se utilizan en UML.??
Más o menos, pero el elnguaje Herkin describe más historias y escenarios que casos de uso, por ejemplo, no tiene precondiciones del tipo a las de los CU
Todavía se utilizan CU? Para qué son recomendables? Saludos! Muy bueno tu blog, me es muy útil 🙂
Un post realmente bueno y directo para alguien que está empezando con BDD como yo. ¡Esperando ansioso la segunda parte!
Gracias y un saludo.
muy interesante tu post, muchas gracias
Es cierto que los criterios de aceptación deben ser escritos por el PO, para cada escenario en la historia de usuario a verificar, aunque BDD es también aplicable a sistemas aislados del usuario final.
Como ejemplo, en una arquitectura basada en microservicios en la que he trabajado unos años, muchos de ellos eran backend, por lo que el usuario final no tenía contacto con ellos, lo que implica que los criterios de aceptación del producto (importante) no estaban directamente alineaados con la API del servicio, ya que ésta era solamente una parte del producto, y por tanto, solamente una parte de la historia de usuario completa.
Para implementar BDD en estos servicios de backend, no es necesario que el PO escriba los criterios de aceptación. De hecho, es extraño que sea capaz de escribirlos, a no ser que este familiarizado con la arquitectura del sistema y el dominio de cada servicio. De manera que, dependiendo del contexto de cada servicio a testear, los criterios de aceptación (las features en BDD) podrían no ser escritas por el Prouct Owner.
Posiblemente esto entre ya en el debate de TDD, métodos y scopes de tests (tests de aceptación de servicio vs. tests de aceptación de producto). Pero es un detalle que quería comentar, tal vez en futuros posts pueda ser tratado.
Para los amantes de la JVM: http://pease.github.io/ + https://github.com/spockframework
Hola!
Estoy empezando a automatizar un proyecto que he cogido de cero pero ya desarrollado… quería crear mis propias historias de usuario e implementarlas pero no entiendo muy bien cómo hacerlo con Cucumber etc ya que dices que hay código por debajo para picar (es lo que voy a hacer pero no sé a qué te refieres concretamente)
Gracias
En esta oficina se implemento el Scrum y es nuevo para nosotros ya nos hablaron de los roles y el acomodo de papeles de colores para saber en que andas y que estas haciendo y que vas a hacer, en mi caso soy el tester, en que momento es conveniente entrar, sera que como se van terminando las interfaces voy verificando …???