BDD y Gherkin en QA: qué son y cuándo usarlos

Si has mirado ofertas de QA con algo de automatización, seguro que te has cruzado con "BDD" en los requisitos. Y si has buscado qué es, seguro que te has encontrado tres palabras mezcladas sin que nadie te explique bien la diferencia: BDD, Gherkin y Cucumber.

No son sinónimos. BDD es una práctica de trabajo, Gherkin es un idioma para escribir escenarios y Cucumber es solo una de las herramientas que ejecuta ese idioma como test automatizado. Confundir los tres es el motivo por el que tanta gente cree que "hacer BDD" es simplemente escribir "Given, When, Then" delante de un test que de todas formas ya iban a escribir.

Aquí vas a ver la diferencia real entre los tres, cómo se escribe un escenario en Gherkin de verdad, cómo se conecta con el código que lo ejecuta, y cuándo esta práctica compensa el esfuerzo y cuándo es puro teatro documental.

Tres palabras, tres cosas distintas

Antes de escribir una sola línea de Gherkin conviene separar los tres conceptos, porque cada uno resuelve un problema distinto.

El error habitual, y honestamente el más comprensible, es usar Gherkin sin hacer BDD de verdad: un solo QA escribe los escenarios, nadie de negocio los revisa nunca, y el archivo .feature termina siendo solo una forma más rara de escribir el mismo test que ya se iba a automatizar. Eso no es malo en sí, pero tampoco es BDD: es sintaxis Gherkin sobre un test tradicional.

Cómo se escribe un escenario en Gherkin

Un archivo Gherkin (extensión .feature) describe un comportamiento en tres bloques: el contexto de partida (Given), la acción que lo dispara (When) y el resultado esperado (Then). And y But encadenan pasos del mismo tipo sin repetir la palabra clave.

Feature: Inicio de sesión
  Como usuario registrado
  quiero iniciar sesión con mis credenciales
  para acceder a mi cuenta

  Scenario: Login con credenciales válidas
    Given que estoy en la página de login
    When introduzco un email y una contraseña válidos
    And pulso el botón "Entrar"
    Then accedo a mi panel de usuario

Cada línea del Scenario es un paso. Lo importante no es la palabra clave que lo empieza, sino el orden lógico: primero el contexto, luego la acción, luego la comprobación. Gherkin ni siquiera obliga a usar el verbo correcto en cada paso, es solo una convención para que el escenario se lea como una frase natural.

De Gherkin a test automatizado: los step definitions

Un archivo .feature por sí solo no ejecuta nada. Necesita un step definition: una función de código conectada a cada línea del escenario mediante un texto que hace de patrón. Con pytest-bdd, la librería que conecta Gherkin con pytest en Python, cada paso se define así:

from pytest_bdd import scenarios, given, when, then

scenarios("login.feature")

@given("que estoy en la página de login")
def ir_a_login(page):
    page.goto("https://miapp.com/login")

@when("introduzco un email y una contraseña válidos")
def rellenar_credenciales(page):
    page.fill("#email", "usuario@test.com")
    page.fill("#password", "Clave123")

@when('pulso el botón "Entrar"')
def pulsar_entrar(page):
    page.click("text=Entrar")

@then("accedo a mi panel de usuario")
def verificar_panel(page):
    assert page.url.endswith("/panel")

El texto entre comillas de cada decorador tiene que coincidir, palabra por palabra, con la línea del .feature. Si cambias una coma en el escenario y no en el step definition, el test falla con un error de "step no encontrado", no con un fallo del comportamiento real. Es la fricción más habitual al empezar con BDD, y desaparece con la práctica.

Scenario Outline: el mismo escenario, muchos datos

Cuando el mismo comportamiento hay que probarlo con distintos datos de entrada (justo lo que piden la partición de equivalencia y los valores límite, ver cómo escribir casos de prueba en QA), Gherkin tiene una construcción para no repetir el escenario entero: Scenario Outline con una tabla Examples.

Scenario Outline: Login con credenciales inválidas
    Given que estoy en la página de login
    When introduzco el email "<email>" y la contraseña "<password>"
    Then veo el mensaje de error "<mensaje>"

    Examples:
      | email             | password | mensaje                             |
      | vacio@test.com    |          | La contraseña es obligatoria        |
      | noesunemail       | Clave123 | El email no tiene un formato válido |
      | usuario@test.com  | mal123   | Usuario o contraseña incorrectos    |

Cada fila de la tabla ejecuta el escenario completo una vez, sustituyendo cada marcador por el valor de esa fila. El step definition no cambia: solo recibe los valores como parámetros. Es la misma idea que @pytest.mark.parametrize en pytest normal, aplicada a Gherkin.

Qué herramientas implementan BDD además de Cucumber

Cucumber fue el primero y sigue siendo el más conocido, pero no es la única forma de ejecutar Gherkin. La elección depende sobre todo del lenguaje que ya usa tu equipo, no de cuál sea "mejor" en abstracto.

No hay que dominar las cinco. Basta con saber que el concepto (Gherkin desacoplado del código que lo ejecuta) es el mismo en todas, y que la herramienta concreta se elige por el stack del equipo, no al revés.

Cuándo BDD compensa y cuándo se convierte en burocracia

Aquí toca ser honesto, porque BDD tiene fama de solución universal y no lo es. Funciona muy bien en un escenario concreto y se convierte en una capa extra de mantenimiento en otro.

Si tu equipo no tiene a nadie de negocio dispuesto a sentarse a escribir o revisar escenarios, Gherkin sigue siendo útil como formato legible, pero la parte que de verdad da valor a BDD (la colaboración antes de programar) no está pasando. En ese caso, unos tests bien escritos con Playwright o pytest sin la capa de Gherkin encima suelen ser más rápidos de mantener.

¿Piden BDD en las ofertas de QA en España?

La respuesta honesta, con datos propios: menos de lo que su presencia en los cursos y en LinkedIn sugiere.

Eso no significa que sea inútil aprenderlo, significa que no es una prioridad para conseguir tu primera oferta. Si vienes de automatización básica y ya dominas Playwright, Cypress o pytest, BDD es una capa que puedes añadir después, cuando el equipo en el que trabajes de verdad lo pida (normalmente en proyectos grandes con producto y negocio muy involucrados, más que en startups pequeñas).

Como con toda práctica que suena bien en el papel, el criterio importa más que la etiqueta: escribir Gherkin no te hace mejor QA si nadie más en el equipo lo usa para lo que fue pensado. Dominar por qué se prueba algo, ver las técnicas de diseño de casos de prueba, pesa más en una entrevista que saber la sintaxis exacta de Scenario Outline.