컨퍼런스 2일차 오후 첫번째 세션은 그 유명한 ThoughtWorks 사의 Anand Bagmar 라는 분이 발표한 'Build the Right Regression Suite with Behavior-Driven Testing'라는 세션을 들었습니다.
처음에 들어갈때는 ThoughtWorks 사의 발표인줄 몰랐다가 나중에 보니 ThoughtWorks 사의 발표더군요.. 웬지 모를 급 호감이...
사실 들을만한 세션이 없어서 반은 호기심으로 들어갔던 세션인데 생각보다 세션 내용이 매우 좋았습니다.
발표를 듣는 사람도 엄청 많아서 좌석이 모자라서 서서 드는 사람이 있을 정도였습니다. 웬지 모를 뜨거운 반응이었습니다. 제가 들었던 세션 중 그토록 뜨거웠던 반응을 보인 세션은 이 세션이 유일했습니다.
발표하시는 분이 인도분이라서 발음을 못알아들을까봐 매우 걱정했는데 발음도 좋으시고...
하지만 이 세션을 들어도 사실 전 아직도 BDT를 잘 모르겟습니다. 개념은 대충 알겠는데.. 흠..
세션 발표내용을 요약하면 이렇습니다.
애자일 개발 조직에서는 단위테스트가 아무래도 자동화가 용이하다보니 단위테스트만 비대해지는 경향이 있다. 그래서 대체로 애자일 개발 조직에서는 테스트가 피라미드 모양이 된다. 아래가 길고 위는 얇은..
이렇게 되면 필연적으로 GUI 테스트가 약해질 수밖에 없다. GUI 테스트는 아무래도 자동화 테스트가 어려운 것이 사실이다. GUI 테스트를 모두 자동화할 수는 없다. 자동화와 함께 탐색적 테스팅과 같이 사람이 하는 테스트도 중요하다.
그럼 GUI 테스트를 어떻게 자동화할것인가?
그에 대한 방안이 BDD 또는 BDT이다.
BDT는 기능이 아닌 행동(액션, 목적)에 집중하는 것이다. 큰 그림을 볼 수 있어야 한다.
기능에 집중하면 테스트 케이스를 많이 만들 수는 있지만 중요한 것을 놓칠 수 있다.
BDT를 작성하기 위해서는 퍼소나를 먼저 작성해야하고 그다음 퍼소나의 비즈니스 플로우에 집중해서 테스트 케이스를 도출해야한다.
정황이 최고다(Context is KING!!).
그리고 BDT로 작성한 테스트 케이스는 CI를 통해 지속적으로 통합, 수행되어야 한다.
머 이런 내용이었습니다.
사실 도구에 대한 소개나 시연 같은 것을 기대했었는데, BDD의 기본 개념만 소개되었고 마지막에 이러한 BDD의 구현은 돌아가서 각자 알아서 하라고 하더군요.
도구는 cucumber를 고려하라고 간단하게 말하고 넘어갔습니다.
그리고 여기서도 역시 CI 도구로 Jenkis를 강조하더군요.
정말로 재미있게 들었던 세션이었습니다.
처음에 들어갈때는 ThoughtWorks 사의 발표인줄 몰랐다가 나중에 보니 ThoughtWorks 사의 발표더군요.. 웬지 모를 급 호감이...
사실 들을만한 세션이 없어서 반은 호기심으로 들어갔던 세션인데 생각보다 세션 내용이 매우 좋았습니다.
발표를 듣는 사람도 엄청 많아서 좌석이 모자라서 서서 드는 사람이 있을 정도였습니다. 웬지 모를 뜨거운 반응이었습니다. 제가 들었던 세션 중 그토록 뜨거웠던 반응을 보인 세션은 이 세션이 유일했습니다.
발표하시는 분이 인도분이라서 발음을 못알아들을까봐 매우 걱정했는데 발음도 좋으시고...
하지만 이 세션을 들어도 사실 전 아직도 BDT를 잘 모르겟습니다. 개념은 대충 알겠는데.. 흠..
세션 발표내용을 요약하면 이렇습니다.
애자일 개발 조직에서는 단위테스트가 아무래도 자동화가 용이하다보니 단위테스트만 비대해지는 경향이 있다. 그래서 대체로 애자일 개발 조직에서는 테스트가 피라미드 모양이 된다. 아래가 길고 위는 얇은..
이렇게 되면 필연적으로 GUI 테스트가 약해질 수밖에 없다. GUI 테스트는 아무래도 자동화 테스트가 어려운 것이 사실이다. GUI 테스트를 모두 자동화할 수는 없다. 자동화와 함께 탐색적 테스팅과 같이 사람이 하는 테스트도 중요하다.
그럼 GUI 테스트를 어떻게 자동화할것인가?
그에 대한 방안이 BDD 또는 BDT이다.
BDT는 기능이 아닌 행동(액션, 목적)에 집중하는 것이다. 큰 그림을 볼 수 있어야 한다.
기능에 집중하면 테스트 케이스를 많이 만들 수는 있지만 중요한 것을 놓칠 수 있다.
BDT를 작성하기 위해서는 퍼소나를 먼저 작성해야하고 그다음 퍼소나의 비즈니스 플로우에 집중해서 테스트 케이스를 도출해야한다.
정황이 최고다(Context is KING!!).
그리고 BDT로 작성한 테스트 케이스는 CI를 통해 지속적으로 통합, 수행되어야 한다.
머 이런 내용이었습니다.
사실 도구에 대한 소개나 시연 같은 것을 기대했었는데, BDD의 기본 개념만 소개되었고 마지막에 이러한 BDD의 구현은 돌아가서 각자 알아서 하라고 하더군요.
도구는 cucumber를 고려하라고 간단하게 말하고 넘어갔습니다.
그리고 여기서도 역시 CI 도구로 Jenkis를 강조하더군요.
정말로 재미있게 들었던 세션이었습니다.
댓글
댓글 쓰기