Gherkin es un lenguaje de marcado, es decir, un sistema de etiquetado o codificación que se utiliza para describir la estructura y el contenido de un documento, en nuestro caso, de una historia de usuario.
Este formato a la hora de escribir historias de usuarios (HUs) permite añadir una pieza más a la integración continua que va desde la definición de una necesidad o funcionalidad hasta su puesta en producción y posterior seguimiento mediante métricas.
Uno de los mayores retos a los que se enfrentan los Product Owners y Product Managers es crear historias de usuario que comprendan todas las partes involucradas.
Para ello usamos BDD, Behavior Driven Development o desarrollo guiado por el comportamiento. Esto nos permite escribir escenarios de prueba en un formato comprensible tanto para las personas más técnicas que desarrollan esa HU como para las personas no-técnicas (los muggles o techless).
Habitualmente usamos mockups o maquetas para dar forma a nuestra historia de usuario. Si bien es cierto, los mockups no siempre son tan útiles, sobre todo si trabajas con APIs o entornos con menor carga visual, así que una buena alternativa para enriquecer las HUs está en el proceso BDD y, en particular, en el lenguaje Gherkin.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
BDD y Gherkin
BDD (desarrollo guiado por el comportamiento) es una metodología ágil propuesta por Dan North que va un paso más allá del TDD (desarrollo guiado por pruebas de software).
¿Qué diferencia hay entre BDD y TDD?
Tradicionalmente, las HUs se llamaban requisitos y se escribían pensando sólo en la parte técnica, hasta el punto que se orientaba la definición a las pruebas técnicas que se iban a realizar después. Esto cambia cuando ponemos al usuario en el centro, empezamos a escribir su historia, su necesidad y por tanto necesitamos describir comportamientos y no tanto pruebas técnicas.
Usamos BDD buscando cuatro beneficios clave:
- Comunicación: Todos hablan el mismo idioma: el lenguaje humano.
- Especificación: Proporciona un marco para redactar los criterios de aceptación.
- Documentación: El conjunto de escenarios sirve como documentación para enumerar las reglas de operación.
- Automatización: Con código adicional (y una buena dosis de rigor), podemos vincular los escenarios de aceptación a las pruebas automatizadas.
Entendiendo el propósito de BDD y sus principales ventajas, llegamos a una de las principales fuentes de frustración en el mundo del software, el clásico “negocio/tech no me entiende”. Con BDD podemos hacer descripciones comprensibles para toda persona involucrada en esa HU usando un lenguaje común: Product Owner, devs, testers, Product Designers negocio, stakeholders y cualquier otra parte involucrada, incluso usuarios. Sería como el Pseudo Código de la tradicional definición técnica. Este lenguaje es Gherkin.
Gherkin se basa en una sintaxis específica, una estructura con un formato de lenguaje natural y fácil de seguir.
Con este lenguaje definimos escenarios, donde cada escenario comienza con la palabra clave "Given" (dado), después "When" (cuando) y por último"Then" (entonces).
Dado un ‘contexto inicial’ o escenario de partida
Cuando ‘se produce un acontecimiento’ o un evento o una acción específica.
Entonces ‘se produce un resultado determinado’ o una consecuencia prevista.
Los escenarios —que son tan completos como los mockups— ilustran, por ejemplo, lo que se espera de un software o una funcionalidad tras desarrollar la historia de usuario. Estos escenarios los recoge el equipo de desarrollo, quien los codifica tomando como referencia la historia de usuario a modo de prueba. Una vez pasada la prueba, la historia queda finiquitada.
Por ejemplo:
Escenario 1: La cuenta tiene crédito
- Dado una cuenta con un crédito de 1.200€ y una tarjeta válida y un cajero automático con 10.000€
- Cuando el cliente solicita 10€
- Entonces se cargan 10€ a la cuenta y el cliente recibe 10€ y se devuelve la tarjeta.
Escenario 2: La cuenta está endeudada.
Escenario 3: No hay más efectivo en el cajero automático.
Escenario 4: La tarjeta no es válida.
Escenario 5: Se produce un error inesperado en el cajero, como por ejemplo que no devuelve la tarjeta, o el rodillo que extiende el dinero se bloquea, etc.
Mi recomendación siempre es empezar por el escenario ideal o happy path, y después ir desmontando o rompiendo ese escenario ideal poco a poco. Cada pequeña “rotura” produce un nuevo escenario que debe ser contemplado. Para esto, si como Product Owner o Product Manager es la primera vez que te enfrentas a una definición en escenario o comportamientos busca ayuda, ya sea de personas con experiencia como QAs, Testers u otros PMs, o bien usa el Monkey Testing: pruebas random sobre la funcionalidad como si de un mono se tratase.
¡Sabemos que pasar de la teoría a la práctica no es fácil! Te ayudamos en esta transición con nuestros cursos de Product Manager
«Los tres amigos» y la redacción de escenarios
Entre las buenas prácticas del BDD están los talleres de trabajo «Los tres amigos», que pueden resultar muy beneficiosos. El número de participantes no es tan importante como la multidisciplinariedad de los perfiles que se sientan a la mesa.
Lo ideal es que en este taller participe un representante de la tarea desde el punto de vista de negocio (Product Owner, Product Manager, Stakeholder), un representante del usuario (Product Designer, Product Manager, QA, tester) y un representante del área técnica (Dev, Tech Lead, Arquitectura). Dependiendo del contexto del producto habrá unos representantes u otros, incluso alguna otra área que necesite representación en esa mesa para que juntos escriban los escenarios.
Estas sesiones permiten crear una visión común y garantizan que todos los participantes comprenden bien los distintos elementos. Además, permiten ahondar en las historias de usuario y anticipar como grupo los comportamientos esperados (es decir, el conjunto de criterios de aceptación).
A las sesiones hay que dedicarles bastante tiempo, pero son muy importantes cuando el producto comienza a desarrollarse. Con el tiempo, el equipo se acostumbra a hablar el mismo lenguaje de forma natural y podemos escribir los escenarios de manera más independiente.
Para aprender más, descarga nuestra biblia de producto: Agile Product Management
