Table of Contents
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: Captures the requirements requested by the client (stakeholders).
- Developer: Implements the requirements captured by the business to create the product.
- 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:
- El PO se reúne con el stakeholder para obtener el requisito funcional.
- El PO escribe el requisito en formato de User Stories “As a [user], I want [functionality], so that [Benefit]”
- Un representante de cada perfil (PO, DEV y QA) se reúnen refinar, estimar e identificar los escenarios para cubrir la User Story.
- Se crean tareas con la definición + escenarios acordados.
- Paralelo al punto 6: Los desarrolladores programan la funcionalidad descrita.
- Paralelo al punto 5: Los QA automation automatizan los testing scenarios descritos.
- 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.
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:
Given – Precondiciones necesarias preparar el estado inicial del sistema para que el usuario pueda interactuar.
When – Acciones que el usuario ejecutará para obtener el output deseado.
Then – Validaciones 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.
