책 발췌 – 구글 엔지니어의 테스팅 관련 역할

출처: 책 How Google Tests Software, James Whittaker, Jason Arbon, Jeff Carollo, 2012년

 

구글에서 소프트웨어 테스팅 관련하여 엔지니어 직무가 어떻게 나뉘어 있고 각기 어떤 역할을 하는지 소개하는 내용

 

---

 

구글의 테스팅 관련 직군

Google에서는 타 엔지니어가 더 생산적이고 더 품질에 유의하도록 만드는 일을 책임지는 역할이 존재한다. 이 엔지니어가 종종 스스로를 ‘테스터’로 식별하지만 그들의 실제 임무는 생산성(productivity)에 있다. 테스터는 개발자를 더 생산적으로 만들기 위해 존재하며, 이러한 생산성의 많은 부분이 조잡한 개발로 인한 재작업(re-work)을 없애는 데서 나온다. 품질은 따라서 이 생산성의 큰 부분을 차지한다.

 

소프트웨어 엔지니어(SWE: Software Engineer)

소프트웨어 엔지니어(SWE)는 전통적인 개발자 역할이다. SWE는 사용자에게 배포되는 기능 코드를 작성한다. 이들은 설계 문서를 작성하고, 데이터 구조와 전체 아키텍처를 선택하며, 대부분의 시간을 코드를 작성하고 검토하는 데 쓴다. SWE는 테스트 주도 설계(TDD)나 단위 테스트를 비롯한 많은 테스트 코드를 작성하고 스몰, 미디엄, 라지 테스트 구축에 참여한다. SWE는 자신이 만지는 모든 것에 대해(그것을 작성했는지, 픽스했는지, 또는 수정했는지 상관없이) 그 품질 주체(owner)가 된다. SWE가 어떤 기능을 수정해야 하고 그 수정으로 인해 기존 테스트가 훼손되거나 또는 새 테스트가 필요해진 경우 해당 SWE가 해당 테스트를 작성해야 한다. SWE는 거의 100%의 시간을 코드 작성에 쓴다.

 

 

테스트 분야 소프트웨어 엔지니어(SET: Software Engineer in Test)

SET도 마찬가지로 개발자 역할이지만 이들은 테스트용이성(testability)과 일반적인 테스트 인프라구조에 중점을 둔다. SET는 SWE가 쉽게 기능을 테스트할 수 있도록 하는 코드를 작성하며, 실제 테스팅의 많은 부분은 SWE에 의해 수행된다. SET는 설계를 리뷰하고 코드 품질과 리스크를 자세히 들여다본다. SET는 테스트용이성을 높이기 위해 코드를 리팩터링하고, 단위 테스트 프레임워크 및 자동화를 작성한다. 이들이 SWE 코드베이스의 파트너이지만 새로운 기능을 추가하거나 성능을 높이는 것보다 품질과 테스트 커버리지를 높이는 데 더 관심이 있다. SET도 코드 작성에 거의 100%에 가까운 시간을 할애하지만 고객이 사용하는 기능을 코딩하기보다는 품질을 위해 그렇게 한다.

 

 

테스트 엔지니어(TE: Test Engineer)

테스트 엔지니어(TE)는 SET 역할과 관련이 있지만 초점이 다르다. 이 역할은 사용자를 대신한 테스트 수행에 가장 우선순위를 두고 개발자는 그 다음이다. 일부 구글 TE는 사용자의 사용 시나리오를 자동화 스크립트 및 코드 형태로 작성하는 데 상당한 시간을 할애한다. 이들은 또한 SWE와 SET의 테스트 작업을 계획하고, 테스트 결과를 해석하고, (특히 릴리스 추진이 강화되는 프로젝트의 후반 단계에서) 테스트 실행을 주도한다. TE는 제품 전문가, 품질 고문, 그리고 리스크 분석가이다. 코드 작성을 아주 많이 하는 TE도 있고 그렇지 않은 TE도 있다.

 

 

테스트 엔지니어링 관리자(TEM: Test Engineering Manager)

TE와 SET가 각각 사용자와 개발자를 지원하기 위해 노력할 때 이들을 하나로 묶는 역할을 TEM이 한다. TEM은 개별적으로 중요한 일을 맡아 수행하는 엔지니어링 동료이자 모든 지원 팀(개발, 제품 관리, 릴리스 엔지니어, 문서 작성자 등)을 하나로 이어주는 접촉점이다. TEM은 TE와 SET의 스킬이 모두 필요하므로 아마도 구글의 모든 직책 중에서 가장 도전적인 자리일 것이다. TEM은 또한 직속 부하 직원의 경력 개발을 지원하기 위한 관리 스킬이 필요하다.

 

 

 

SET와 TE의 차이점 by Jason Arbon

SET의 역할과 TE의 역할은 관련되어 있지만 근본적으로 다르다. 내가 이 두 역할 모두를 경험하였고 또한 이 두 역할 모두의 관리자가 되어 본 적이 있다. 다음 목록을 보고 어떤 것이 나 자신을 가장 잘 설명하는지 찾아보라. 어쩌면 당신이 지금 하고 있는 역할을 바꿔야 할지도 모른다.

 

다음의 경우 SET에 가깝다.

• 명세서와 깨끗한 화이트보드를 가지고 견고하고 효율적인 솔루션을 코딩할 수 있다.
• 코딩을 할 때, 지금 작성해야 하는 모든 단위 테스트를 죄책감을 느끼며 생각한다. 이윽고 각 단위 테스트를 손으로 짜는 대신 테스트 코드 및 유효성 검사(validation)를 생성할 수 있는 모든 방법에 대해 생각하게 된다.
• 최종 사용자(end user)란 API 호출을 하는 사람이라고 생각한다.
• 부실하게 작성된 API 문서를 보면 짜증이 나지만 애초에 그 API가 왜 흥미로운지 때때로 잊어버린다.
• 코드 최적화나 경합 조건(race conditions) 찾기에 열광하는 사람들과 어울리고 있는 자신을 발견한다.
• 다른 사람과 IRC(Internet Relay Chat)나 체크인 시 코멘트를 통해 의사소통하는 것을 선호한다.
• GUI보다 커맨드라인을 선호하고 마우스를 거의 만지지 않는다.
• 내 코드가 그 알고리즘과 테스팅 알고리즘에 구애받지 않고 수천 대의 머신에서 실행될 수 있기를 꿈꾼다(순전히 CPU 사이클과 네트워크 패킷 수만을 통해 코드 정확성을 보여줌).
• 내 데스크탑 배경(background)을 신경쓰거나 커스토마이징한 적이 없다.
• 컴파일러 경고를 보면 불안해진다.
• 제품을 테스트해 달라는 요청을 받으면 소스 코드를 열고 어디를 모형으로 대체(mocked out) 할지에 대해 생각하기 시작한다.
• 내가 생각하는 리더십이란 모든 사람이 활용할 수 있는 또는 테스트 서버가 하루에 수백만 번 실행할 수 있는 훌룡한 저수준(low-level) 단위 테스트 프레임워크를 구축하는 것이다.
• 누가 내게 제품이 출시 준비가 되었는지 물으면 "모든 테스트가 통과된다"라고 답한다.

 

다음의 경우는 TE에 가깝다.

• 기존 코드를 가져와서 에러를 찾고 해당 소프트웨어의 가능한 실패 모드(failure modes)를 즉시 이해할 수 있지만, 그걸 처음부터 코딩하거나 변경하는 데는 크게 관심을 가지지 않는다.
• 하루 종일 다른 사람의 코드를 읽는 것보다 Slashdot이나 News.com을 읽는 것을 선호한다.
• 반쯤 작성된 제품 명세서를 읽고 공백인 부분 모두를 직접 채워 문서에 병합할 수 있다.
• 사람들의 삶에 큰 영향을 미치는 제품을 만드는 데 참여하고, 사람들이 당신이 참여한 제품을 알아보는 것을 꿈꾼다.
• 일부 웹사이트의 UI에 끔찍한 충격을 받은 적이 있으며, 그들이 어떻게 사용자를 확보할 수 있었는지 의아하다.
• 데이터 시각화에 흥미를 느낀다.
• 실제 현실 세계에서 인간과 대화하고 싶은 자신을 발견한다.
• 특정 텍스트 편집기에서 입력을 시작하기 위해 왜 "i"를 쳐야 하는지 이해하지 못한다.
• 내가 생각하는 리더십이란 다른 엔지니어의 아이디어를 육성하고 그들의 아이디어에 훨씬 더 큰 규모로 도전하는 것이다.
• 누가 내게 제품이 출시 준비가 되었는지 물으면 "제 생각엔 준비된 것 같습니다."라고 말한다.

 

테스터는 스스로가 누구인지 파악하는 것이 중요하다. 종종 TE를 코딩을 많이 하지 않는 또는 잘 하지 못하는 SET로 단순히 간주한다. 실제로는 하루 종일 코드에 머리를 파묻고 있는 사람은 절대 볼 수 없는 것들을 보는 사람이 TE이다. 또한 SET도 자신이 TE가 아님을 깨달아야 한다. UI 이슈를 찾는다거나 시스템 전체 또는 경쟁 제품에 대해 생각해야 한다는 죄책감이나 압박을 버리고 대신 고품질의, 테스트가 용이하고, 재사용이 용이한 모듈 및 자동화에 집중해야 한다.

 

훌룡한 제품을 만들어 내기 위해서는 다양한 테스터 패밀리가 필요하다.