BDD y Gherkin para comunicar mundos diferentes.

Había una vez una hormiguita muy laboriosa que se dedicaba a escribir documentación exhaustiva sobre los procesos y la definición funcional de su sistema gran parte de su tiempo. Cuando las hormiguitas desarrolladoras tenían que leer esos documentos, estaban repletos de información técnica para que pudieran comprenderlos. Sin embargo, al compartir ese documento con las hormiguitas del negocio, esa documentación ya no servía, y ella elaboraba una nueva orientada al negocio. Cuando la hormiguita encargada de automatizar pruebas llegaba, tenía que combinar ambas y tratar de determinar qué pruebas implementar.

Este cuento deja de ser una historia de fantasía cuando las hormiguitas se transforman en profesionales eficientes que conocen Gherkin y BDD, y comienzan a comprender cómo sacar provecho de estas herramientas.

Gherkin

Gherkin es un lenguaje natural específico del dominio (DSL - Domain Specific Language) que puede ser entendido tanto por perfiles de negocio como técnicos e incluso puede ser traducido en código de manera automática. Consiste en una estructura de elementos y características que describen comportamientos y acciones de manera sencilla. La parte básica de Gherkin consta de cinco partes principales:

• Feature (característica): breve descripción de la funcionalidad a describir, redactada en un nivel alto.
• Scenario (escenario): una característica puede contener varios escenarios, cada uno describiendo diferentes características que resuelven la funcionalidad descrita.
• Given (dado que): precondiciones que deben cumplirse en el escenario antes de ejecutar las acciones.
• When (cuándo): condiciones que disparan la acción.
• Then (entonces): resultados esperados después de que la acción se ejecute.

Ejemplo:

Característica: gestión de hojas del almacén del hormiguero.
Escenario: llevar hojas al hormiguero.
Dado que tengo una cantidad previa de hojas en el hormiguero.
Cuando ingreso nuevas hojas.
Entonces la cantidad de hojas del hormiguero debería incrementarse.

También contamos con otros elementos más específicos para describir situaciones de mayor complejidad.

• Background (contexto): es un atributo para el elemento feature. Con este atributo se puede definir precondiciones generales comunes a todos los escenarios.
• And (y): es un conector lógico para separar diferentes condiciones cuando queremos indicar que todas deben cumplirse.
• Or (o): es también un conector lógico para separar diferentes condiciones cuando queremos indicar que alguna de ellas debe cumplirse
• But (pero): Se puede utilizar para excluir condiciones.
• Scenario template (plantilla de escenario): puede utilizarse cuando diferentes escenarios son muy similares y solo varían en determinados valores fijos, Se utiliza para describir el comportamiento mediante ejemplos.

Nada mejor que un caso práctico para comprenderlo:

Escenario: Llevar 5 hojas al hormiguero.
Dado que tengo 10 hojas previamente en el hormiguero y que el almacén no está lleno,
Cuando ingreso 5 hojas más
Entonces el hormiguero debería quedar con 15 hojas.

Escenario: Llevar 7 hojas al hormiguero.
Dado que tengo 30 hojas previamente en el hormiguero y que el almacén no está lleno.
Cuando ingreso 7 hojas más
Entonces el hormiguero debería quedar con 37 hojas.

Puede definirse la plantilla del escenario de la siguiente forma:

Escenario: Llevar hojas al hormiguero.
Dado que tengo <actual> hojas previamente en el hormiguero y que el almacén no está lleno.
Cuando ingreso <nuevas> hojas más.
Entonces el hormiguero debería quedar con <finales> hojas.

Ejemplos:
|actual|nuevas|finales|
|  10  |   5  |   15  |
|  30  |   7  |   37  |

Como puede verse en los ejemplos, la sintaxis es lo suficientemente simple para que cualquier perfil pueda entenderlo, y, sin embargo, es lo suficientemente específica para que pueda comprenderse la lógica del negocio.

BDD

BDD ayuda a eliminar ambigüedades en la definición y representa el comportamiento del sistema de manera clara, mejorando la comunicación entre desarrolladores y el Product Owner. Además, permite la automatización de pruebas mediante herramientas como Cucumber.

La implementación de Gherkin en BDD es útil para definir criterios de aceptación de historias de usuario, facilitando la comunicación y reduciendo problemas de interpretación.

Las siglas BDD provienen del inglés "Behavior Driven Development" (en español, "Desarrollo orientado al comportamiento"). Es una práctica que evoluciona a partir de TDD (Test Driven Development o Desarrollo orientado a pruebas), guiando el desarrollo a través de validaciones de comportamiento esperado en lugar de pruebas unitarias.

En la práctica, TDD nos enseñó que primero tenemos que desarrollar un unit test, hacerlo fallar, luego desarrollar el código que hace funcionar ese test, y al verificar que ya funciona nuevamente, iterar y avanzar con otra prueba hasta alcanzar el desarrollo completo.

BDD al servicio del desarrollo y del testing

La práctica de BDD ayuda a remover las ambigüedades de la definición, facilita la representación del comportamiento del sistema de una forma clara para mejorar la comunicación entre los desarrolladores y el Product Owner.

También permiten acceder a la automatización de casos de prueba mediante el uso de herramientas automatizadas como Cucumber o como nos enseñó el capitán Spock hace unos años para proyectos con Java o Groovy.

BDD al servicio de Agile

BDD, y particularmente la implementación de Gherkin, es muy útil para la definición de los criterios de aceptación de las historias de usuario. Pueden introducirse al equipo mediante las actividades de refinamiento que se realizan durante el sprint.

Además, es un recurso de bajo coste para validar comportamientos de manera anticipada.

El uso de Gherkin particularmente, ayuda a facilitar la comunicación entre los perfiles que interactúan en la construcción del software. Técnicos, negocio, UX, UI, clientes, todos pueden intercambiar información útil de una manera clara y que permita la reducción de problemas de interpretación.

Configuración de un template Gherkin para tus criterios de aceptación en Azure Devops

En Azure Devops puedes configurar una plantilla para que sea más fácil la adopción del uso de Gherkin en la elaboración de los criterios de aceptación.

• Opción 1

Dirígete a la configuración de tu equipo, selecciona el tipo de ítem al que quieres asignarle la plantilla (por ejemplo, “Product Backlog Item”) y en la pestaña de plantillas (“templates” en inglés), crea una nueva que puedes llamar de una forma que sea fácil de localizar. Selecciona el campo “Acceptance Criteria” y en el valor colocas un ejemplo de Gherkin en sintaxis HTML.

Después de guardar los cambios, encontrarás la plantilla grabada en los meatballs de la esquina superior derecha del ítem que has configurado:

Al seleccionarla, se completará el campo “Acceptance Criteria” con el ejemplo seleccionado.

• Opción 2

Dentro del propio ítem al que quieres generar una plantilla. Dirígete a los meatballs de arriba a la derecha y en la sección templates elige “Capturar”y accederás a una plantilla pre-cargada con todos los campos que en ese momento tengan valor. Podrás seleccionar cuáles dejar grabados o quitar los que no resulten de interés. En nuestro caso, podríamos quitar todos y dejar solo el campo de criterios de aceptación y dejar así grabada la plantilla.

Tip. Si has editado los criterios de aceptación, antes de guardar la plantilla, dando formato al texto, se completará el valor del campo con el código HTML que se corresponde con dicho formato, facilitando la tarea de escribirlo manualmente que indicamos en la opción 1.

Configuración de un template Gherkin para tus criterios de aceptación en Jira

Puedes recurrir a la configuración de automatización de tu proyecto para que de forma automática, al crear una nueva issue, el campo que usas para los criterios de aceptación ya comience cargado con la estructura de la sintaxis de Gherkin.

En la configuración de tu proyecto, crea una nueva regla siguiendo, por ejemplo, el disparador de “Incidencia creada”.

En el siguiente paso, seleccionaremos la opción “ENTONCES” y a continuación podemos seleccionar la opción de “Editar incidencia”. En el selector desplegable, seleccionamos el campo que queremos que se complete automáticamente y en la descripción indicamos el valor que queremos que aparezca.

Luego de grabar los cambios, al crear incidencias veremos que el campo seleccionado ya viene pre cargado con el contenido que hemos configurado:

Una historia que no acaba

Poco a poco, la hormiguita comenzó a armar historias de usuario con criterios de aceptación claros usando Gherkin, que se convirtieron en documentación viva del producto. Esto eliminó la necesidad de dedicar incontables horas a documentos no leídos. Logró que las diferentes hormiguitas buscaran y leyeran los comportamientos que les interesaban, manteniendo los criterios actualizados día a día. También mejoró la robustez de las pruebas automáticas y la estabilidad de las releases. Cualquier hormiguita stakeholder podía consultar las features y entender su funcionamiento. Las nuevas hormiguitas en el proyecto tenían a su disposición el comportamiento de todas las features para agilizar su integración al proyecto.

Por eso, te recomiendo: sigue a la hormiguita, por algo son una de las civilizaciones más eficientes y con mejor comunicación.

• Imagen de portada de Ilo en Pixabay.