[번역] How Google Tests Software - Part Two

How Google Tests Software – Part Two

Wednesday, February 09, 2011 6:36 PM

 

By James Whittaker

 

“당신이 만들고, 만든 당신이 해체한다(You build it, you break it)”라는 모토를 실현하기 위해서는, 전통적인 개발자의 역할을 능가할 수 있는 새로운 역할이 필요하다. 특히 개발자가 효율적이고 효과적으로 테스트를 수행할 수 있도록 엔지니어링을 수행할 사람이 반드시 필요하다. 구글에서는 다른 사람들이 좀 더 생산적으로 일할 수 있도록 하는 엔지니어 역할을 만들었다. 이러한 엔지니어들은 스스로를 테스터라고 부르기는 하지만, 실상은 생산성과 관련된 미션을 수행한다. 그들은 개발자들이 테스트를 통해 좀 더 생산적인 업무를 수행할 수 있도록 해준다. 이들의 역할을 간단하게 알아보자.  

 

SWE 혹은 소프트웨어 엔지니어(Software Engineer)들은 전통적인 의미의 개발자(developer)들을 말한다. SWE들은 고객들이 사용하는 기능을 코드로 작성한다. 그들은 설계 문서(design documentation), 설계 데이터 구조(design data structure)와 전체적인 아키텍쳐를 만들고, 코드를 작성하고 리뷰 하는 일에 가장 많은 시간을 할애한다. SWE는 테스트 주도 설계(test driven design)와 유닛 테스트를 포함하는 수많은 테스트 코드를 작성하고, 이후에도 설명하겠지만 다양한 규모의 테스트에도 참여한다. SWE는 그들이 작성하거나 수정 혹은 변경한 모든 것들의 품질에 대한 책임을 진다(SWE own quality for everything they touch whether they wrote it, fixed it or modified it).

 

SET 혹은 테스트 소프트웨어 엔지니어(Software Engineer in Test)는 그들의 업무 영역이 테스트를 쉽게 수행하도록 하는 것(testability)에 맞춰져 있다는 것을 제외하고는 개발자와 동일한 역할을 수행한다. 그들은 설계를 리뷰하고 코드 품질과 리스크를 심도 있게 살펴본다. 그들은 쉽게 테스트가 수행될 수 있도록 코드를 리팩토링 한다. 또한 SET는 유닛 테스팅 프레임워크와 자동화 코드도 작성한다. 그들은 코드를 작성한다는 관점에서 SWE와 파트너이기는 하지만, 제품에 새로운 기능을 추가하거나 퍼포먼스를 높이는 대신, 제품의 품질과 테스트 커버리지를 향상시키는 일에 더 관련이 있다.

 

TE 혹은 테스트 엔지니어(Test Engineer)는 정확하게 SET와 반대되는 일을 한다. 이들에게는 테스트가 먼저고, 개발은 그 다음이다. 구글의 많은 TE들이 사용자 시나리오처럼 사용자의 입장을 대변하는 자동화 스크립트와 코드를 작성하는데 많은 시간을 할애한다. 그들은 또한 SWE와 SET의 테스팅 작업을 준비하고, 테스트 결과를 분석하며, 테스트 수행을 도와준다. 이러한 일들은 특히 릴리즈에 대한 압박이 심해지는 프로젝트의 마지막 단계에서 많이 수행된다. TE는 제품에 대한 전문가인 동시에 품질에 관한 조언자이며, 또한 리스크를 분석하는 사람이기도 하다.

 

품질이라는 관점에서 볼 때, SWE는 기능과 이러한 기능의 품질 모두를 책임지는 사람들이다. 그들은 폴트 톨러런스 설계(fault tolerant designs), 장애 복구(failure recovery), TDD, 유닛 테스트 등을 책임지는 동시에, SET와 함께 코드가 제 기능을 수행하는지 검증하는 테스트를 작성한다.

 

SET는 테스팅 기능을 제공하는 개발자다. 스텁(stub)이나 목업(mocks) 그리고 페이크(fake)를 사용해 디펜던시(dependencies)를 시뮬레이팅 함으로써 새롭게 개발된 코드를 격리시키고, 코드 체크인을 관리하기 위한 큐(Queues)를 서브밋(submit)한다. 즉, SET는 SWE가 기능을 테스트 할 수 있도록 해주는 코드를 작성한다는 말이다. 실제로 테스트의 대부분은 SWE에 의해 수행된다. SET는 해당 기능이 테스트 가능한지, 그리고 SWE가 능동적으로 테스트 케이스 작성 작업에 참여하는지를 확인한다.

 

명백하게 SET는 개발자들에게 우선적인 초점을 둔다. 개별 기능의 품질이 그들의 타깃이며, 개발자들이 작성한 코드를 스스로 쉽게 테스트 할 수 있도록 만드는 것이 SET의 가장 주된 관심사다. 이러한 개발 포커스에는 하나의 큰 약점이 있다. 아마 이 글을 읽고 있는 독자들이라면 이미 확실하게 알고 있을 것이다.

자, 그럼 사용자는 어떻게 할 것인가?

 

사용자에 초점이 맞추어진 테스팅은 구글에서 TE가 수행하는 일의 하나다. SWE와 SET가 모듈과 기능 수준의 테스팅을 적합하게 수행했다고 가정한다면, 그 다음 업무는 이렇게 수행 가능한 코드와 데이터들의 집합이 어떻게 한 데 모여 사용자의 니즈를 만족시키면서 정상적으로 잘 동작하느냐를 검증하는 것이다. TE는 개발자들의 성실함을 이중으로 점검하는 것이다. 누가 보아도 명백한 버그가 검출된다면, 앞선 사이클의 개발자 테스팅이 제대로 수행되지 않았거나 엉성했다는 것을 의미한다. 만약 그러한 버그가 거의 검출되지 않는다면, TE들은 그들의 최우선 업무를 일반적인 사용자 시나리오를 수행해 보는 것으로 바꾼다. 제품이 높은 성능을 발휘하며 또한 안전한지, 혹은 국제화(internationalized)는 제대로 되어 있는지 등을 점검하는 것이다. TE는 수많은 테스트를 수행한다. 가끔은 TE들끼리, 혹은 계약직 테스터, 일반 사용자에서 선출된 테스터들, 개밥 사용자들(dog fooders), 베타 유저들, 얼리어답터들과 함께 이런저런 일들을 수행한다. 그들은 이런 모든 이해관계자들과 함께 기본 설계, 기능의 복잡성(feature complexity)과 장애 회피 방법 등에 내재되어 있는 리스크에 대해 커뮤니케이션한다. TE들이 한 번 투입되고 집중하기 시작하면, 그들이 해야 할 일들은 아마  끝이 없을 것이다.

 

자, 이제 각각의 역할에 대해 조금 더 잘 이해가 될 것이다. 이러한 일들을 어떻게 조율할지에 대해서 좀 더 자세하게 파고들어 볼 것이다. 다음 시간에… 흥미를 가져줘서 고맙다.

-- continue --