Behavior Driven Development
BDD란, 행위주도개발의 약자로 Agile개발방법 중 하나라고 널리 알려져 있습니다.
BDD는 DDD와 TDD의 중간지점 즈음에 위치하고 있습니다.
개발을 진행하면서, 어떠한 비즈니스 요구사항은 각 부서의 관계자들 간의 서로 이해가 다를 수 있습니다. 각각의 다른 이해로 인하여 많은 Communication cost가 발생하고, 때로는 고객이 요구하는 내용과는 전혀다른 결과물이 만들어지기도 합니다.
그렇기 때문에 비즈니스 요구사항을 모두 이해하기 쉽도록, 공통적인 레벨로 통일할 필요가 발생하게 되었습니다. 이러한 것을 해결하기 위해 BDD가 생겨나게 되었습니다.
BDD을 진행하기 위해선 관계자들 사이에서 합의된 일정한 format에 따라 비즈니스 요구사항이 기술되어야만 합니다. 이렇게 작성된 비즈니스 요구사항은 개발자들에게는 개발의 방향을 제시하게 되며, QA에게는 QA에서 확인해야할 일정의 기준이 됩니다.
특히 BDD에서 정의되는 비즈니스 요구사항은 Integration Test, End to End Test에서의 테스트케이스처럼 넓고 큰 범위의 기능을 정의합니다.
Why it is getting popular?
BDD는 TDD를 넘어서 새롭게 주목받은 개발방법론입니다. (물론 쓰이는 경우가 좀 다르다고 이해
하고 있습니다.) 어째서 주목받는 걸까요?
- 개발해야할 기능 / 테스트케이스를 정의하는 공통적인 표준, Template 따르게 됩니다.
- 각각의 비즈니스 시나리오는 비즈니스 요구사항을 반영합니다.
- 이 시나리오에 기반하여 구현한 기능들과, 테스트케이스들을 통해 비즈니스 요구사항에 대한 커버리지를 가늠할 수 있게 됩니다.
- BDD에 따라 작성된 비즈니스 요구사항에 대한 내용은, 이 자체로도 문서화할 수 있습니다.
다음 포스트에서는 이러한 BDD에 기반한 요구사항 파일의 확장자중 하나인 .feature 파일과, 해당 파일의 문법인 Gherkin 에 대해 작성해보고자 합니다.
Reference
QA Engineer