BDD es uno de esos términos que aparece constantemente en las ofertas de trabajo y en las entrevistas de QA sin que nadie lo explique de forma clara y sencilla. En este artículo te lo explico desde cero con ejemplos reales para que la próxima vez que lo veas sepas exactamente de qué se trata.
Qué es BDD
BDD son las siglas de Behaviour Driven Development, que en español significa Desarrollo Guiado por Comportamiento. Es una metodología de desarrollo de software que extiende el concepto de TDD (Test Driven Development) para incluir no solo a los desarrolladores sino a todo el equipo — producto, negocio, QA y desarrollo trabajando juntos.
La idea central es muy simple: antes de escribir código, todo el equipo acuerda cómo debe comportarse la aplicación escribiendo escenarios en un lenguaje que todos puedan entender — no solo los técnicos.
La diferencia entre BDD y TDD
TDD (Test Driven Development) es una práctica técnica donde los desarrolladores escriben tests antes de escribir el código. Los tests están escritos en código y solo los desarrolladores los entienden y mantienen.
BDD va un paso más allá. Los escenarios de comportamiento se escriben en lenguaje natural estructurado — casi como texto normal — de forma que tanto el equipo técnico como el de negocio pueden leerlos, entenderlos y validarlos.
La diferencia clave no es técnica sino de comunicación. BDD convierte los requisitos del negocio directamente en tests automatizados, eliminando la brecha de interpretación entre lo que el negocio quiere y lo que el equipo técnico implementa.
El lenguaje Gherkin
Los escenarios BDD se escriben en un lenguaje llamado Gherkin. Tiene una estructura muy reconocible basada en palabras clave en inglés — o en español si usas la configuración correcta.
La estructura básica de un escenario Gherkin es esta:
gherkin
Feature: Login de usuario
Scenario: Login correcto con credenciales válidas
Given que el usuario está en la página de login
When introduce su email y contraseña correctos
And hace clic en el botón de login
Then debería ver el dashboard
And debería ver su nombre en la barra de navegación
Scenario: Login fallido con contraseña incorrecta
Given que el usuario está en la página de login
When introduce su email correcto y una contraseña incorrecta
And hace clic en el botón de login
Then debería ver un mensaje de error
And debería seguir en la página de loginLas palabras clave son:
Feature — describe la funcionalidad que se está probando.
Scenario — describe un caso concreto de uso de esa funcionalidad.
Given — el estado inicial antes de que ocurra algo. El contexto del escenario.
When — la acción que ejecuta el usuario o el sistema.
Then — el resultado esperado después de la acción.
And — para encadenar múltiples pasos del mismo tipo sin repetir Given, When o Then.
Por qué BDD mejora la comunicación del equipo
El mayor valor de BDD no es técnico — es la conversación que provoca antes de escribir código.
Cuando el equipo se sienta a escribir los escenarios Gherkin juntos, afloran preguntas importantes que de otro modo nadie haría. ¿Qué pasa si el usuario introduce el email sin arroba? ¿Cuántos intentos fallidos de login permitimos antes de bloquear la cuenta? ¿El mensaje de error debe ser genérico o específico?
Estas conversaciones ocurren antes de que el desarrollador escriba una sola línea de código, cuando cambiar de dirección es barato. Sin BDD, estas preguntas suelen aparecer durante el testing o peor, en producción.
Herramientas para BDD en Python
La herramienta más popular para implementar BDD en Python es pytest-bdd, que permite escribir los escenarios en archivos Gherkin y conectarlos con código Python.
Primero instalas el plugin:
bash
pip install pytest-bddLuego creas un archivo .feature con los escenarios:
gherkin
# tests/features/login.feature
Feature: Login de usuario
Scenario: Login correcto
Given el usuario está en la página de login
When introduce credenciales válidas
Then ve el dashboardY después escribes los step definitions en Python — las funciones que implementan cada paso:
python
# tests/test_login.py
from pytest_bdd import scenarios, given, when, then
from playwright.sync_api import Page
scenarios("features/login.feature")
@given("el usuario está en la página de login")
def pagina_login(page: Page):
page.goto("https://miweb.com/login")
@when("introduce credenciales válidas")
def introduce_credenciales(page: Page):
page.fill("#email", "usuario@test.com")
page.fill("#password", "password123")
page.click("#btn-login")
@then("ve el dashboard")
def ve_dashboard(page: Page):
assert "dashboard" in page.urlCuándo tiene sentido usar BDD
BDD no es la solución para todos los proyectos. Tiene más sentido en estas situaciones concretas.
Cuando hay una brecha de comunicación real entre el equipo técnico y el de negocio. Si los desarrolladores y product managers no hablan el mismo idioma al definir requisitos, BDD puede cerrar esa brecha.
Cuando el dominio de negocio es complejo. En aplicaciones con lógica de negocio compleja — seguros, banca, e-commerce avanzado — los escenarios Gherkin ayudan a documentar y verificar esa lógica de forma comprensible para todos.
Cuando la documentación viva es importante. Los escenarios Gherkin actúan como documentación siempre actualizada — si los tests pasan, la documentación es correcta.
Cuándo BDD puede no ser la mejor opción
En equipos pequeños donde todos hablan el mismo idioma técnico, BDD puede añadir complejidad sin aportar valor real. El overhead de mantener archivos Gherkin y step definitions puede no estar justificado si el equipo es todo técnico y se comunica bien.
En proyectos muy técnicos sin participación del negocio en el día a día, los beneficios de comunicación de BDD son menores y el coste de mantenimiento puede superar el beneficio.
BDD en entrevistas QA
BDD aparece frecuentemente en entrevistas de QA, especialmente en empresas que trabajan con metodologías ágiles. Las preguntas más habituales son sobre la diferencia entre BDD y TDD, qué es Gherkin y para qué sirve, y cómo se conectan los escenarios con el código de automatización.
Con lo que has leído en este artículo tienes suficiente para responder con criterio en cualquier entrevista. Si quieres saber más sobre cómo funciona el QA en equipos ágiles puedes leer cómo funciona el QA en Scrum o qué es el testing shift-left.
Y si necesitas ayuda para implementar una estrategia de testing en tu proyecto puedes ver mis servicios en fatimaqa.com.