GHERKIN, LA UNIÓN IDEAL ENTRE NEGOCIO, DESARROLLO Y PRUEBAS

  Por: Luis Bermeo - Analista de Pruebas

A la hora de ejecutar un desarrollo, es importante alinear las expectativas de todas las partes: lo que espera negocio, lo que debe construir desarrollo y lo que debe validar pruebas. Una única verdad hará mucho más fácil el éxito del producto, la herramienta que nos puede ayudar es Gherkin.

Para entender y ver el verdadero potencial de Gherkin, empecemos por hablar un poco de BDD (Behavior-Driven Development), el cual  no es solo un marco de trabajo para el área de pruebas, es un marco que involucra a las áreas más importantes al momento de construir un Software, como son: negocio, desarrollo y pruebas. Además, se adecua y facilita el uso de agilidad.

Dan North el creador de BDD explica que es una metodología de "fuera hacia dentro", porque comienza explicando los requisitos de negocio, el comportamiento esperado de aquello que se programará y termina identificando que se cumplan estos requisitos. Por otro lado BDD busca disponer de un lenguaje común para unir la parte técnica y la de negocio, siendo allí donde inicien las pruebas y el desarrollo. 

En BDD existen varios lenguajes, el más popular Gherkin el cual es un lenguaje muy simple, técnicamente es un DSL (Lenguaje de Dominio Específico) muy cercano al lenguaje natural. Usar este lenguaje es de gran ayuda para stakeholders, negocio, desarrollo y testers, ya que proporciona una forma sencilla de escribir necesidades, hacer documentación viva (que luego se va a poder ejecutar) y definir pruebas que puedan ser entendidas por todos.

La idea de Gherkin es contar cómo se comporta el software sin entrar en detalles de implementación, su objetivo es disponer de un lenguaje que sea fácil de leer tanto para desarrollo, negocio y pruebas, siendo cooperativo entre los mismos, cuando este se usa únicamente como una herramienta para automatizar pruebas y sin la participación de negocio este pierde su valor. 

Para ver cómo este lenguaje nos puede ayudar en la creación de historias de usuario, documentación, pruebas unitarias y pruebas de aceptación, veamos este ejemplo:

Una historia normal:

  Yo como usuario quiero sumar números 

  Para evitar hacer errores tontos

  Como un ser humano

  Quiero saber la suma de dos números.

 Una Historia usando Gherkin:

Característica: yo como usuario quiero una calculadora 

  Para evitar hacer errores tontos

  Como un ser humano

  Quiero saber la suma de dos números

  Esquema del escenario: Sumar dos números

   Dado que he introducido <numero1> en la calculadora

    Y que he introducido <numero2> en la calculadora

    Cuando oprimo el <botonSumar>

    Entonces el resultado debe ser <resultado> en la pantalla

   Ejemplos:

    | numero1   | numero2 | botonSumar | resultado |

    | 20            | 30            | sumar     | 50         |

    | 2              | 5               | resta        | 3           |

Como podemos observar usando este lenguaje tenemos la historia, el caso o los casos de pruebas tanto unitarios como de aceptación, contamos con la documentación fácil de acoplarse a los cambios de negocio y nos genera todos los métodos que debemos de usar en la pruebas.

En términos generales, Gherkin es fácil de usar y comprender, también ayuda a reducir tiempo y a reutilizar descripciones por negocio, además nos facilita la automatización de pruebas y da una idea más clara de los flujos que se deben de automatizar para las mismas.