Introducción

En un proyecto de desarrollo de software, la comunicación efectiva es clave. En este artículo, exploraremos cómo el lenguaje Gherkin actúa como un puente entre los perfiles técnicos y no técnicos, facilitando una colaboración más fluida y eficaz de los equipos de trabajo.

Arquitectura de un proyecto

En la mayoría de las empresas, los proyectos de desarrollo de software se organizan dentro de un marco estructurado que ayuda a gestionar y hacer un seguimiento de todas las actividades relacionadas.

Software Development Life Cycle

Se suele empezar por la fase de planificación, donde se definen los objetivos, el alcance y los requisitos del proyecto. Esta fase inicial es vital para establecer una dirección clara y alineada con las expectativas de las partes interesadas.

La siguiente fase es la del diseño, donde se desarrolla la arquitectura del sistema y se esbozan las especificaciones técnicas. Durante esta fase se elaboran diagramas, se modelan estructuras y se identifica el conjunto de tecnologías y herramientas a emplear. Posteriormente, en la fase de desarrollo, los programadores escriben el código siguiendo las especificaciones.

La fase de pruebas sigue al desarrollo. Aquí, se verifica y valida el funcionamiento del software para asegurar que cumple con los requisitos y no presenta defectos. Se realizan pruebas unitarias, integradas y de sistema para garantizar la calidad del producto.

Finalmente, el software es desplegado en el entorno de producción, lo que da paso a la fase de mantenimiento. Durante esta fase, se resuelven los problemas reportados por los usuarios finales y se implementan mejoras, garantizando que el sistema continúe funcionando de manera eficiente.

Esta estructura, conocida comunmente como Software Development Life Cycle (SDLC), permite gestionar los proyectos de manera efectiva, asegurando que cada etapa del desarrollo esté claramente definida y controlada.

Fases del ciclo de vida del desarrollo de software:

  1. Planificación
  2. Diseño y prototipado
  3. Implementación
  4. Pruebas
  5. Despliegue
  6. Mantenimiento

La falta de atención y cuidado adecuados durante cualquiera de estas fases puede ocasionar la aparición de problemas en las etapas posteriores, lo que provoca retrasos en la entrega y costes adicionales.

Actores principales

En un proyecto de esta envergadura se trabaja con una amplia gama de perfiles que aportan diferentes habilidades y perspectivas, esenciales para el éxito del proyecto. Estos perfiles suelen categorizarse en técnicos y no técnicos.

Perfiles técnicos

Los perfiles técnicos son los responsables de la implementación y el funcionamiento del software. Aunque hay muchos más, principalmente encontramos:

  1. Software Architect: Diseñan la estructura del sistema y toman decisiones tales como seleccionar las tecnologías y definir los estándares de codificación y diseño para garantizar escalabilidad y mantenibilidad.
  2. Tech Lead: Dirigen a un equipo de desarrollo y son responsables de la calidad de sus productos técnicos. Colaboran estrechamente con el equipo de desarrollo para alcanzar los objetivos establecidos.
  3. Desarrolladores: Escriben el código y colaboran con los arquitectos y analistas para convertir las especificaciones técnicas en un producto funcional, creando funcionalidades, implementando mejoras y solucionando errores. Aquí nos podemos encontrar a los desarrolladores Backend y Frontend, que son más especializados, y a los desarrolladores Full-Stack, que son más generalistas.
  4. QA Lead: Supervisan y coordinan las actividades relacionadas con el aseguramiento de la calidad. Lideran y gestionan el equipo de QA (Quality Assurance) y se dedican a buscar formas de mejorar los procesos y la eficiencia.
  5. Ingenieros de QA: Su labor consiste en asegurar que el software cumpla con los criterios de calidad establecidos, diseñando y ejecutando pruebas automatizadas y manuales para detectar y documentar fallos, asegurando la estabilidad del producto y la ausencia de errores para el usuario final.
  6. DevOps: Optimizan la integración y entrega continua (CI/CD), gestionan la infraestructura y automatizan los flujos de trabajo de desarrollo y despliegue. Se enfocan en que el paso del desarrollo a la producción sea fluido y eficiente.
  7. Administradores de bases de datos: Gestionan las bases de datos, realizan backups y aseguran el rendimiento, seguridad y accesibilidad. Participan en el diseño del modelo de datos y en la optimización o refactorización de consultas.

Perfiles no técnicos

Igualmente esenciales, los perfiles no técnicos se ocupan de la planificación, coordinación y alineación del proyecto con los objetivos de negocio. Entre ellos, destacamos:

  1. Stakeholders o partes interesadas: Son los principales interesados en el éxito del proyecto, como inversores, patrocinadores, usuarios finales y clientes. Su función es proporcionar orientación y retroalimentación para garantizar que el producto cumpla con sus expectativas y necesidades.
  2. Project Managers: Supervisan la planificación, ejecución y conclusión del proyecto. Aseguran que el proyecto se complete a tiempo, dentro del presupuesto y cumpliendo con los estándares de calidad. Identifican y manejan riesgos y se comunican con todos los actores para que el proyecto avance.
  3. Product Owners: Sirven de enlace entre los Stakeholders y los equipos de desarrollo. Se encargan de comprender las necesidades de negocio y definen los requisitos del producto en las historias de usuario. También planifican las tareas en el Backlog de los equipos de desarrollo.
  4. UX/UI Designers: Aunque no necesariamente son perfiles no técnicos, sus responsabilidades suelen estar más alineadas con las de un perfil no técnico. Se encargan del diseño de la interfaz y la experiencia del usuario, asegurando que el software sea intuitivo, fácil de usar, agradable y accesible.

Comunicación dentro y fuera de los equipos

Como has podido observar, hay perfiles muy diferentes, pero probablemente has notado que algunos tienen la función de construir puentes y actuar como traductores. Esto no es casualidad. En el ciclo de vida del desarrollo de software, nos encontramos frecuentemente con actores que emplean un lenguaje técnico y otros que usan un lenguaje común, siendo para ambos un desafío comunicarse eficazmente.

A continuación, vamos a analizarlos y ejemplificarlos.

El lenguaje común

Durante las fases de un proyecto, a menudo surge una barrera de comunicación entre los distintos perfiles debido al uso de un lenguaje altamente técnico por parte de los desarrolladores y analistas. Los perfiles no técnicos, como los Product Owners, los Project Managers y los Business Analysts, pueden encontrarse con dificultades para comprender términos y conceptos técnicos, lo que dificulta su labor de definir con claridad las funcionalidades del producto.

Esto puede llevar a malentendidos, ambigüedades y a una desalineación entre las expectativas del cliente y lo que se puede lograr técnicamente. Es ahí donde surge la necesidad de establecer un lenguaje común que permita a todos los miembros, sin importar su conocimiento técnico, comprender y contribuir de manera efectiva al proyecto.

El lenguaje técnico

El lenguaje técnico es una herramienta esencial para los desarrolladores y otros profesionales del ámbito técnico, ya que lo emplean para comunicarse, colaborar, intercambiar información, y describir los detalles del diseño, implementación y funcionamiento del software. Es un lenguaje más estricto, lo que previene confusiones o malentendidos.

Aunque este lenguaje se caracteriza por ser preciso y descriptivo, puede ser complejo para quienes no tienen experiencia técnica. Es muy común que se encuentren con términos y conceptos desconocidos que necesitan explicaciones adicionales para comprender su significado y su importancia en el proyecto.

El lenguaje Gherkin

Hemos visto que los distintos perfiles utilizan lenguajes diferentes, lo cual es esencial para facilitar la colaboración entre los miembros de un mismo equipo. Sin embargo, esto no debe convertirse en un obstáculo para la comunicación entre equipos, especialmente cuando interactúan perfiles técnicos con no técnicos.

Para abordar este desafío, se introduce la metodología llamada Behavior Driven Development (BDD, por sus siglas en inglés). BDD busca mejorar la colaboración entre desarrolladores, testers y perfiles no técnicos, enfocándose en el comportamiento esperado del software más que en detalles técnicos de implementación. Este enfoque promueve un entendimiento mutuo y una comunicación más clara.

Dentro del marco de BDD, se utiliza un lenguaje específico llamado Gherkin. Gherkin es un lenguaje diseñado para expresar comportamientos de software de una manera legible y estructurada, comprensible tanto para perfiles técnicos como no técnicos. Surge como una herramienta clave para definir casos de prueba, permitiendo que todos los miembros del equipo participen en la definición y verificación de los requisitos del software.

ℹ️

Gherkin permite definir criterios de aceptación de manera colaborativa.

Para emplearlo de manera efectiva, es necesario tener un conocimiento básico de la sintaxis del lenguaje y una comprensión clara de los conceptos de BDD.

Ejemplo de comunicación en los distintos lenguajes

Veamos cómo la comprensión de la definición de una misma funcionalidad que describa el proceso de inicio de sesión en una aplicación puede variar en función del lenguaje empleado:

  1. Lenguaje común:

    Quiero que el usuario pueda iniciar sesión en la aplicación utilizando su correo electrónico y contraseña.

  2. Lenguaje técnico:

    Implementar un sistema de autenticación mediante el uso de las credenciales de un usuario determinado.

  3. Lenguaje Gherkin:

    Feature: Inicio de sesión en la aplicación

  Scenario: Usuario inicia sesión con éxito (happy path)
    Given El usuario está en la página de inicio de sesión
    When El usuario introduce su correo electrónico y contraseña correctos
    Then El usuario debería ser redirigido a su página de inicio

  Scenario: Error al iniciar sesión debido a credenciales incorrectas
    Given El usuario está en la página de inicio de sesión
    When El usuario introduce un correo electrónico o contraseña incorrectos
    Then El usuario debería ver un mensaje de error

Como se puede observar en el ejemplo anterior, el lenguaje común resulta ambiguo, mientras que el lenguaje técnico puede ser complejo. No obstante, el lenguaje Gherkin emplea un lenguaje común que evita esas ambigüedades. Esto es sumamente importante ya que define la misma funcionalidad de tal manera que cualquier profesional pueda entenderla sin dar lugar a confusiones a ninguno de los perfiles que ya hemos visto antes.

ℹ️

Gherkin no solo sirve para facilitar la comunicación, sino que también puede ser ejecutado como parte de las pruebas automatizadas.

Además, el ejemplo muestra cómo una sola funcionalidad puede resultar en varios casos de uso o escenarios, lo cual es vital para que todos los equipos técnicos involucrados (en particular desarrolladores e ingenieros de QA) entiendan los criterios de dicha funcionalidad y puedan someterla a un control de calidad más riguroso.

Esto es más fácil de definir si uno se hace estas dos preguntas:

  • ¿Qué se espera que haga la funcionalidad?
  • ¿Qué se espera que no haga la funcionalidad?

La sintaxis de Gherkin

La sintaxis de Gherkin es sencilla y fácil de aprender, pensada para que tanto usuarios técnicos como no técnicos puedan leerla y escribirla sin dificultad. Un archivo de Gherkin contiene escenarios que detallan las diferentes funcionalidades del software. Los escenarios están compuestos por pasos, que utilizan palabras clave como Given, When y Then para establecer las condiciones previas, las acciones ejecutadas y los resultados esperados.

También están los pasos And y But, que sirven para añadir condiciones o resultados adicionales en los distintos momentos del escenario.

Feature: [Nombre de la funcionalidad]
  [Descripción]

  Scenario: [Nombre del escenario]
    Given [Contexto inicial]
    When [Acción realizada]
    Then [Resultado esperado]

Veamos un ejemplo real:

Feature: Gestión de tareas

  Scenario: Crear una nueva tarea
    Given El usuario está en la página de tareas
    When El usuario introduce el nombre de la tarea y hace clic en el botón "Crear"
    Then La nueva tarea debería aparecer en la lista de tareas

  Scenario: Completar una tarea existente
    Given El usuario está en la página de tareas
    And Hay una tarea existente llamada "Comprar leche"
    When El usuario marca la tarea "Comprar leche" como completada
    Then La tarea "Comprar leche" debería aparecer como completada en la lista de tareas

Esta sintaxis permite que los escenarios sean claros y entendibles para todos los miembros del equipo, facilitando la colaboración y la comunicación. Sin embargo, es muy importante mantener los escenarios simples y centrados en un único comportamiento para facilitar la comprensión y el mantenimiento.

Diferencias entre historias de usuario y Features

Los propósitos de las historias de usuario y las características o Features, a menudo pueden confundirse en el contexto de BDD. Analicemos cómo se relacionan y cómo diferenciarlas.

Una historia de usuario (o User Story) es una descripción de una funcionalidad desde la perspectiva del usuario final. Este concepto, propio de las metodologías ágiles, se centra en detallar qué quiere lograr el usuario y por qué. Veamos un ejemplo:

  • Como usuario,
  • Quiero poder iniciar sesión en la aplicación,
  • Para acceder a mis datos personales y configuraciones.

En contraste, una Feature describe una funcionalidad del sistema que agrupa varios escenarios. Corresponde a una o varias historias de usuario.

En el contexto de Gherkin, un Scenario detalla un caso específicos dentro de una Feature y cumple con los criterios de aceptación de las historias de usuario. Es, en esencia, un caso de prueba para una parte de la aplicación.

Cada historia de usuario describe un objetivo que el usuario quiere lograr, y dicho objetivo puede comprender varias situaciones o escenarios que necesitan ser probados. Por lo tanto, una historia de usuario no se restringe a un único caso de prueba; depende del nivel de detalle y de la manera en que se desglosen las funcionalidades dentro de una Feature.

ℹ️

Las historias de usuario responden a lo que el usuario final quiere lograr y por qué, mientras que las Features son más específicas y técnicas.

Continuando con el ejemplo de la gestión de tareas, así se definiría la historia de usuario:

  • Como usuario,
  • Quiero poder gestionar mis tareas,
  • Para organizar mejor mi trabajo diario.

Esta definición daría lugar a varios casos de prueba o Scenarios en Gherkin:

Feature: Gestión de tareas

  Scenario: Crear una nueva tarea
    Given El usuario está en la página de tareas
    When El usuario introduce el nombre de la tarea y hace clic en el botón "Crear"
    Then La nueva tarea debería aparecer en la lista de tareas

  Scenario: Completar una tarea existente
    Given El usuario está en la página de tareas
    And Hay una tarea existente llamada "Hacer una tortilla de patatas"
    When El usuario marca la tarea "Hacer una tortilla de patatas" como completada
    Then La tarea "Hacer una tortilla de patatas" debería aparecer como completada en la lista de tareas

  Scenario: Eliminar una tarea
    Given El usuario está en la página de tareas
    And Hay una tarea existente llamada "Hacer una tortilla de patatas"
    When El usuario hace clic en el icono de eliminar junto a la tarea "Hacer una tortilla de patatas"
    Then La tarea "Hacer una tortilla de patatas" debería desaparecer de la lista de tareas

Solo nos falta ver el Background, que son las precondiciones o antecedentes del escenario.

El papel del Product Owner

En el pasado, los equipos de QA y desarrollo establecían sus propios criterios de aceptación y escenarios de prueba en base a su interpretación de un resumen de la historia de usuario facilitada por un Product Owner. Esto a menudo resultaba en definiciones no alineadas entre los equipos y, por ende, las expectativas para aprobar una prueba variaban según la interpretación de los requisitos por cada equipo.

Para remediarlo, en los flujos de trabajo modernos, es el Product Owner quien define y proporciona los criterios de aceptación de forma clara y precisa, minimizando el riesgo de interpretaciones diferentes y la necesidad de repetir iteraciones de pruebas o desarrollo, lo que reduce significativamente los costos de producción. En base a ellos, los equipos de QA y desarrollo establecen los escenarios de prueba.

Por norma general, cuando el Product Owner planifica el desarrollo de una nueva funcionalidad, la discute con un Tech Lead y un QA Lead para asegurar que todos estén alineados sobre la definición de la funcionalidad y su posible impacto en otras áreas del sistema. Es en estas reuniones de seguimiento donde se discuten los escenarios de prueba y los criterios de aceptación para después proceder a su redacción.

En este contexto, Gherkin se presenta como un canal de comunicación altamente efectivo para simplificar esta tarea, teniendo en cuenta la participación de perfiles técnicos y no técnicos.

Veamos un ejemplo práctico sobre cómo el Product Owner y los equipos de QA y desarrollo colaboran en una misma historia de usuario:

  1. Se dispone de un caso de prueba proporcionado y revisado por el Product Owner, donde detalla el resumen de la historia de usuario sobre la que se va a trabajar.

    • Resumen:

      Como usuario quiero poder gestionar mis tareas para organizar mejor mi trabajo diario.

  2. El Product Owner plantea todos los escenarios posibles para validar la historia de usuario, asegurando así su cumplimiento total.

    • Escenario 1:

      Permitir al usuario crear una nueva tarea en el panel para poder gestionar su trabajo.

    • Escenario 2:

      Permitir al usuario completar una tarea existente en el panel para poder darla por finalizada.

    • Escenario 3:

      Permitir al usuario eliminar una tarea existente en el panel para poder despejarlo de aquellas que se han creado por error.

  3. El Product Owner establece los criterios de aceptación necesarios para la historia de usuario, de modo que el Tester tenga el input necesario para los escenarios de prueba a implementar y el desarrollador pueda crear las pruebas unitarias.

    • Criterios de aceptación:
    Feature: Gestión de tareas

 Scenario: Crear una nueva tarea
   Given El usuario está en la página de tareas
   When El usuario introduce el nombre de la tarea y hace clic en el botón "Crear"
   Then La nueva tarea debería aparecer en la lista de tareas

 Scenario: Completar una tarea existente
   Given El usuario está en la página de tareas
   And Hay una tarea existente llamada "Hacer una tortilla de patatas"
   When El usuario marca la tarea "Hacer una tortilla de patatas" como completada
   Then La tarea "Hacer una tortilla de patatas" debería aparecer como completada en la lista de tareas

 Scenario: Eliminar una tarea
   Given El usuario está en la página de tareas
   And Hay una tarea existente llamada "Hacer una tortilla de patatas"
   When El usuario hace clic en el icono de eliminar junto a la tarea "Hacer una tortilla de patatas"
   Then La tarea "Hacer una tortilla de patatas" debería desaparecer de la lista de tareas

  4. Los equipos de QA y desarrollo diseñan sus escenarios de prueba según los criterios de aceptación establecidos por el Product Owner.

    • Creación de una tarea:

      • Caso de prueba 1 (happy path):
      Validar que el usuario pueda crear una tarea al darle un nombre y pulsar el botón "Crear".
      • Caso de prueba 2:
      Validar que el usuario no pueda crear una tarea al pulsar el botón "Crear" sin haberle dado un nombre.

    • Otros escenarios de prueba…

      • Otros casos de prueba…

Según los escenarios establecidos por el Product Owner, los casos de prueba pueden responder o a un Happy Path.

Por ejemplo, si la historia de usuario define que se debe poder iniciar sesión, el Happy Path sería lograrlo con credenciales válidas. Por otro lado, el caso contrario, es decir, el no poder iniciar sesión con credenciales inválidas, no se clasificaría como Happy Path.

Tenemos que hablar de Cucumber

Hasta ahora, hemos visto cómo resolver los problemas de comunicación entre los diferentes participantes que trabajan en un proyecto de desarrollo de software utilizando la metodología BDD dentro del contexto de Gherkin. Llega el momento de ver cómo Cucumber puede eficienciar la labor de los ingenieros de QA.

Cucumber es una herramienta que permite ejecutar los archivos Gherkin, proporcionando una plataforma donde los escenarios definidos en lenguaje natural o común se convierten en pruebas automatizadas. Su principal ventaja es que los escenarios de prueba escritos en Gherkin son comprensibles por todos los miembros del equipo, incluidos los perfiles no técnicos.

Todo esto es muy prometedor, pero… ¿cómo trabaja Cucumber? Veámoslo paso a paso:

  1. El Product Owner trabaja conjuntamente con los equipos de desarrollo y calidad para definir los criterios de aceptación de las funcionalidades.
  2. Los ingenieros de QA escriben los escenarios en archivos .feature utilizando la sintaxis de Gherkin.
  3. Los desarrolladores implementan los pasos especificados en los escenarios con un lenguaje de programación que sea compatible con Cucumber, como Java o JavaScript.
  4. Cucumber procesa los escenarios, ejecutando el código correspondiente a cada paso y comprobando que los resultados sean los esperados.
  5. Tras la ejecución, Cucumber genera informes detallados del éxito o fracaso de cada escenario, lo que permite a los equipos detectar problemas.

Cucumber no solo facilita la escritura y ejecución de pruebas automatizadas, sino que también mejora la comunicación y colaboración dentro del equipo, asegurando que todos trabajen con una comprensión clara y compartida de los requisitos y funcionalidades del software.

Por si fuera poco, los archivos .feature funcionan como documentación activa. Esto implica que cada Scenario, aparte de ser comprensible, actúa como una documentación constantemente actualizada, dado que son pruebas que se llevan a cabo y se validan de manera continua.

Esto permite llevar a cabo los siguientes tipos de pruebas:

  • Pruebas de aceptación: Sirven para validar si un sistema cumple con los requisitos y expectativas del usuario final.
  • Pruebas de regresión: Aseguran que las funcionalidades existentes no se vean afectadas negativamente por los cambios en el código y que no se introduzcan nuevos errores.
  • Pruebas funcionales: Verifican el comportamiento y la funcionalidad específica del software, al margen de las expectativas del usuario final, como la capacidad de crear usuarios.
  • Pruebas de integración: Aseguran que los diferentes componentes del sistema funcionen correctamente en conjunto.
  • Pruebas de extremo a extremo (E2E): Se emplean para validar de forma exhaustiva el funcionamiento del sistema desde el comienzo hasta el final, incluyendo todas las interacciones entre los distintos componentes.

Además, el uso de Cucumber puede ser beneficioso para los equipos de desarrollo, ya que se integra de manera eficaz con varias herramientas de CI/CD, lo que facilita la automatización de pruebas dentro del propio proceso de desarrollo. Esto no solo ayuda a identificar errores antes de que el producto llegue a la fase de QA, sino que también ayuda a reducir tiempos y costos en el proyecto.

Recursos adicionales

Si este artículo te ha parecido interesante, te invito a visitar los enlaces brindados a lo largo del mismo, que sirven de complemento a los diversos términos y conceptos abordados.

Además, si estás interesado en experimentar por ti mismo, necesitarás conocer al menos las siguientes secciones de la documentación oficial de Cucumber:

Por último, si trabajas con Node.js, debes saber que hay un módulo de npm denominado Cucumber.js.

Glosario

  • BDD (Behavior Driven Development): Una metodología de desarrollo de software enfocada en el comportamiento esperado de la aplicación, que fomenta la colaboración entre desarrolladores, testers y perfiles no técnicos.
  • Cucumber: Una herramienta que facilita la ejecución de especificaciones escritas en Gherkin como pruebas automatizadas, facilitando la implementación de BDD. Beneficia a testers y a desarrolladores por igual.
  • Gherkin: Lenguaje utilizado en BDD que permite escribir especificaciones que describan los comportamientos esperados del sistema en un lenguaje natural. Ofrece las siguientes palabras clave:
    • Background: Palabra clave de Gherkin que permite indicar las precondiciones del escenario.
    • Feature: Palabra clave de Gherkin que representa una característica o funcionalidad del sistema.
    • Given: Palabra clave de Gherkin que representa el contexto de la situación (dado que).
    • Scenario: Palabra clave de Gherkin que hace referencia a la prueba en sí.
    • Then: Palabra clave de Gherkin que representa la aserción o resultado esperado después de realizar una acción.
    • When: Palabra clave de Gherkin que describe la acción principal que se realiza en el escenario.
  • Happy Path: El flujo correcto para completar un proceso sin que surjan problemas.