En el presente documento se detalla los lineamientos actuales para la utlización de la metodología de Gherkin en las mesas.

CONTROL DE VERSIONES DEL DOCUMENTO

¿Qué es Gherkin?

Gherkin es un lenguaje legible por humanos y máquinas, diseñado para definir el comportamiento del software sin detallar cómo se implementa esa funcionalidad. Se utiliza para escribir casos de prueba en un formato estructurado, claro y comprensible.

¿Cómo funciona?

• Gherkin utiliza una sintaxis basada en un conjunto limitado de palabras clave, como Feature, Scenario, Given, When, Then, And, y But.
• Cada Feature describe una característica del software y contiene varios Scenarios, que son ejemplos concretos de cómo debería comportarse esa característica.
• Los pasos Given, When y Then definen las condiciones previas, la acción que se está probando y el resultado esperado, respectivamente.
• En el caso de los proyectos de las mesas ágiles se deberá usar el lenguaje gherkin en Español por lo cual se debe colocar la etiqueta #language: es, al inicio del desarrollo de los feature de gherkin.

Ejemplo:

1. Se tiene un caso de prueba el cual es brindado y revisado por el PO, en el cual nos indica cual es el resumen de la historia de usuario de la cual se va a trabajar.

2. El PO plantea el escenario con la cual se va a trabajar y plantea todos los escenarios posibles para la validación de la historia y que el cumplimiento sea al 100%.

3. El PO plantea los criterios de aceptación que debe tener la historia de usuario para que el Tester automatizador tenga el input de los escenarios de prueba que va a desarrollar y el desarrollador tenga el input de las pruebas unitarias que debe de construir.

4. El QA y DEV plantean sus escenarios de prueba basandose en los criterios de aceptación establecidos por el PO.

Flujo de Trabajo Anterior

Anteriormente el flujo de trabajo del proceso de gherkin, contemplaba que el QA y DEV debían establecer sus criterios de aceptación y escenarios de pruebas basandose en el resumen que el PO les brindaba, por lo cual se tenía diferentes contemplaciones a la hora de realizar un script automatizado o una prueba unitaria, la cual traía muchas iteraciones por los cambios que se pedían para que los C.A sean lo más orientado posible a lo que requiere la Historia de usuario.

Flujo de Trabajo Actual

Se establece el siguiente flujo de trabajo, en el cual el PO es el principal gestor brindando los escenarios y criterios de aceptación para que una historia de usuario sea cumplida al 100% y con esto evitar tener más de 1 iteracción por lo cual se estarían ahorrando costes a nivel productivo en caso hubiera algún error o cambio en la descripción de la HU.