티스토리 뷰

지난번 포스트로 구글 테스팅에 관한 소개는 끝인줄 알았는데휘태커 아저씨가 구글 테스팅에 대해 소개할 말이 아직도 많이 남았나 봅니다. “Stay tuned!”라고까지 하시는군요.

짤방은 최근 구글이 야심차게 진행하고 있는 Google Art Project이것도 엄청나네요.
시간 나실 때 방문해 보실 것을 권장해 드립니다!


How Google Tests Software – Part Six

Monday, May 02, 2011 12:05 PM

 

By James Whittaker

 

The Life of an SET

 

SET는 테스트 소프트웨어 엔지니어(Software Engineer in Test)를 말한다. 이들은 기능성 테스팅 작성을 담당하는 소프트웨어 엔지니어들이다. SET는 다른 어떤 테스터들보다 개발자에 가까운 사람들이다. 구글의 채용 문구나 내부 승진 요건에서도 100% 코딩을 하는 역할로 알려져있다. SET에 지원한 사람의 면접이 진행될 때, 이들에게는 SWE와 거의 비슷한 역할이 요구되지만 자신들이 만든 코드를 어떻게 테스트 할지 알아야 한다는 점이 더욱 부각된다. , 이는 SWE SET 둘 다 코딩에 관한 질문에는 능숙하게 답할 정도가 되어야 한다는 것을 의미한다. SET는 여기에 더해 테스팅에 관한 질문에도 답변을 할 수 있어야 한다.

 

이미 예상할 수 있듯이, 이 역할에 필요한 요구사항을 충족시키기는 것은 결코 쉬운 일이 아니다. 하지만 구글의 몇몇 SET들이 이러한 요구사항을 충족시킬 수 있었던 이유는, 구글이 생산성에 관한한 혁신적인 공식을 만들어 내서가 아니라 SET들이 이러한 스킬들을 갖추기 힘들다는 현실을 인정하고 받아들인 결과라고 할 수 있다. 우리는 이 중요한 일을 이 일을 직접 수행하는 사람 중심으로 최적화하고 프로세스를 만들었다.

 

제품 설계 단계의 초반에는 SET들이 포함되지 않는 것이 일반적이다. 이러한 배제는 의도된 것이 아니라 수많은 구글의 제품이 태어나는 과정을 거쳐 생긴 부산물이다. 새롭게 시작하는 프로젝트 중 20% 정도만이 구글의 브랜드를 달 수 있는 제품으로 살아남는 것이 일반적이다. 구글과 크롬 OS 둘 다 구글이 공식적으로 지원하지 않은 아이디어로부터 시작했으며, 시간이 지날수록 개발 팀과 테스트 팀이 참여하는 공식적인 제품으로 성장한 것이다. 이같은 경우 초기의 개발 활동은 품질이 아니라 제품의 컨셉을 증명하고 제품 규모와 성능이 합리적인 것인가를 밝히는데 집중된다. 측정조차 할 수 없는 웹 서비스가 있다면, 테스팅이 가장 큰 골치거리는 아닐 것이기 때문이다.

 

제품이 지속적으로 만들어지고 생산하기로 확실하게 결정이 되면 그때부터 개발팀은 테스트가 가능한 환경을 만들기 시작한다.

 

이후의 개발 프로세스는 다음과 같이 진행될 것이다. 누군가가 아이디어를 만들어 내고, 이에 대해 고민하고, 시험적으로 코드를 작성해본다. 다른 사람들에게 이에 대한 의견을 물어보고, 좀 더 많은 코드를 작성하고, 또 다른 사람들이 이 작업에 참여하고, 더 많은 코드를 작성하고, 그들이 무언가 중요한 일을 하고 있구나라고 깨닫고, 더 많은 코드를 통해 그들의 아이디어를 구현하고 다른 사람들에게 피드백을 받는다이 단계에서 실제로 수행될 프로젝트들이 구글의 프로젝트 데이터베이스에 기록되고 시작된다. 테스터들은 프로젝트가 구체화 될 때까지 포함되지 않는다.

 

그럼 구체화된 모든 프로젝트에 테스터가 포함될까? 모두 그런 것은 아니다. 일부 제한된 사용자들을 대상으로 하는 소수의 프로젝트들은 이를 개발한 사람들만 테스트에 참여한다. 제품을 사용하는 사용자나 기업(후자가 조금 더 위험하다)에 조금 더 리스크를 안길 수 있다고 판단되는 프로젝트들은 테스팅에 좀 더 신경을 많이 쓰게 된다.     

 

테스터들에게 도움을 요청하고 그들의 프로젝트가 흥미롭고 잠재력이 있다는 것을 부각시킬 책임은 바로 개발팀에 있다. 개발 관리자(Dev Directors)들이 그들이 수행하는 프로젝트와 진행 상황, 출시 예정일 등을 테스트 관리자(Test Director)에게 설명한다. 이후 그들은 함께 테스팅 업무를 어떻게 나눌 것이며, SWE가 테스팅에 포함될 것인지, 어느 정도 수준의 유닛 테스팅을 수행할 것인지, 그리고 릴리즈 프로세스에 관한 의무를 어떻게 공유할 것인지에 대해 논의하게 된다. 프로젝트가 시작되는 단계에서는 아직 SET가 소속되어 있지 않을 수도 있다. 그러나 한 번 프로젝트가 구체화되기 시작하면, 업무를 진행하는데 상당한 영향력을 행사하게 된다.

 

내가 테스팅이라고 말하는 것은 단순히 코드 경로를 탐색한다는 것을 의미하는 것은 아니다. 초기 단계에는 테스터들이 포함되지 않을 수도 있다. 하지만 테스팅은 수행되고 있다. 사실, SET의 영향력은 개발자들이 빌드에 자기의 코드를 서밋하기 위해 체크하기 전부터 느낄 수 있다. 내가 무슨 말을 하는건지 계속 듣고 싶다면 채널 고정!