본문으로 건너뛰기
중급약 20분

BDD와 TDD: Given-When-Then, 테스트 주도 개발에서 QA의 역할

코드를 짜기 전에 테스트부터 쓰는 TDD, 그리고 사람이 읽을 수 있는 문장으로 요구사항과 테스트를 잇는 BDD. QA가 이 흐름에서 어디에 기여하는지 익힌다.

  • #BDD
  • #TDD
  • #GivenWhenThen

개념

TDD — 테스트를 먼저 쓴다

TDD(Test-Driven Development)는 개발자가 기능 코드를 짜기 전에 그 기능을 검증할 테스트 코드를 먼저 쓰는 개발 방식이다. 순서는 다음과 같다.

1. 실패하는 테스트를 먼저 쓴다 (Red)
2. 테스트를 통과시키는 최소한의 코드를 짠다 (Green)
3. 코드를 정리한다, 테스트는 계속 통과해야 한다 (Refactor)

이 사이클을 짧게 반복한다. TDD는 주로 개발자가 단위 테스트(모듈 10에서 다룬다) 수준에서 실천하는 습관이다.

BDD — 사람이 읽을 수 있는 문장으로 행위를 정의한다

BDD(Behavior-Driven Development)는 TDD의 사고방식을 확장해, 개발자가 아닌 사람도 읽고 이해할 수 있는 문장으로 시스템이 어떻게 동작해야 하는지 먼저 정의한다. 대표적인 형식이 Given-When-Then(Gherkin 문법)이다.

Given 로그인한 사용자가 장바구니에 상품 2개를 담아둔 상태에서
When  사용자가 유효한 쿠폰 코드를 입력하고 "적용" 버튼을 누르면
Then  주문 금액에서 쿠폰 할인이 반영되어야 한다
  • Given — 시작 상태(사전조건)
  • When — 사용자의 행동
  • Then — 기대하는 결과

이 구조는 모듈 3(레슨 1)에서 배운 테스트 케이스의 사전조건·절차· 기대결과와 본질적으로 같다 — 다만 BDD는 이걸 기획자·개발자·QA가 모두 같은 언어로 합의하는 산출물로 만든다는 점이 다르다.

BDD에서 QA의 역할

BDD 워크숍(흔히 "Three Amigos"라 불리는, 기획자·개발자·QA 세 역할이 함께 모이는 세션)에서 QA는 Given-When-Then 시나리오를 작성하거나 검토하며 엣지 케이스와 예외 상황을 미리 질문한다.

"Given에서 '유효한 쿠폰'이라고 했는데, 쿠폰이 만료됐거나 이미 쓴 쿠폰이면 어떻게 되나요? 그 시나리오도 필요하지 않을까요?"

이 질문은 모듈 2(레슨 6)에서 배운 "질문하는 QA"의 역할을, BDD라는 구체적인 산출물 위에서 실천하는 것이다. 이렇게 미리 합의된 시나리오는 자동화 테스트(Cucumber 같은 도구)로 그대로 옮겨지기도 한다 — 즉 BDD 시나리오가 살아있는 문서이자 테스트 코드의 원본이 된다.

TDD와 BDD의 관계

TDD는 "코드가 옳게 동작하는가"를 개발자 관점에서 검증하는 습관이고, BDD는 "시스템이 사용자가 원하는 대로 행동하는가"를 비즈니스 언어로 먼저 합의하는 방식이다. 둘은 배타적이지 않고, 많은 팀이 BDD로 시나리오를 합의한 뒤 그 시나리오를 구현하는 코드를 TDD 방식으로 짠다.

실무에서 왜 필요한가

BDD 시나리오 작성 워크숍에 QA가 참여하는 팀에서는, 개발이 시작되기 전에 엣지 케이스가 이미 논의되어 있어 나중에 결함으로 발견되는 빈도가 줄어든다. 이건 모듈 2에서 배운 "요구사항 단계에서 결함을 막는다"는 원칙을 BDD라는 구체적인 실무 도구로 실천하는 것이다. "BDD/Cucumber 경험"을 요구하는 채용공고도 결국 이 협업 능력을 평가하려는 것이다.

실습 과제

과제 1 — Given-When-Then 작성하기 (10분)

"비밀번호 재설정" 기능에 대해 Given-When-Then 형식의 시나리오를 2개 작성한다 — 하나는 정상 경로, 하나는 예외 상황(예: 만료된 재설정 링크)으로 만든다.

과제 2 — 엣지 케이스 질문 만들기 (10분)

다음 시나리오를 보고, Three Amigos 세션에서 QA로서 던질 만한 질문을 2개 만든다.

Given 사용자가 상품 상세 페이지에 있을 때
When  "찜하기" 버튼을 누르면
Then  찜 목록에 상품이 추가되어야 한다

자가 체크리스트

  • TDD의 Red-Green-Refactor 사이클을 설명할 수 있다
  • Given-When-Then 형식으로 시나리오를 작성할 수 있다
  • BDD 워크숍에서 QA가 어떤 역할을 하는지 설명할 수 있다
  • TDD와 BDD의 관계(배타적이지 않다는 것)를 설명할 수 있다

흔한 실수

  • BDD 시나리오를 개발이 다 끝난 뒤에야 작성한다. BDD의 가치는 개발 전에 합의하는 데 있다 — 사후 작성은 그냥 테스트 케이스 문서화에 가깝다.
  • Given-When-Then을 너무 구현 세부사항 위주로 쓴다("Given DB에 row가 있을 때"). 사용자 행위 관점에서 써야 기획자도 읽고 검토할 수 있다.
  • TDD는 개발자만의 일이라고 생각해 BDD 워크숍에 QA가 소극적으로 참여한다. 엣지 케이스 질문은 QA가 가장 잘하는 기여 지점이다.

참고 자료

  • Dan North — Introducing BDD — BDD 개념을 처음 정리한 원문 글
  • Kent Beck, Test-Driven Development: By Example — TDD의 고전적인 정의와 사례