¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
dev
Mauricio A. Contrera Gaite 29/01/2024 Cargando comentarios…
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 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:
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.
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 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.
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, 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.
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.
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.
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.
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:
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.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Estamos comprometidos.
Tecnología, personas e impacto positivo.
Cuéntanos qué te parece.