BDD를 QA 테스트에 적용하기

BDD (Behavior Driven Development) 는 아래와 같이

Given, When, Then 을 이용하여 사용자 시나리오를 정의하는 것에서 부터 출발합니다.

이러한 사용자 시나리오를 바탕으로 Cucumber 등의 프레임워크를 이용해서

TDD에 사용될 Test case들을 만드는 등의 형태로 많이 설명이 됩니다.

 

개발과는 한발짝 떨어진,

User Level의 End to End test를 하는 QA 입장에서

이런 BDD 방법론을 개발팀을 설득해서 도입하는 것 이전에

테스트에 도입을 할 만한 방안이 없을까 고민을 해 봅니다.

 

User Level의 End to End Test의 경우 자동화된 테스트에서 

Cucumber 등을 이용하여 BDD 형식을 도입을 하더라도 

들인 시간 대비 얻는 이점이 그리 크진 않습니다.

실제 BDD라는 것이 개발자와 비 개발자(마케팅 등)의 원활한 업무 협조 등의 목적이

큰 방법론이라 테스트 한정으로는 한계가 있죠.

 

다만 BDD의 기본이라고 할 수 있는 Given, When, Then 의 표현방법을

테스트 정의에 이용을 하면 테스트 케이스의 가독성이 높아지는 효과는 볼 수 있습니다.

 

Case 1: 구글 OAuth Test  - 브라우저를 열고 구글을 로그인 한다  - 로그인후 포털의 로그인 화면으로 이동한다  - 로그인 옵션중 구글 로그인을 선택한다  - 다른 로그인 화면 없이 로그인이 잘 되는지 확인한다 Case 2: 구글 OAuth Test  - Given : 브라우저에서 구글 로그인이 이미 되어있는 상황에서  - When : 포털의 로그인시 구글 로그인을 선택하였을 경우  - Then : 다른 추가 로그인 화면 없이 로그인이 되어야 한다.

 

위 Case 1과 Case 2를 비교해보면

Case 2번이 전제 조건(Given), 입력 (When), 기대값(Then) 으로 잘 정리된 느낌을 받을 수 있습니다.

 

위와 같이 메뉴얼 테스트의 경우 BDD 표현방법을 이용한 테스트 케이스 작성을 한다면,

자동화 테스트의 경우는 아주 간단하게는 method 이름 혹은 Display name 등에 

이를 활용할 수 있습니다.

@Test
@DisplayName("Given : When loggined in google, When : Select login method to Google login, Then : Shall be logged in without any other login prompt")
void testGoogleOAuth () {
 // some test code here
}

추가 적으로 Given_GoogleLogin, When_GoogleOAuthLogin, Then_CheckLogin 등의 method를 

따로 정의 하여 테스트 코드 내에서도 BDD의 표현식을 따라 갈 수도 있겠네요.

 

자동화 테스트 코드도 가독성이 아주 중요합니다.

테스트 코드이니만큼 누구나 이해할 수 있을 만큼의 수준이 되면 더 좋을 것 입니다.

이러한 BDD 표현방식을 통해 가독성 문제를 어느정도 만족시킬 수 있을 것 같습니다.