Saltar al contenido principal
Página

Tema 2.1 - ¿Qué es Gherkin?

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.


Ventajas:

  • Gherkin es lo suficientemente simple para que los no programadores lo entiendan
  • Los programadores pueden usarlo como una base muy sólida para comenzar sus pruebas
  • Hace que las historias de usuario sean más fáciles de digerir
  • Se dirige a los requerimientos del negocio
  • Una proporción significativa de las especificaciones funcionales se escribe como historias de usuario
  • No necesitas ser un experto para entender el pequeño conjunto de comandos de Gherkin
  • Gherkin vincula las pruebas de aceptación directamente a las pruebas automatizadas
  • Los casos de estilo de escritura de pruebas son más fáciles de reutilizar el código en otras pruebas


Desventajas:

  • Requiere un alto nivel de compromiso empresarial y colaboraciones.
  • Puede que no funcione bien en todos los escenarios
  • Las pruebas mal escritas pueden aumentar fácilmente el costo de la prueba de mantenimiento.


¿Qué es una historia de usuario?

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:

  1. Una descripción escrita de la historia usada para planificar y como recordatorio.
  2. Conversaciones acerca de la historia que sirven para desarrollar los detalles de la historia.
  3. Un conjunto de tests que transmiten y documentan detalles que indican cuándo se completa una historia de usuario.
Última modificación: martes, 22 de marzo de 2022, 14:49