Behavior-Driven Development - Revision history

Mberne: /* Véase también */

2026-05-25T09:42:29Z

Véase también

← Older revision		Revision as of 11:42, 25 May 2026
Line 51:		Line 51:

	<div class="bok-tags">		<div class="bok-tags">
	[[TDD]] [[Criterios de aceptación]] [[Definición de hecho]] [[Spec-Driven Development]] [[Agilidad técnica]] [[Historia de usuario]] [[Extreme programming]]		[[TDD]] [[Criterios de aceptación]] [[Definición de hecho]] [[Spec-Driven Development (SDD)]] [[Agilidad técnica]] [[Historia de usuario]] [[Extreme programming]]
	</div>		</div>

Mberne at 07:51, 20 May 2026

2026-05-20T07:51:53Z

← Older revision		Revision as of 09:51, 20 May 2026
Line 40:		Line 40:
	'''Usar BDD solo como herramienta técnica de testing, ignorando el lenguaje compartido.''' El valor de BDD no está en Cucumber o Gherkin: está en que las personas de negocio y las técnicas colaboran para definir el comportamiento antes de construirlo. Si los escenarios Given/When/Then los escribe solo el equipo técnico sin participación del propietario del producto o los usuarios, BDD se convierte en TDD con sintaxis diferente.		'''Usar BDD solo como herramienta técnica de testing, ignorando el lenguaje compartido.''' El valor de BDD no está en Cucumber o Gherkin: está en que las personas de negocio y las técnicas colaboran para definir el comportamiento antes de construirlo. Si los escenarios Given/When/Then los escribe solo el equipo técnico sin participación del propietario del producto o los usuarios, BDD se convierte en TDD con sintaxis diferente.
	</div>		</div>
			== Recursos ==
			<div class="bok-recurso">
			📄 [https://scrummanager.com/files/scrumenequiposconia.pdf '''Scrum Master en equipos con IA v.1.0''']<span class="detalle">Descarga gratuita · Scrum Manager</span>
			</div>
	== Referencias ==		== Referencias ==

Mberne: /* Beneficios */

2026-05-20T07:50:41Z

Beneficios

← Older revision		Revision as of 09:50, 20 May 2026
Line 25:		Line 25:
	* '''Documentación viva:''' los escenarios son a la vez especificación y prueba: cuando el código cambia, las pruebas detectan si el comportamiento esperado también ha cambiado.		* '''Documentación viva:''' los escenarios son a la vez especificación y prueba: cuando el código cambia, las pruebas detectan si el comportamiento esperado también ha cambiado.
	* '''Cobertura orientada al valor:''' las pruebas BDD se centran en lo que importa al usuario, no en los detalles de implementación técnica.		* '''Cobertura orientada al valor:''' las pruebas BDD se centran en lo que importa al usuario, no en los detalles de implementación técnica.
	* '''Facilita el [[Spec-Driven Development\|SDD]]:''' los escenarios Given/When/Then son una forma de spec legible tanto por personas como por agentes de IA.		* '''Facilita el [[Spec-Driven Development (SDD)\|SDD]]:''' los escenarios Given/When/Then son una forma de spec legible tanto por personas como por agentes de IA.

	== BDD y la IA ==		== BDD y la IA ==

Mberne: /* El formato Given/When/Then */

2026-05-20T07:50:19Z

El formato Given/When/Then

← Older revision		Revision as of 09:50, 20 May 2026
Line 13:		Line 13:

	'''Ejemplo:'''		'''Ejemplo:'''
	~~{{quote\|~~		<blockquote><small>
	'''Given''' que el usuario ha iniciado sesión y tiene saldo suficiente,<br>		'''Given''' que el usuario ha iniciado sesión y tiene saldo suficiente,<br>
	'''When''' transfiere 100€ a otra cuenta,<br>		'''When''' transfiere 100€ a otra cuenta,<br>
	'''Then''' su saldo se reduce en 100€ y la transacción aparece en el historial.		'''Then''' su saldo se reduce en 100€ y la transacción aparece en el historial.</small></blockquote>
	}}

	Este escenario puede ser escrito por el propietario del producto o el analista de negocio, revisado por el equipo técnico y ejecutado automáticamente por una herramienta de BDD como Cucumber o Behave.		Este escenario puede ser escrito por el propietario del producto o el analista de negocio, revisado por el equipo técnico y ejecutado automáticamente por una herramienta de BDD como Cucumber o Behave.

Mberne: Created page with "{{Meta-bok|min=4}} El '''Behavior-Driven Development''' (BDD, desarrollo guiado por comportamiento) es una extensión de Test-Driven Development que traslada el foco de las pruebas técnicas al comportamiento esperado del sistema desde la perspectiva del usuario de negocio. Las pruebas se escriben en lenguaje natural estructurado —comprensible para personas no técnicas— antes de que el código exista, siguiendo el formato '''Given/When/Then''' (dado/cuando/e..."

2026-05-20T07:49:44Z

Created page with "{{Meta-bok|min=4}} El '''Behavior-Driven Development''' (BDD, desarrollo guiado por comportamiento) es una extensión de Test-Driven Development que traslada el foco de las pruebas técnicas al comportamiento esperado del sistema desde la perspectiva del usuario de negocio. Las pruebas se escriben en lenguaje natural estructurado —comprensible para personas no técnicas— antes de que el código exista, siguiendo el formato '''Given/When/Then''' (dado/cuando/e..."

New page

{{Meta-bok|min=4}}
El '''Behavior-Driven Development''' (BDD, desarrollo guiado por comportamiento) es una extensión de [[TDD|Test-Driven Development]] que traslada el foco de las pruebas técnicas al comportamiento esperado del sistema desde la perspectiva del usuario de negocio. Las pruebas se escriben en lenguaje natural estructurado —comprensible para personas no técnicas— antes de que el código exista, siguiendo el formato '''Given/When/Then''' (dado/cuando/entonces).

Dan North acuñó el término en 2003 como evolución de TDD, observando que el principal problema de TDD no era técnico sino de comunicación: los desarrolladores no sabían qué cosas probar, y los tests técnicos no eran legibles para los stakeholders de negocio.

== El formato Given/When/Then ==

BDD estructura cada escenario de comportamiento en tres cláusulas:

* '''Given''' (dado): el estado inicial del sistema o el contexto en el que ocurre la acción.
* '''When''' (cuando): la acción que realiza el usuario o el sistema.
* '''Then''' (entonces): el resultado esperado que puede verificarse.

'''Ejemplo:'''
{{quote|
'''Given''' que el usuario ha iniciado sesión y tiene saldo suficiente,<br>
'''When''' transfiere 100€ a otra cuenta,<br>
'''Then''' su saldo se reduce en 100€ y la transacción aparece en el historial.
}}

Este escenario puede ser escrito por el propietario del producto o el analista de negocio, revisado por el equipo técnico y ejecutado automáticamente por una herramienta de BDD como Cucumber o Behave.

== Beneficios ==

* '''Lenguaje compartido:''' los escenarios BDD son comprensibles tanto para stakeholders de negocio como para desarrolladores, reduciendo malentendidos en los [[Criterios de aceptación|criterios de aceptación]].
* '''Documentación viva:''' los escenarios son a la vez especificación y prueba: cuando el código cambia, las pruebas detectan si el comportamiento esperado también ha cambiado.
* '''Cobertura orientada al valor:''' las pruebas BDD se centran en lo que importa al usuario, no en los detalles de implementación técnica.
* '''Facilita el [[Spec-Driven Development|SDD]]:''' los escenarios Given/When/Then son una forma de spec legible tanto por personas como por agentes de IA.

== BDD y la IA ==

BDD tiene una sinergia directa con el desarrollo asistido por IA:

* Los escenarios Given/When/Then pueden usarse como especificación para que un agente de IA genere el código que los satisface: la prueba precede al código, tal como prescribe [[TDD]].
* Los escenarios escritos por el equipo en lenguaje natural son más resistentes a las [[Alucinación de IA|alucinaciones]] que las specs puramente técnicas, porque están anclados en comportamientos de usuario verificables.
* Las herramientas de IA pueden ayudar a transformar [[Historia de usuario|historias de usuario]] en escenarios BDD, aunque la revisión humana de la cobertura de casos extremos sigue siendo imprescindible.

== Error frecuente ==

<div class="bok-aviso">
'''Usar BDD solo como herramienta técnica de testing, ignorando el lenguaje compartido.''' El valor de BDD no está en Cucumber o Gherkin: está en que las personas de negocio y las técnicas colaboran para definir el comportamiento antes de construirlo. Si los escenarios Given/When/Then los escribe solo el equipo técnico sin participación del propietario del producto o los usuarios, BDD se convierte en TDD con sintaxis diferente.
</div>

== Referencias ==

* North, Dan. (2006). "Introducing BDD". [https://dannorth.net/introducing-bdd/ dannorth.net].

== Véase también ==

<div class="bok-tags">
[[TDD]] [[Criterios de aceptación]] [[Definición de hecho]] [[Spec-Driven Development]] [[Agilidad técnica]] [[Historia de usuario]] [[Extreme programming]]
</div>

<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>

[[Category:Glosario de términos]]
[[Category:Prácticas técnicas]]
[[Category:Prácticas ágiles]]