기획자, 개발자, QA가 함께 쓰는 테스트 명세서, 'BDD' 시작하기

이런 경험 없으신가요? 기획자는 A라고 생각하고 문서를 썼는데, 개발자는 B라고 이해해서 개발하고, QA는 C라고 해석해서 버그라고 보고하는 상황. 이런 소통의 부재는 프로젝트의 시간과 비용을 낭비하는 가장 큰 원인 중 하나입니다.

목차 숨기기

‘BDD(Behavior-Driven Development, 행동 주도 개발)’는 바로 이 문제를 해결하기 위해 탄생한, 팀의 모든 구성원이 ‘공통의 언어’로 소통하고 협업하도록 돕는 개발 방법론입니다.

BDD는 기술적인 팀원(개발자, QA)과 비기술적인 팀원(기획자, PM)이 ‘사람이 읽을 수 있는’ 자연어 형식으로 소프트웨어의 ‘행동(Behavior)’에 대한 공통의 이해를 구축하고, 이를 바탕으로 개발과 테스트를 진행하는 방법론입니다.

BDD는 ‘거킨(Gherkin)’이라는, 정해진 규칙을 가진 언어를 사용하여 시나리오를 작성합니다. 이 문법은 Given-When-Then 이라는 핵심 구조를 가집니다.

Gherkin 문법:
- Given (어떤 상황이 주어졌을 때): 시나리오가 시작되기 위한 전제 조건이나 초기 상태를 설명합니다.
- When (언제 / 무엇을 하면): 사용자가 특정 행동을 하는 것을 설명합니다.
- Then (그러면 / 어떻게 되어야 한다): 그 행동의 결과를 검증 가능한 형태로 명확하게 설명합니다.
예시 (로그인 기능):Gherkin# 시나리오 이름: 성공적인 로그인 Given 사용자가 로그인 페이지에 있고 When 올바른 아이디와 비밀번호를 입력하고 And 로그인 버튼을 누르면 Then 사용자는 "환영합니다" 라는 메시지를 보게 된다. 이 시나리오는 개발자가 아니더라도 누구나 쉽게 읽고 이해할 수 있습니다.

BDD는 QA의 역할을 근본적으로 바꾸고, 테스트 프로세스에 많은 이점을 제공합니다.

1. 요구사항 명확화 (Shift Left 실천):
- 개발이 시작되기 전에, 모든 팀원이 모여 Given-When-Then 시나리오를 함께 작성합니다. 이 과정에서 숨겨진 예외 케이스나 모호한 부분이 자연스럽게 드러나고, 모두가 동일하게 이해하는 명확한 요구사항을 만들 수 있습니다. 이는 버그를 사전에 ‘예방’하는 가장 확실한 방법입니다.
2. 테스트 자동화와의 직접적인 연결:
- 이렇게 작성된 Gherkin 시나리오는 그 자체로 ‘실행 가능한 명세서’가 됩니다. Cucumber(Java), Behave(Python), SpecFlow(.NET) 같은 BDD 프레임워크를 사용하면, 이 Given-When-Then 문장 하나하나를 실제 자동화 테스트 코드와 직접 연결할 수 있습니다.
3. 팀 전체의 품질 책임 강화:
- 기획자, 개발자, QA 모두가 테스트 시나리오 작성에 함께 참여하므로, ‘품질은 QA만의 책임’이라는 생각에서 벗어나 팀 전체가 품질을 함께 책임지는 ‘품질 문화’를 만드는 데 큰 도움이 됩니다.

BDD는 단순히 테스트를 자동화하는 새로운 기술이 아닙니다. 이것은 팀의 소통 방식을 바꾸고, 오해의 소지를 줄이며, 모두가 같은 목표를 향해 나아가도록 돕는 강력한 ‘소통과 협업의 프레임워크’입니다.

QA가 BDD 프로세스에 적극적으로 참여할 때, QA는 더 이상 완성된 결과물을 검증하는 역할에 머무르지 않습니다. 명확하고 테스트 가능한 요구사항을 함께 만들어가는, 제품 개발의 핵심적인 파트너로 거듭날 수 있습니다.

기획자, 개발자, QA가 함께 쓰는 테스트 명세서, ‘BDD’ 시작하기