Gherkin es un lenguaje entendible por el negocio, lo que se llama un DSL (Domain-Specific Language), más o menos cercano al lenguaje natural. Está pensado para que lo entienda el negocio, los usuarios, la parte técnica etc. Su idea es describir una funcionalidad del software sin entrar en detalles de implementación, es decir, SIEMPRE en términos de negocio y no del sistema.
Y tal vez te preguntes ¿Cómo así que en términos de negocio y no del sistema?
Pues bien, cuando hacemos referencia a la interacción con los objetos de una página ( hablando en términos de automatización de pruebas), es decir, “dar click sobre el botón Iniciar Sesión, ingresar el nombre de usuario en el campo User, hacer scroll down sobre la lista de ítems”, son ejemplos de acciones a nivel del sistema con el que se interactúa y los cuales son prácticas NO RECOMENDADAS cuando estamos trabajando con BDD, es por esto que el Product Owner o usuario del aplicativo deberían ser quienes escriban las historias de usuario, describiendo qué es los que se requiere siempre en términos de negocio, pero esto no quiere decir que alguien del equipo, ya sea tester o desarrollador no pueda tomar parte en el refinamiento de éstas, de hecho, es una práctica recomendada y de la cual hablaremos en el tema de ATDD y brainstorming.
Una historia de usuario describe una funcionalidad que será valiosa para un usuario o un comparador de un sistema de software. Una historia de usuario se compone de 3 partes: