자연어가 모호 할 때 행동 주도 개발은 어떻게 명확성을 개선합니까?

나는 현재 오이와 같은 BDD 테스트 프레임 워크를 탐색 하고 있으며 사람들이 말할 때 궁금해합니다.

기능 파일은 단순한 자연 언어이므로 명확성을 향상시키고 명확한 비전을 제공합니다.

그러나 자연어가 우리가 소프트웨어 엔지니어링에서 겪고있는 대부분의 문제의 원인이 아닙니까?

자연어는 모호하며 고객 요구 사항의 잘못된 해석과 개발자의 이해로 인해 많은 소프트웨어 프로젝트가 실패하는 이유입니다. 나는 틈새 시장을 얻지 못한다.

그렇습니다. 테스트를 아주 간단한 실행 가능한 조치로 분류하면 의미가 있고 어느 정도의 명확성이 제공되지만 전체적으로 생산성이 향상됩니까?

추신 : 저는 전문가가 아니며 여기서 의견을 말하지 않습니다. 나는 그 개념을 이해하고 싶어합니다.

당신이 올바른지. BDD는 언어 모호성 문제를 제거하지 않습니다. 다른 사람들이 지적했듯이 번역 된 스 니펫은 올바르게 정의하여 일치시켜야하지만 근본적인 모호성 문제를 해결하지는 못합니다.

이제이 문제를 해결하지 않아도 BDD가 실제로 가치가있는 이유는 무엇입니까? 몇 가지 이유가 있으며이 목록은 확실하지 않습니다.

모호성이 해결되지 않았습니다

이것이 BDD를 선호하거나 반대하는 이유는 아닙니다. 그러나 사용자 사례 또는 요구 사항과 같은 다른 접근 방식과 대조 할 때 모든 SW 개발 접근 방식은 모두 자연어 구성으로 시작하여 언어 모호성으로 인해 어려움을 겪습니다.

기술적으로 언어 모호성의 문제는 lojban 과 같은 인공 언어로 해결 되었지만 고객과 개발자는 해당 언어를 모를 것입니다.

유비쿼터스 언어

BDD는 유비쿼터스 언어라는 개념과 밀접한 관련이 있습니다. 모든 고객, 테스터 및 개발자와 함께 시나리오를 지정할 수 있기 때문에 BDD는 다른 접근 방식보다 우위에 있습니다.

기존 요구 사항 엔지니어가 모든 요구 사항을 적어 두십시오. 테스터 나 고객이 검토해야 할 요구 사항으로 가득 찬 300 페이지의 문서를 받으면 여기에 사용 된 용어보다 훨씬 더 시급한 문제가 있습니다.

사용자 스토리는 창작에 모든 이해 관계자가 포함되기 때문에 그 측면에서 조금 나아집니다. 유비쿼터스 언어의 관점에서 볼 때, BDD 또는 사용자 스토리가 더 낫다고 말하지는 않지만 다음 시점에서는 크게 다릅니다.

테스트 가능성

BDD의 주요 측면은 사양이 실제로는 (오이 등을 통해) 실행 가능하다는 것입니다. 요구 사항이나 사용자 스토리는이 기능을 제공하지 않습니다. 개인적으로 BDD의 주요 판매 지점입니다.

기존 요구 사항과 달리, 요구 사항 엔지니어에게 요구 사항을 테스트 할 수 있어야한다고 말하고 있습니다. 그러나 모든 프로젝트는 라인 테스터가 특정 요구 사항을 테스트하는 방법을 모른다는 것을 알고있는 경우를 봅니다.

사용자 스토리가 올바르게 수행되면 초기 제작 단계에 테스터를 포함시켜이를 확인할 수 있습니다. 불행히도, 이것은 실제 세계와 이론이 충돌하는 경우이며, 이전에는 테스터가 보지 못한 수많은 이야기를 보았습니다.

반면에 BDD는 자동으로 실행 가능한 테스트 시나리오를 제공합니다. 자동화 계층을 완전히 무시하고 멋진시를위한 시나리오를 작성하지 않는 한 변명이나 그에 대한 방법은 없습니다.

보다 일반적으로 Test First는 모든 소프트웨어 개발 단계에서 매우 보람있는 원칙이며 BDD는 개발의 최 외층에 적용됩니다 (단위 레벨의 f.ex. TDD와 비교).

요약

요약하자면, BDD는 자연어 모호성 문제에서 벗어나지 않습니다. 그러나 두 가지 중요한 점을 통해 문제를 해결하는 데 도움이됩니다. 모호성을 줄이기 위해 유비쿼터스 언어에 중점을 두어 (완전히 제거하지는 않지만 톤을 도와줍니다!) 실행 파일을 작성하도록합니다. 명세서. 후자의 요점은 모호성 문제를 해결하는 데 도움이되고 있는데, 그 이유는 모호성이 다른 문제로 나타나기 시작하기 때문입니다.

무언가가 "자연 언어"로 쓰여질 때 이것은 많은 것을 의미 할 수 있습니다 :

• 이것은 말 그대로 영어입니다. 영어는 매우 모호하고 모호한 언어이므로이 입력 모드는 소프트웨어 개발 환경에서 만족스럽지 않습니다.

• 이것은 영어이지만 관련 용어가 정확하게 정의되어 있습니다. 이러한 언어는 법률 문서 또는 수학 텍스트에 사용됩니다.

• 이 언어는 공식 언어이지만 자연어 규칙에 따라 매우 밀접하게 모델링되었습니다. 모든 프로그래밍 언어를 어느 정도 설명합니다. 영어와 같은 공식 언어가 많을수록 훈련되지 않은 독자가 이해하기가 더 쉽습니다. 이 목표를 가진 프로그래밍 언어의 주목할만한 예로는 COBOL과 SQL select id, name from persons where age > 18이 있습니다. 이러한 언어의 단점은 작업 코드 를 작성 하려면 공식 언어를 이해해야한다는 것 입니다. 또한 이러한 언어는 종종 매우 장황합니다.

DDD는 프로젝트가 유비쿼터스 언어 를 사용 하여 도메인을 설명 할 것을 제안 합니다. 이것은 본질적으로 사례 2 : 자연어 내에서 정확하게 의사 소통 할 수 있도록 관련 용어를 정의합니다.

오이 자체는 사례 3 : 일반 영어에 매우 가깝게 읽고 자하는 공식 언어입니다. 보다 정확하게 : Cucumber는 요구 사항 / 테스트를 표현하는 데 사용할 수있는 간단한 공식 언어를 정의 할 수있는 프레임 워크입니다. 여기서 중요한 것은 동일한 문서가 자연어 요구 사항과 자동으로 실행 가능한 테스트를 나타내므로 둘 다 항상 동기화됩니다. 오이 시나리오를 읽고이 모든 작동 방식을 이해하지 않고도 요구 사항을 올바르게 표현하는지 확인할 수 있습니다.

오이는 문서를 알려진 자연어 스 니펫과 일치시켜 작동합니다. 이 스 니펫은 먼저 정의해야합니다. Cucumber에서 시나리오를 작성하려면 사용 가능한 스 니펫을 알고 있어야합니다. 소프트웨어는 사용자의 마음을 읽지 못합니다. 이러한 스 니펫은 가능한 문제의 원인이기도합니다. 텍스트 스 니펫의 동작을 구현할 때 코드는 스 니펫 텍스트가 제안하는 것과 약간 다르게 작동 할 수 있습니다. 동일한 스 니펫을 여러 번 사용하는 경우 문제가되지 않습니다. 따라서 오이는 더 작은 조건, 조치 및 결과 세트로 구성된 비즈니스 규칙을 설명하는 데 적합합니다. 예를 들어 각 테스트 사례에 대한 설정이 고유하기 때문에 각 스 니펫을 한두 번만 사용하면 다른 테스트 프레임 워크가 더 나을 수 있습니다.

Given / When / Then / And 키워드 뒤의 텍스트 인 @ Raghuram8892는 "스 니펫"과 일치해야합니다. 그렇지 않으면 단계가 정의되지 않거나 "보류 중"으로 실패합니다. 따라서 사례 3에 해당합니다.

"영어", 오이 및 그 언어와 관련하여 Gherkin은 국제적으로 사용하도록 설계되었습니다. 명령을 호출하여 cucumber --i18n help현재 지원되는 언어 목록 cucumber --i18n $CODE을보고 특정 언어 코드의 키워드를 볼 수 있습니다. 예를 들어, cucumber --i18n eo에스페란토의 키워드를 제공합니다.