Estás en lo correcto. BDD no elimina los problemas con la ambigüedad del lenguaje, en absoluto. Como otros señalaron, los fragmentos que se traducen deben coincidir definiéndolos adecuadamente, pero esto tampoco resuelve el problema de ambigüedad subyacente.
Ahora, ¿por qué vale la pena BDD a pesar de no resolver este problema? Hay algunas razones y esta lista ciertamente no está completa.
La ambigüedad no ha sido resuelta
Esta no es una razón a favor de BDD ni en contra de ella. Pero cuando lo contrasta con otros enfoques, como historias de usuarios o requisitos, todos los enfoques de desarrollo de SW sufren de ambigüedad en el lenguaje, ya que todos comienzan de una forma u otra con una formulación de lenguaje natural.
Técnicamente, el problema de la ambigüedad del lenguaje se ha resuelto con lenguajes artificiales como el lojban , pero, de nuevo, es muy probable que su cliente y los desarrolladores no conozcan ese idioma.
Lengua ubicua
BDD va de la mano con la idea de un lenguaje ubicuo. Ser capaz de especificar escenarios junto con todos los clientes, evaluadores y desarrolladores, solo le da a BDD una ventaja sobre otros enfoques.
Considere un ingeniero de requisitos tradicional escribiendo todos los requisitos. Una vez que, como probador o cliente, obtenga ese documento de 300 páginas lleno de requisitos para revisar, tendrá muchos más problemas apremiantes que la terminología que se utilizó allí.
Las historias de usuarios mejoran un poco en ese frente, ya que también incluyen a todos los interesados en su creación. En términos del lenguaje ubicuo, no diría que BDD o las historias de los usuarios son mejores, aunque difieren significativamente en el siguiente punto.
Testabilidad
Un aspecto importante de BDD es que sus especificaciones son realmente ejecutables (a través de Cucumber o similares). Ni los requisitos ni las historias de los usuarios ofrecen esta característica. Para mí personalmente, ese es el principal punto de venta para BDD.
Compare eso con los requisitos tradicionales: hemos estado diciendo a los ingenieros de requisitos durante años que sus requisitos deben ser comprobables. Sin embargo, cada proyecto ve un caso en el que los evaluadores se dan cuenta de que no tienen idea de cómo probar un determinado requisito.
Las historias de los usuarios, si se hacen correctamente, incluyen evaluadores en su etapa inicial de creación para asegurarse de eso. Desafortunadamente, este es un caso de teoría que choca con el mundo real, donde he visto numerosas historias que ningún probador ha visto antes.
BDD, por otro lado, le proporciona automáticamente un escenario de prueba ejecutable. No hay excusas ni formas de evitarlo (bueno, a menos que ignore por completo las capas de automatización y simplemente escriba los escenarios para la poesía elegante).
En términos más generales, Test First es un principio que ha sido muy gratificante en todas las etapas del desarrollo de software y BDD es su aplicación en la capa más externa del desarrollo (en comparación con TDF, por ejemplo, en el nivel de la unidad).
Resumen
En resumen, BDD no lo libera de los problemas de la ambigüedad del lenguaje natural. Sin embargo, lo ayuda a abordar ese problema a través de dos puntos importantes: centrarse en un lenguaje ubicuo para reducir las ambigüedades (¡no las eliminará por completo, pero ayuda mucho!) Y al obligarlo a escribir ejecutable especificaciones. El último punto está ayudando a abordar los problemas de ambigüedad principalmente porque ese es el punto donde las ambigüedades comienzan a aparecer como problemas de otra manera.