[번역] How Google Tests Software - Part One

최근 페이스북이나 트위터 등 여러 소셜 네트워크 서비스에서 “페이스북에는 테스팅을 전담하는 조직이
없다”라는 내용이 화제가 된 적이 있습니다. 여기에 대해 국내에서도 이런 저런 논의가 많았었죠.
마찬가지로 지난 1월부터 구글 테스팅 블로그에 올라오고 있는 제임스 휘태커(James Whittaker)의 포스트 “How Google Tests Software” 시리즈도 화제에 오르고 있습니다. 페이스북과 마찬가지로 구글에서도
개발자들이 테스팅을 원활하게 수행하도록 하기 위해 테스팅 조직이 존재한다는 것입니다. 
그 외에도 사람들이 궁금해 하는 구글에서의 테스팅 방법에 대해 많은 내용이 올라와 있습니다.  

 

저는 자잘한 내용들을 조금 더 보충해 전문을 번역한 것 뿐이고, 핵심적인 내용은  

흥배님의 블로그 포스트 『구글의 소프트웨어 테스트 방법』에 잘 정리되어 있습니다. 
 

이 글을 빌어 번역에 많은 도움 주신 흥배님에게도 다시 한 번 감사의 말씀 드립니다. 
이 글의 번역은 원문 포스트 댓글을 통해 저자로부터 승인을 받았습니다.    

PS>  구글의 내부 조직을 잘 모르니 조직 명칭과 같은 부분들을 정확하게 번역하기 힘드네요. 
       구글에 재직하고 계시거나 조직을 잘 아시는 분들이 있으시면 정확한 한글 명칭 좀 알려주세요.

이 글은 ‘구글이 어떻게 소프트웨어를 테스트 하는가’라는 주제의 포스트 연작 중 첫 번째 글이다.

 

내가 정말 궁금했던 문제도 바로 ‘과연 구글은 어떻게 테스트하고 있을까?’였다. 이 문제에 대해서는 구글
테스팅 블로그에 낱낱이 잘 설명되어 있기는 하지만 업데이트될 필요가 있을 것 같다.

구글의 기본적인 테스팅 전략은 변한 것이 없다.
하지만 회사가 점점 발전해 나감에 따라 우리가 수행하는 테스트의 접근 방식 역시 같이 진화해 왔다.
이제 구글은 검색, 앱, 광고, 모바일, OS 등의 다양한 사업 분야를 가진 회사로 발전했다.
각각의 집중 영역(Focus Areas; 우리는 이 분야들을 이렇게 부른다)들은 문제가 발생할 만한 부분에 대해
합리적으로 대처해 나가야 한다. 새로운 집중 영역이 추가되고 해당 분야의 사업이 성장하게 되면, 그 분야에서 우리가 수행하는 테스트 역시 그 범위가 넓어지고 개선된다.

이번 연작에서 나는 오늘날 우리 구글 테스팅 팀이 어떤 일을 수행하고 있는지, 그리고 향후 예측가능한 미래에 우리가 어떤 방향으로 나아가고자 하는지에 대해 다루고자 한다.

 

우리 조직의 구조를 살펴보는 것부터 시작해보자.
우리 조직에 대해 알고 나면 많은 사람들이 무척 놀랄 것이다.

구글에는 실질적으로 테스팅을 수행하는 조직이 존재하지 않는다
(There isn’t an actual testing organization at Google).

테스트는 엔지니어링 생산성(Engineering Productivity)이라고 부르는 집중 영역안에 존재한다.
엔지니어링 생산성 조직에는 수많은 엔지니어링 부서가 포함되어 있으며, 그 중 테스트는 가장 큰 부분을
차지한다.
엔지니어링 생산성 조직은 다음과 같이 구성되어 있다.

 

1.     프러덕트 팀(A product team)은 회사 전반에 걸쳐 다양하게 사용되고 있는 내부 오픈 소스 툴을
만드는 팀이다. 이 팀은 코드 분석기(Code analyzers), IDE, 테스트 케이스 관리 시스템, 자동화
테스팅 툴, 빌드 시스템, 소스 제어 시스템(Source control system), 코드 리뷰 스케줄러(Code review schedulers) 그리고 버그 데이터베이스 등을 만들고 유지보수 하는 일을 수행한다. 
엔지니어들은 이들이 만든 툴을 사용해 작업의 생산성을 더 높일 수 있다.
이들이 만들어 내는 툴들은 단순히 버그를 검출해 내는 것을 뛰어넘어 사전에 버그를 예방하고자 하는 구글의 전략적인 목표에서 아주 큰 부분을 차지하고 있다.

 

2.     서비스 팀(A service team)은 툴, 문서화, 테스팅, 릴리즈 관리(Release management), 교육 훈련
등의 다양한 분야에서 구글 프러덕트 팀에게 전문적인 지식과 서비스를 제공해주는 팀이다.
이 팀의 전문 지식과 서비스는 제품의 신뢰성(reliability), 보안(security), 국제화(internationalization)와 같은 분야를 커버할 뿐만 아니라 특정 제품에 특화된 기능적인 이슈까지 커버한다.
다른 모든 집중 영역의 조직이 엔지니어링 생산성 조직의 전문 지식을 검색할 수 있다.        

 

3.     임베디드 엔지니어(Embedded engineers)는 그때 그때 필요할 때마다 프러덕트 팀에 투입된다.
어떤 엔지니어들은 같은 프러덕트 팀에서 수 년 동안 일할 수도 있지만, 대부분 그들을 가장 필요로
하는 팀에 기간과 상관없이 투입된다.
구글은 엔지니어들이 항상 새로운 제품을 접함으로써 업무에 집중하고, 또한 늘 객관적인 자세를
유지할 수 있도록 자주 프러덕트 팀을 바꿀 것을 권장한다. 테스터 역시 이와 다르지 않으며, 팀을
변경할 지 여부는 각 개인이 결정한다. 나는 크롬 프로젝트에서 수 년 동안 일해온 테스터들과
단지 18개월 정도만 같이 일한 테스터, 그리고 계속해서 다른 부서로 순환되는 테스터들과 함께
일하고 있다. 제품에 대한 깊은 지식과 테스터로서 가져야 하는 신선한 안목을 균형있게 유지하기
위해서는 테스트 매니저가 숙련자와 신입의 구성을 어떻게 맞출것인가에 깊은 관심을 가져야 한다.     

 

테스터들은 테스팅 업무에 관해서 엔지니어링 생산성 조직의 관리자들에게 보고한다.
이와 동시에 그들은 검색이나 지메일, 혹은 크롬과 같은 프러덕트 팀에도 속해있다.
조직도 상에서 볼 때도 그들은 이 두 조직 모두에 속해 있다.
그들은 프러덕트 팀 안에 위치하고 있으며, 프러덕트 팀의 계획 회의에 참가하고, 같이 점심을 먹으러 나가고,
그들과 함께 제품 출시 보너스를 받으며, 프러덕트 팀의 다른 직원과 동등한 대우를 받는다.

분리된 보고 구조가 제공하는 장점은 테스터들에게 정보를 공유하기 위한 포럼을 제공해 준다는 것이다.
구글에서 제안되는 테스팅 아이디어들은 엔지니어링 생산성 조직 안에서 원활하게 공유되고 모든
테스터들에게 전달된다.
어떤 제품 팀에 속해있는지와 상관없이 모든 테스터들이 회사 안에서 최고의 테크놀로지를 접해볼 수 있는
것이다.

 

프로젝트와 보고의 분리된 구조가 가지는 고유한 문제점도 있다.
가장 큰 문제점은 테스터들이 결국에는 외부의 자원으로 국한되어 있다는 것이다.
프러덕트 팀이 그들에게 너무 많은 기대를 해서도 안되지만, 항상 일정 이상의 품질이 유지될 수 있도록은
해주어야 한다.

그렇다. 구글에서 품질을 관장하는 주체는 테스터들이 아니라 프러덕트 팀인 것이다.
모든 개발자들이 직접 테스팅을 수행하도록 권장된다.
테스터들이 하는 일은 개발자들에게 테스트 자동화 인프라스트럭쳐를 제공하거나, 개발자들이 스스로의
성과물에 대해 신뢰감을 가지게 해주는 개발자 테스팅 프로세스를 만들어 주는 것이다.
테스터들은 개발자들이 테스트하는 것을 가능하도록 만들어준다.  

 

내가 이러한 전략을 좋아하는 이유는 개발자와 테스터들을 같은 출발선 상에 올려놓기 때문이다.
이는 우리를 품질에 관한한 진정한 동반자로 만들어 주는 동시에, 품질에 관해 가장 큰 책임을 져야할 사람들이 바로 그렇게 하도록 만들어주는 것이다. 개발자들이야말로 제품의 품질을 올바르게 유지하는데 가장 큰 책임을
가지고 있는 사람들이다.

이 전략의 또 다른 장점은 개발자와 테스트가 다대일(多對一) 관계를 유지하도록 해준다는 것이다.
항상 개발자들이 테스터들보다 많은 수를 유지한다.
그들이 테스팅을 더 잘 수행할수록, 테스터들보다 더 많은 수가 고용될 것이다.
테스터들보다 개발자들이 더 많은 비율을 차지하고 있는 프러덕트 팀이라면 그것을 자랑스러워해야 한다!!!

 

오케이, 자 어쨌든 우리는 테스트 업계의 허물없는 동료들이 아닌가?
아마 당신이라면, 지금 내가 말한 이 전략에 커다란 허점이 있다는 것을 알아챘을 것이다.
그 허점은 수많은 버그를 양산할 수 있을 정도로 충분히 크다.

바로 이것이다.
개발자들은 테스트를 할 수 없다는 것이다!!!

글쎄, 내가 이를 부정하는 사람처럼 보이나?
그 어떤 것도 이를 부정할 수는 없을 것이다.
특히 개발자와 테스터의 대결을 다루었던 나의 작년 GTAC 강연에서도 이 부분이 잘 다루어져 있다
(스포일러지만 그 결과를 알려주겠다: 결국 테스터가 이긴다).

 

이 문제에 대한 구글의 답은 바로 역할을 분리하는 것이다.
구글은 아주 다른 두 가지 테스팅 문제를 해결하기 위해 테스터의 역할 역시 두 가지로 분리함으로써
이 문제를 풀어나간다.

나의 다음 포스트에서 이 역할들에 대해 설명하고 어떻게 이 두 파트로 테스팅 문제를 분리했는지에 대해
설명해 보겠다.

 

-- Continue --