Pruebas BDD: el desarrollo guiado por comportamiento explicado

Las pruebas BDD (desarrollo guiado por comportamiento, del inglés behavior-driven development) son una forma de escribir escenarios de prueba en un lenguaje claro y estructurado, con el formato Given/When/Then, para que desarrolladores, ingenieros de QA y responsables de negocio puedan leer y acordar la misma especificación antes de que una funcionalidad salga a producción. Después, herramientas como Cucumber ejecutan esos escenarios como pruebas automatizadas sobre el producto real.

Saber si su equipo necesita pruebas BDD se reduce a una pregunta: ¿debería poder leer sus pruebas alguien que nunca ha escrito código? Con BDD, un product manager puede leer «Dado un usuario con sesión iniciada, Cuando añade un artículo al carrito, Entonces el total del carrito se actualiza» y saber exactamente qué se comprueba, y detectar lo que falta. Esa legibilidad tiene un coste. Cada línea en lenguaje natural necesita código detrás, y alguien tiene que mantener ambos sincronizados a medida que el producto cambia.

BDD es hoy una práctica habitual en los equipos de pruebas. En la encuesta State of Testing 2024 de PractiTest y Tea-time with Testers, la adopción de BDD pasó del 19% de los encuestados en 2022 al 26% en 2024, ligeramente por delante del desarrollo guiado por pruebas (TDD), con un 23%, y el 92% de los encuestados trabajaba con modelos Agile o similares.

Esta guía explica la estructura Given/When/Then, cómo se integran las herramientas BDD en las pruebas automatizadas, en qué se diferencia BDD de TDD y cuándo compensa el esfuerzo adicional.

La estructura Given/When/Then en BDD

Todo escenario BDD sigue la misma forma en tres partes:

• Given (Dado) fija el estado inicial: quién es el usuario, qué datos existen, en qué pantalla está.
• When (Cuando) describe la única acción o evento que se prueba.
• Then (Entonces) indica el resultado esperado que le importa al negocio.

And (Y) y But (Pero) amplían cualquiera de las tres cuando un paso necesita más de una línea. Esta sintaxis se llama Gherkin y vive en archivos de texto plano .feature que cualquier persona del equipo puede abrir. La referencia de Gherkin recoge el conjunto completo de palabras clave, traducidas a más de 70 idiomas: con la línea # language: es al principio del archivo, su equipo escribe los escenarios en español.

Así queda el ejemplo del carrito escrito como un escenario real:

# language: es
Característica: Carrito de compra

  Escenario: Añadir un artículo actualiza el total del carrito
    Dado un usuario con sesión iniciada y el carrito vacío
    Cuando añade un cuaderno de 25 € al carrito
    Entonces el carrito muestra 1 artículo
    Y el total del carrito es 25,00 €

Un product owner puede confirmar que este es el comportamiento previsto, un desarrollador puede construir a partir de él y un ingeniero de QA puede automatizarlo, todo desde el mismo texto.

La habilidad está en describir comportamientos en lugar de clics. «Cuando hace clic en el botón con id add-to-cart» ata el escenario a la interfaz actual y se rompe con el siguiente rediseño. «Cuando añade un cuaderno de 25 € al carrito» sobrevive a un rediseño y sigue leyéndose como una regla de negocio. Los Scenario Outlines (esquemas del escenario) van más allá: un escenario más una tabla de valores de ejemplo cubre diez códigos de descuento o cinco roles de usuario sin diez copias de los mismos pasos.

Esa fuente de verdad única y legible ataca un punto débil habitual. La misma encuesta State of Testing 2024 reveló que en el 60% de las organizaciones los casos de prueba no están bien escritos ni mantenidos, y la duplicación y el mal mantenimiento son las causas habituales.

Cómo funcionan realmente las herramientas de pruebas BDD

Las herramientas BDD se sitúan sobre su framework de automatización de pruebas y le delegan el trabajo real. Los escenarios describen lo que debe hacer el producto, y el framework que hay debajo ejecuta cada paso contra el navegador, la aplicación móvil o la API. Los equipos que ya tienen una suite automatizada suelen poder añadir una capa BDD de forma gradual, un flujo de negocio cada vez, y conservar las pruebas que ya tienen. Una configuración BDD tiene tres capas:

Cucumber es la herramienta BDD más utilizada, con implementaciones para Java, JavaScript, Ruby y otros lenguajes. Behave cubre Python, Reqnroll (el sucesor de SpecFlow) cubre .NET y CodeceptJS admite escenarios Gherkin para equipos de JavaScript. Para el trabajo con API, Karate usa directamente una sintaxis al estilo Gherkin, uno de los motivos por los que suele aparecer cuando los equipos comparan Karate con REST-Assured.

Cuando Cucumber ejecuta Cuando añade un cuaderno de 25 € al carrito, busca la definición de paso correspondiente, que a su vez llama a Playwright o Selenium para realizar la acción. Esta estructura en capas tiene dos consecuencias prácticas:

• BDD hereda la calidad del framework que tiene debajo. Los localizadores inestables o los entornos de prueba lentos siguen siendo inestables y lentos detrás de un escenario legible.
• Quienes no programan pueden contribuir al diseño de las pruebas. En la encuesta de 2024, el 42% de los encuestados afirmó no sentirse cómodo escribiendo scripts de automatización. Los escenarios en lenguaje natural permiten que esos testers, y las personas de producto, definan qué se automatiza mientras los ingenieros se ocupan del código de los pasos.

Los escenarios BDD funcionan como una interfaz legible para las pruebas funcionales automatizadas: comprueban de principio a fin que las funcionalidades se comportan como espera el negocio.

BDD vs TDD: en qué se diferencian

BDD nació del desarrollo guiado por pruebas (TDD) a mediados de la década de 2000, cuando Dan North empezó a describir las pruebas como comportamientos para que TDD fuera más fácil de enseñar y de comentar. Hoy ambos resuelven problemas distintos.

En el desarrollo guiado por pruebas, un desarrollador escribe una pequeña prueba unitaria que falla, escribe el código justo para que pase y después refactoriza. Las pruebas viven en el código y se dirigen a otros desarrolladores. BDD lleva la conversación un nivel más arriba, al comportamiento que reconocería un cliente o un responsable de negocio.

Muchos equipos usan ambos: TDD para la lógica interna y BDD para los pocos flujos de negocio que los responsables tienen que aprobar. El crecimiento constante de ambas prácticas apunta a que gana terreno el enfoque de «all team testing», en el que desarrolladores, QA y producto comparten la responsabilidad de la calidad en los equipos de I+D.

Cuándo compensa el esfuerzo de las pruebas BDD

BDD añade trabajo real sobre la automatización. Alguien tiene que organizar sesiones breves de escenarios con producto, desarrollo y QA (a menudo llamadas reuniones de los «three amigos»), mantener un vocabulario compartido de pasos para que los escenarios no deriven en casi duplicados y mantener las definiciones de pasos a medida que cambia la interfaz. Si nadie fuera de ingeniería lee los escenarios, ese trabajo no aporta nada.

BDD suele compensar cuando:

• Las reglas de negocio son complejas o generan discusión. Precios, requisitos de elegibilidad, permisos y lógica de reembolsos son el origen de los errores del tipo «eso no es lo que queríamos decir».
• Personas no técnicas aprueban el comportamiento. Los product owners, los responsables de cumplimiento o el equipo de aceptación de un cliente pueden revisar los escenarios directamente.
• Los ingenieros de QA manual necesitan contribuir a la automatización sin convertirse en programadores a tiempo completo.
• Necesita documentación viva. Los escenarios que se ejecutan en CI/CD muestran lo que hace el producto hoy, lo que ayuda en la incorporación de personas nuevas y en las auditorías.

Suele ser una mala elección cuando:

• La suite es solo para desarrolladores: pruebas unitarias, bibliotecas internas, código de infraestructura.
• El producto es un prototipo que cambia rápido y su comportamiento varía cada semana.
• Todavía no hay una base de automatización estable. Primero arregle el framework y después añada la capa legible.

El argumento de fondo tiene que ver con la comunicación. En la encuesta de PractiTest de 2025, las habilidades de comunicación pasaron del 59% en 2024 al 75% en 2025 y se convirtieron en la principal habilidad que los testers dicen necesitar, algo que los autores relacionan con que los testers trabajan en estrecha colaboración con equipos multifuncionales Agile y DevOps. BDD convierte esa colaboración en un artefacto concreto, y un malentendido detectado en la revisión de un escenario cuesta mucho menos que uno detectado en producción. Esa curva de costes es la misma razón que explica la importancia del QA desde las primeras fases del desarrollo.

Cómo usa QAwerk BDD en un proyecto real

En Evolv, una plataforma de optimización del crecimiento digital basada en IA, el equipo del cliente ya usaba CucumberStudio como herramienta de colaboración BDD para casos de prueba manuales. La automatización de QAwerk funcionaba con CodeceptJS y Puppeteer. En lugar de obligar a que una herramienta sustituyera a la otra, nuestros ingenieros crearon un pequeño generador que produce el código de enlace entre CucumberStudio y el proyecto de CodeceptJS en ambas direcciones, con los escenarios ejecutándose en el pipeline de CI/CD.

El resultado hizo la automatización accesible para todo el equipo de QA:

• Los ingenieros de QA manual crean escenarios nuevos a partir de una biblioteca de más de 100 Action Words, con una incorporación mínima.
• Cuando cambia un localizador o el orden de los pasos, lo corrigen editando los pasos en CucumberStudio en lugar de subir cambios de código.
• Los pasos de bajo nivel se refactorizan poco a poco en frases Gherkin de nivel de negocio que el equipo de Evolv puede leer.

Funcionó porque ambos equipos trabajaron como uno solo. El equipo de Evolv preparaba documentación de depuración mientras nosotros escribíamos casos de prueba, y nos incorporamos en la fase en la que estaba la plataforma en cada momento, desde la antigua aplicación web hasta el nuevo producto. Si no tiene claro si BDD encaja en su proyecto, cuéntenos qué está construyendo y le daremos una respuesta directa.

¿Son las pruebas BDD adecuadas para su equipo?

BDD justifica su esfuerzo cuando cierra una brecha de comunicación real entre quienes construyen el software y quienes deciden qué debe hacer. Resuelve un problema distinto al de TDD, y muchos equipos sólidos usan uno, el otro o ambos.

Los ingenieros de automatización de QAwerk pueden añadir Cucumber u otra herramienta BDD sobre el framework que ya se adapta a su stack, para que obtenga escenarios legibles sin reconstruir su suite de pruebas. Si prefiere un equipo de pruebas dedicado que escriba escenarios con sus product owners y los mantenga en ejecución en CI, así es como solemos empezar.

Preguntas frecuentes

Descubra cómo probamos una solución de crecimiento digital con IA y aumentamos un 50% la velocidad de las pruebas de regresión

Por favor ingrese su correo electrónico comercial no es un correo electrónico comercial

Obtener Caso de Estudio