온라인 포럼 및 게시물에서 알 수있는 것부터 BDD/ATDD의 주요 초점 중 하나는 토론 중이며 고객, 개발자, 테스터 및 기타 관련 당사자가 시스템에서 수행해야 할 작업을 이해하고 있음을 확인하는 것 같습니다. .BDD/ATDD 이야기가 전통적인 요구 사항의 필요성을 대체합니까?
질문 1 : BDD/ATDD 이야기는 Volere Template을 사용하여 캡처 한 것과 같은 전통적인 요구 사항 사양의 필요성을 대체합니까?
전통적인 요구 사항 사양은 개발자와 테스터의 주요 입력 사항 중 하나이므로 전통적인 요구 사양은 포괄적 인 경향이 있습니다.
질문 2 : BDD/ATDD 사례도 시스템을 완전히 테스트 할 수있을 정도로 포괄적이어야합니까?
질문 1 :이 질문을 흑백 상태로 보는 대신이 두 요구 사항 캡처 방법이 서로 어떻게 조화를 이루는지 더 잘 이해해야합니다. 예를 들어 story을 BDD/ATDD 방법론 또는 Scrum에 쓰는 것은 표에서 volere과 같은 서식 파일을 제거하는 것을 의미하지 않습니다. volere 요구 사항 사양 here을 살펴보면 대부분의 정보가 프로젝트 관련 문제에 관련되어 있다는 것을 알 수 있으며 기능 요구 사항에 사용되는 셸은 스토리와 다르지 않습니다. 그들은 단지 다른 정보가 아니라 독점적 인 정보가 아닙니다.
질문 2 : 여기서 우리는 방법론 자체에서 이점이 있습니다. BDD는 TDD에서 비롯되었으므로 팀이 시스템을 테스트 할 수 있도록 테스트 우선 프로세스에 어느 정도 의존 할 수 있습니다. 그러나 질문 1에서 언급했듯이 BDD/ATDD 이야기를보다 포괄적으로 만드는 것은 죄가 아니며 이야기의 일반적인 개념을 손상시키지 않습니다. 경험 많은 고객과 상호 작용할 때도 유용합니다.