구글은 테스트를 어떻게하는가 1

Good morning~

 

제가 얼마전 저희 센터 조직장들에게 올해 목표를 세울 때 꼭 넣으려고 하는 몇 가지 명시적 목표를 얘기한 적이 있었습니다.

그 중 하나가 "센터 전체로 보내는 메일을 이용한 기술적/비기술적 이슈 공유 5건 이상" 이라는 목표였습니다.

팀장/랩장들에게 아주 명시적으로 이것을 요구한 것인데요...

이런 전체 공유가 자연스럽게 되지 않는 분위기가 있어서 이를 어느 정도 강제한 것입니다.

현재 저희 센터의 팀/랩장님 수가 약 70명 가량 되니까 70x5=350 이네요.

그니까 올해 적어도 350개 이상의 이런 저런 메일이 센터DL을 통해 공유되어야 한다는 것이지요.

이런 시도는, 꼭 조직장만 그렇게 해야한다...는 얘기가 아니라 누구라도 그렇게 했으면 좋겠지만, 조직장이 좀 더 role model이

되었으면 좋겠다...는 얘기로 해석해 주시면 고맙겠습니다.

 

아래 예제를 하나 공유해 드릴께요.

"도대체 뭘 어떻게 공유하라는거야?" 라는 질문을 가지고 계셨다면 그에 대한 조그만 예제 입니다.

 

Have a nice holidays~

김정민

 

ps: 익명성을 지켜주기 위해서 약간 수정을 했습니다.

-----Original Message-----
Subject: 구글의 QA 활동..

요즘 “구글을 지탱하는 기술” 이라는 책을 읽고 있습니다. 

이 책은 나시다 케이스케 라는 일본인이 구글이 발표한 각종 논문 / 발표들을 종합해서 구글의 기술적인 모습은 이럴 것이라 라고 추측한 내용인데, 

이중 구글의 QA 활동을 볼 수 있는 몇 가지 사실이 적혀 있어 정리하여 공유합니다.
일부는 얼마 전에 NHN을 방문하여 구글과 야후의 개발 지원 도구라는 토픽을 강연해 주신 김성훈 박사의 발표 내용과 일치합니다.

1. 구글에서는 코드 리뷰가 필수다. 
구글의 코드 베이스는 깨끗하다. 1주일 이상의 노력이 필요한 일은 뭐가 됐든 디자인 문서를 요구하는데, 여기에는 반드시 작성해야 하는 항목이 있고, 

직접 고른 제 1, 제 2 리뷰어로부터 피드백을 받아야 한다.

2. 구글의 소프트웨어는 처리 성능을 초기부터 중시한다. 
모든 시스템의 동작을 항상 모니터링 하고, 그 동작 상황을 그래프하여, 언제든지 볼 수 있도록 한다. 

각 시스템의 데이터 처리량 또는 고장률 등도 모두 기록으로 남긴다. 이를 위해 설계 단계부터 고려한다.

3. 정보는 철저히 공유된다.
메일링 리스트, 사내 블로그를 통해 정보를 공유한다. 

사내 포털, Wiki, Google Docs에 프로젝트 상세 기술문서와 신입사원 교육용 문서를 정리한다.
각종 아이디어와 프로젝트의 진척, 버그 정보는 DB화하여 누구나 언제라고 참고할 수 있다.
그리고 모든 코드는 사내에 공유된다.

4. 개발에 사용하는 언어는 C++, Java, Python, Sawzll, Javascript 등으로 제한한다.
예를 들어 구글에서는 루비 등을 사용할 수 없다. 그리고 코딩 스탠다드를 철저히 지킨다. 

5. SCM 시스템으로는 상용인 Perforce를 이용한다.
전세계적으로 공유되는데, 원칙적으로 단일 소스 트리에 저장한다. 

리파지토리에 코드를 넣기 위해서는 리뷰 등의 프로세스를 거쳐야 하는데, 개발자가 자유롭게 브랜치를 만들 수는 없는 것 같다.  

리뷰가 끝나기 전에 소스 코드는 NFS 상의 개발자 홈 디렉토리에 보관되어 있고, 여기서는 개인적으로 버젼관리를 해야한다. 

이때 일관된 체계는 없는 것 같다. 

4000명이 막강한 Perforce 서버 1대에 붙어 소스 관리한다. (듀얼코어 * 4 Cpu, 128GB 메모리) 그러나 요즘 요게 한계에 부딪친 것 같다.

6. 소스 코드 리뷰에는 2006년부터 Mondrian이라는 독자적인 시스템을 사용한다. 
이 도구는 파이썬을 만든 귀도 반 구스 인가 하는 사람이 구글에 입사해서 만들었다..

7. 테스트 엔지니어 팀
구글에서는 각 프로젝트 팀과 모든 프로젝트에 공통된 시스템(테스트 자동화, 국제화, 보안, 빌드 시스템)을 개발하는 팀이 있다. 

소프트웨어의 테스트에는 별도의 전문 테스트 엔지니어가 고용되며, 테스트를 자동화하기 위해 조력한다. 

개개의 프로젝트 유닛 테스트를 작성하는 것은 개발자의 역할이지만, 유닛테스트 실행에 필요한 시스템을 만드는 것과 시스템 전체의 

테스트를 담당하는 것은 테스트 엔지니어 몫이다.

8. 자동화 테스트
구글은 테스트의 자동화에 적극적으로 노력한다. 

개발자와 테스트 엔지니어는 곁에서 서로의 작업을 진행시키는 등 개발 초기 단계부터 테스트 자동화를 의식하며 소프트웨어를 만들도록 하고 있다. 

문제의 복잡함을 줄이기 위해 API 설계에 주의를 기울인다. API 레벨에서 꼼꼼한 테스트를 수행한다. 

구글 테스팅 블로그에는 자동화를 성공시키기 위해 다음과 같은 것이 필요하다고 했다.

-    시스템의 내부적인 디테일과 외부 인터페이스를 모두 고려
-    각 인터페이스(UI 포함)를 위한 대량의 고속 테스트 준비
-    가능한 낮은 레벨에서 기능 검증
-    end-to-end 테스트 양식 준비
-    개발과 병행하여 자동화에 대비해 작업을 시작한다.
-    개발과 테스트 사이의 장벽(공간적, 조직적, 프로세스)을 극복한다.
-    개발팀과 같은 도구를 사용한다.

9. 화장실 테스팅
구글의 테스트 추진 활동의 일환으로 Testing on the Toilet 이라는 것이 있다. 

이는 소프트웨어 테스트를 쉽게 하는 요령을 정리한 문서로 구글 화장실에 붙어 있고, 구글 블로그에도 포스팅 되어 있다.