Você está certo. O BDD não elimina problemas com a ambiguidade da linguagem - nem um pouco. Como outros apontaram, os trechos traduzidos precisam ser correspondidos definindo-os adequadamente, mas isso também não trata do problema de ambiguidade subjacente.
Agora, por que o BDD realmente vale a pena, apesar de não resolver esse problema? Existem alguns motivos e esta lista certamente não está completa.
A ambiguidade não foi resolvida
Esta não é uma razão a favor do BDD nem contra ela. Mas quando você o compara a outras abordagens, como histórias de usuário ou requisitos, todas as abordagens de desenvolvimento de SW sofrem de ambiguidade de linguagem, pois todas começam de uma maneira ou de outra com uma formulação de linguagem natural.
Tecnicamente, o problema da ambiguidade de linguagem foi resolvido com linguagens artificiais como o lojban , mas, novamente, é provável que seu cliente e desenvolvedores não conheçam essa linguagem.
Linguagem onipresente
O BDD anda de mãos dadas com a idéia de uma linguagem onipresente. Ser capaz de especificar cenários em conjunto com todos os clientes, testadores e desenvolvedores, apenas dá ao BDD uma vantagem sobre outras abordagens.
Considere um engenheiro de requisitos tradicional anotando todos os requisitos. Depois que você, como testador ou cliente, obtiver o documento de 300 páginas cheio de requisitos para revisão, você terá muito mais problemas prementes do que a terminologia usada lá.
As histórias de usuários se saem um pouco melhor nessa área, pois também incluem todas as partes interessadas em sua criação. Em termos de linguagem onipresente, eu não diria que o BDD ou as histórias de usuários são melhores - embora elas diferam significativamente no próximo ponto.
Testabilidade
Um aspecto importante do BDD é que suas especificações são realmente executáveis (via pepino ou similar). Nem os requisitos nem as histórias do usuário oferecem esse recurso. Para mim, pessoalmente, esse é o principal ponto de venda do BDD.
Compare isso com os requisitos tradicionais - informamos há muito tempo aos engenheiros de requisitos que seus requisitos devem ser testáveis. No entanto, todo projeto vê um caso em que, em algum ponto da linha, os testadores percebem que não têm idéia de como testar um determinado requisito.
As histórias de usuários, se bem feitas, incluem testadores em seu estágio inicial de criação para garantir isso. Infelizmente, este é um caso de teoria em conflito com o mundo real, onde eu já vi inúmeras histórias que nenhum testador viu antes.
O BDD, por outro lado, automaticamente fornece um cenário de teste executável. Não há desculpas nem maneiras de contornar isso (a menos que você ignore completamente as camadas de automação e apenas anote os cenários para a poesia sofisticada).
De maneira mais geral, o Test First é um princípio que tem sido muito gratificante em todos os estágios do desenvolvimento de software e o BDD é sua aplicação na camada mais externa do desenvolvimento (em comparação com o TDD, por exemplo, no nível da unidade).
Sumário
Em resumo, o BDD não o eleva dos problemas da ambiguidade da linguagem natural. No entanto, ajuda você a resolver esse problema através de dois pontos importantes: Concentrar-se em uma linguagem onipresente para reduzir as ambiguidades (não as eliminará totalmente, mas ajuda muito!) E forçando você a escrever executável especificações. O último ponto está ajudando a resolver problemas de ambiguidade principalmente porque esse é o ponto em que as ambiguidades começam a aparecer como problemas de outra maneira.