저자 : 제임스 휘태커 , 제이슨 아본 , 제프 카롤로
출판사 : 에이콘출판
출판일 : 2013.03.29
구글은 소프트웨어 테스트를 어떻게 하는지 구글의 테스트 디렉터 '제임스 휘태커'가 쓴 책이다.
구글 검색, 애드센스, 지메일, 구글 앱스, 구글 지도, 안드로이드, 유튜브, 크롬과 크롬OS 등 구글은 많은 히트 작을 갖고 있다.
제품 구성도 다양해서 그 제품이 지메일처럼 내부 개발인지, 유튜브처럼 외부 구매인지를 따지지 않는다.
또, 구글 검색처럼 소비재인지 애드센스처럼 기업용인지도 따지지 않고, 안드로이드처럼 대규모 사용자를 바탕으로 한 제품인지 크롬OS처럼 벤처정신의 제품인지도 따지지 않는다.
결론은 그냥 다 잘 만든다.
물론 구글의 모든 제품이 성공하는 것은 아니지만, 이렇게 성공하는 제품을 계속 출시하는 것은 하나를 성공시키고 유지하는 것보다 휠씬 더 대단한 일이다.
그리고 같은 개발자 입장에서 이런 대단한 성공에는 분명 무시무시한 전략과 이를 현실케하는 더 무시무시한 개발 문화가 있을 것이라고 생각한다.
본격적인 테스팅을 하지 않은, 개발하기에 급급한 일개 개발자가 이 책을 제대로 소화하기란 쉽지 않다.
샘플 코드가 쏟아지고, 데모 스크린 샷이 여기저기 있진 않지만, 소문듣고 찾아온 과객이 제대로 이해하기에는 어려운 내용이 많다.
그래서 나는 테스트 방법론 혹은 테스팅 툴에 대한 자세한 설명은 쉽게쉽게 건너 뛰고, 이런 방법론과 툴을 만들 수 있었던 구글의 문화, 관리 기법에 더 관심을 갖기로 했다.
... 지금까지 내 모든 이야기 중 구글에 대한 한 가지는 분명하다. 구글은 전산학과 코딩 기술을 존중했다. 결국 테스터가 이 클럽에 동참하려면 훌륭한 전산학 지식과 몇 가지 절묘한 코딩 기술을 갖고 있어야 했다. 일등 시민이 되기 위해선 반드시 갖춰야 할 요소였다.
... 불만이 있는 사람들에 대해 내 상사는 이렇게 이야기했다. "여긴 구글이야, 뭔가 하고 싶으면 해야지."
... 구글에서는 생산성 혁신 팀(Engineering Productivit Team)이라 불리는 중앙 조직에서 소프트웨어 테스팅을 담당한다. 생산성 혁신 팀은 개발자와 테스터의 툴 체인을 수행하고, 단위 테스팅부터 탐색적 테스팅에 이르는 모든 분야의 테스팅과, 그에 관련된 공학적인 방법을 만들며, 검색, 광고, 앱, 유튜브 등 모든 웹 특성과 관련된 공용 툴과 테스트 인프라스트럭처를 다룬다. 생산성 혁신 팀을 통해 구글은 속도와 규모에 관한 여러 가지 문제를 해결했으며, 대기업이 됐음에도 불구하고 시작 단계의 벤처와 같은 속도로 소프트웨어를 릴리스할 수 있게끔 했다.
... 품질과 테스트가 동치는 아니다. 하지만 품질을 이루기 위해서는 개발과 테스팅을 믹서기에 함께 넣고 구분되지 않을 정도로 섞어야만 한다. ... 품질 활동은 잘못된 부분을 발견해 수정하는 활동이 아니라 발생하기 전에 예방하는 활동에 가깝다는 것을 뜻한다. 품질은 개발 관련 문제이지 테스팅에 관한 문제가 아니다.
... 소프트웨어 엔지니어(SWE, SoftWare Engineer) 전형적인 개발자다. 많은 양의 테스트 코드를 작성하고, 거의 100%에 가까운 시간을 코드 작성에 사용한다.
... 테스트 소프트웨어 엔지니어(SET, Software Engineer in Test) 역시 개발자다. 단지 SET의 경우 테스트 가능성(testability)과 테스트 인프라스트럭처에 포커스가 맞춰져 있다는 점이 다르다. SET는 SWE 코드베이스에 같이 참여하지만, 새로운 기능 추가나 성능 향상보다는 품질 향상과 테스트 커버리지 향상에 집중한다. SET 역시 100%에 가까운 시간을 코드 작성에 할애하지만, 고객이 사용할 기능보다는 품질에 관한 서비스 기능을 만드는 데 집중한다.
... 테스트 엔지니어(TE, Test Engineer) 테스트를 하되, 반은 사용자의 입장에서, 나머지 반은 개발자의 입장에서 테스트한다. 프로젝트의 마무리 단계에서 릴리스 일정을 지키기 위해 압력을 넣는 역할을 한다. TE는 제품 전문가이며, 품질 조언자이고, 리스크 분석가이다.
... 테스터는 기본적으로 상품화 팀에 서비스를 제공하며, 품질 관련 논의를 자유롭게 제시할 수 있고, 테스터가 놓치거나 수용할 수 없는 버그 비율을 보여주는 기능 영역에 대해 질문할 수 있다. 개발 팀이 테스팅에 대해 지름길을 원한다면 미리 협의해야 하며, 우리는 어떤 경우에든 No라고 말할 권리가 있다.
... 완벽한 제품의 컨셉을 갖고 가능성을 타진하기도 전에 품질에 초점을 두게 되면 우선순위를 거꾸로 작업하는 꼴이 된다. 우리가 보아온 구글 20% 활동이 만들어낸 많은 초기 프로토타입이 개발 먹기(dog fooding)나 베타 버전쯤 됐을 때 오리지널 코드는 약간밖에 남아 있지 않으며, 결국 거의 다시 설계됐다. 실험적인 경우에 대해 테스트를 수행하는 일은 확실히 바보들이나 하는 짓이다.
... 이렇게 구글의 문화는 다르다. 단순히 프로젝트가 존재한다고 해서 테스팅 자원을 얻지는 못한다. 개발 팀은 테스터에게 도움을 요청하고 그들의 프로젝트가 매우 흥미롭고 잠재력이 많음을 확신시킬 책임이 있다. ... 우리는 프로젝트 초기에는 관여하지 않지만, 프로젝트가 실체화되면 어떻게 수행할 것인지에 대해 많은 영향력을 갖게 된다.
... 좋은 SET가 고려하는 항목 : 규모에 대해 생각한다. 재사용을 생각한다. 안전성에 대해 생각한다. 확장성에 대해 생각한다. 불변 인자에 기반을 둔 최적화를 고려한다. 안전성을 고려한다.
... ACC(Attribute, Component, Capability) 분석. 1) 제품의 목적과 목표를 설명하는 형용사와 부사, 2) 제품의 여러 부분과 기능을 일컫는 명사, 3) 제품이 실제로 수행하는 것을 지칭하는 동사다.
애트리뷰트는 시스템의 목적과 목표를 설명하는 형용사다. 이러한 형용사들은 제품을 경쟁 제품과 대비해 향상시키는 품질과 특성이다. 이것들은 고객들이 다른 경쟁사 제품 대신 우리의 제품을 선택하는 이유에 대한 설명이 될 것이다.
컴포넌트는 목표하는 시스템을 만들기 위해 함께 사용되는 벽돌과 같은 것이며, 어떤 소프트웨어인가를 결정짓는 주요 코드 부분들이 컴포넌트다.
캐퍼빌리티는 사용자 명령을 수행하는 시스템 동작을 말한다. 캐퍼빌리티는 입력에 대한 반응이며. 질의에 대한 대답이고, 사용자의 목적을 달성하기 위해 완료하는 활동이다.
... 온라인 쇼핑 사이트의 개퍼빌리티 예
- 장바구니에서 항목 추가/삭제하기. 장바구니 컴포넌트의 캐퍼빌리티로서 '직관적인 UI' 애트리뷰트를 다룬다.
- 신용카드 정보를 수집하고 데이터를 검증하기. 장바구니 컴포넌트의 캐퍼빌리티로서 '편리한' 애트리뷰트와 '통합된' 애트리뷰트를 다룬다.
- 배송비 계산하기. 이것은 '빠른'과 '보안' 애트리뷰트를 다루는 배송 컴포넌트의 캐퍼빌리티다.
- 재고 여부 보여주기. 이것은 '편리한'과 '정확한' 애트리뷰트를 다루는 검색 컴포넌트의 캐퍼빌리티다.
... 특히 TE는 알고리즘, 이론 증명, 기능 구현에 있어 최고가 아니기 때문에 직무에 적합한 사람을 채용하기란 어려울 수밖에 없다. ... 그들은 기술적이고, 사용자 입장을 고려하며, 제품을 체계적으로 최종 사용자의 관점에서 이해하는 사람들이다. 그들은 수그러들줄 모르는 훌륭한 교섭자이며, 그리고 무엇보다 중요한 것은 그들은 창의적이며, 애매모호한 것을 처리할 수 있다는 점이다.
... 구글 피드백(Google Feedback). 퀼리티 봇(Quality Bots). 셀레니엄(Selenium). 웹드라이버(WebDriver). 브라우저 통합 테스트 환경(BITE, Browser Integrated Test Environment). 기록/재생 프레임워크(RPF, Record and Playback Framework). 구글 테스트 케이스 매니저(GTCM, Google Test Case manager). 구글 테스트 분석(GTA. Google Test Analytics)
... 테스트 엔지니어(TE)와 테스트 소프트웨어 엔지니어(SET)가 사용자와 개발자 각각을 지원하기 위해 노력하는 동안 그들을 하나로 묶는 역할이 있다. 바로 테스트 엔지니어 매니저(TEM, Test Engineering Manager)다. TEM은 구글의 모든 위치 중 가장 도전적인 위치이고, TE와 SET 모두에게 필요한 기술을 알아야 한다. 또한 경력 개발 시에 필요한 보고서를 직접 만들 수 있는 관리 스킬도 필요하다.
... 구글 직원은 한 분기 정도의 차이는 있을지 모르지만 18개월마다 프로젝트를 변경할 수 있다는 점이다. ... 어떤 TEM이든 사내 공모를 하고, 어떤 TE 또는 SET든 새로운 기회를 볼 수 있다. 사내 공모를 하기 전에 현재 또는 향후 관리자들에게 어떠한 공식적인 승인도 받을 필요가 없다. ... 일반적으로 엔지니어가 프로젝트 A에서 프로젝트 B로 이동할 때 엔지니어는 한 분기 동안 20%의 시간을 새로운 프로젝트 B에 쏟고, 다음 분기에서 20%의 시간을 기존 A 프로젝트에 대해 사용하고, 프로젝트 B에 80%의 비율로 사용한다.
... 프로젝트를 선택하는 데 있어 TEM이 갖는 일반적인 규칙은, 나쁜 프로젝트는 피하라는 점이다. 품질에 있어 동등한 파트너십을 꺼려하는 팀에게는 테스팅을 그들 스스로의 일로 남겨두게 한다. 소형 테스트와 훌륭한 단위 레벨의 커버리지를 만들기 싫어하는 팀은 조용히 스스로의 무덤을 파게 된다.
... 그들이 협업하는 진짜 이유는 다른 팀과의 협업을 하면 아주 놀라울 만한 혁신을 일으킬 수 있기 때문이다. 그 누가 영향력 있는 새로운 툴을 사용하지 않는 유일한 테스터가 되고 싶겠는가? 또한 누가 스마트하게 일하고 싶지 않겠는가?
... 전 복잡하게 생각하지 않고 어려운 문제에 직면하면 그 문제를 해결할 수 있게 구체적인 단계로 변환할 수 있는 사람을 찾습니다. 물론 그 문제를 해결해야겠지요! 시간에 쫓기기보다는 적극적이고 열정적으로일을 하는 사람이 필요합니다. 혁신과 품질 사이에서 균형을 이룰 수 있어야 하고, 단순하게 찾을 수 있는 버그 이상을 찾아낼 수 있는 생각 있는 사람이 필요합니다. 그리고 그 무엇보다도 열정이 보이길 바랍니다. 정말로 테스터가 되길 원하는 사람을 바랍니다.
... 탐색적 테스팅이 제품을 파헤쳐가면서 제품을 익히는 최선의 방법입니다. ... 필요할 때는 모든 SET가 TE처럼 행동할 때도 있고, 그 반대의 경우도 있습니다. 전 직책에 그리 크게 신경 쓰지 않습니다. 가치를 부가하는 것에 더 많은 관심을 갖죠. ... 일일 빌드를 통해 나오는 S/W를 테스트하기 위해 그 안에 무엇이 있는지 밀착해서 분석합니다. 우리는 테스트를 해야 할 중요한 부분을 식별하기 위해서 조율 회의(coordination meeting)를 매일 수행하고, 해당 부분의 담당자가 누구인지를 확인합니다. 제게 있어 수동 테스트의 핵심은 집중과 조율입니다. ... 모든 기능은 각각 고유의 속성이 있고 수동 테스터들은 추후 이 기능을 테스트하게 될 다른 테스터들을 위해 이를 문서화해 가이드라인을 작성합니다. 따라서 일반적인 시스템 레벨의 유스케이스에 대한 테스트 문서와 기능 특화된 가이드라인을 작성하는 데 시간을 쏟습니다.
... 테스트 디렉터(Test Director) 여러 제품의 여러 매니저를 이끄는 역할이다. 그들의 초점은 어떻게 품질과 테스팅이 비즈니스에 영향을 미치는지, 때로는 외부 업계와의 공유에 대해 집중한다. 그들은 고위급이나 클라이언트, 애플리케이션, 광고 등과 같은 '핵심 분야'와 밀접하게 업무를 진행한다.
... 시니어 테스트 디렉터(Senior Test Director) 구글에는 직무 기술, 고용, 외부와의 커뮤니케이션, 그리고 전반적인 구글의 테스팅 전략을 위해 일관된 접근을 해야 하는 고위 리더십의 의무를 가진 사람이 딱 한명 있다(패트릭 코플랜드). 그의 업무는 종종 모범적인 경영 사례 중 하나로 공유되고, 글로벌 빌드 또는 테스트 인프라스트럭처, 정적 분석, 구글의 제품, 사용자 이슈, 코드 기반을 폭넓게 포괄하는 테스팅 활동들에 대해 새로운 계획을 창조하고 추진하는 일을 한다.
... 구글은 특출 나게 자기 동기 부여가 잘되는 사람들을 고용했어요. "내가 그렇게 하라고 했잖아"라는 건 한 번 정도 먹힐 뿐이지만, 이 스마트한 사람들은 시작을 하고 수십 번 생각한 후에 자신이 생각한 최선을 수행합니다. 가이드를 해주고, 통찰력을 제공하고, 제 사람들에게 문을 열고 그들이 가장 열정을 쏟아 붓고 싶어하는 일을 하게 해서 대부분 적극적으로 일을 수행하게 합니다.
... 제가 시작할 때 패트릭 코플랜드는 두 개의 조언을 해줬습니다. 첫 번째는 "오로지 배우기만 하는 시간을 가져라"였습니다. 처음 몇 달 동안은 패트릭이 제안한 대로 했습니다. 말하는 대신 듣고, 시도하는 대신 질문했습니다. 두 번째는 제가 그렇게 좋아하지는 않습니다만, 더 좋은 조언이라고 판명이 났습니다. 그는 제 옆으로 와서 이야기했습니다. "이봐 친구, 난 자네가 구글 밖에서는 명성이 있는걸 알지만, 자넨 아직 내부에서 이룬 것이 하나도 없네." 그의 메시지는 항상 명확하고 이번 메시지는 "그전에 제가 무엇을 했던지 간에 구글은 상관하지 않는다."라는 것이었습니다.
... 첫 번째 미팅 때 우린 두 개의 목록으로 시작했어요. 무엇이 TE라는 역할을 흥분하게 만들고, 무엇이 TE라는 역할에 회의감을 들게 하면서 미치게 만드는지. 단지 이 목록을 만드는 것만으로도 많은 참석자들에게 카타르시스를 느끼게 했어요.
... 테스팅은 주로 품질을 대변하는 것으로 보이며, 개발자에게 품질에 대해 무엇을 하고 있냐고 물어보면 '테스팅'이라고 주로 대답한다. 하지만 테스팅이 품질은 아니다. 품질은 녹아 들어가는 것이지 덧붙이는 것이 아니므로 품질은 개발자의 업무다. 더 이상 다른 말은 필요 없다. 그런 생각들이 테스터들은 개발자의 보조라는 첫 번째 심각한 결함을 가져온다. 결국 테스팅에 대해 많이 생각하지 않고, 테스팅을 쉽게 생각하고, 결국에는 더 적은 테스팅을 할 것이다.
... 사용자들은 제품과 사랑에 빠지지 그것을 만드는 프로세스와 사랑에 빠지진 않는다.
... SET의 미래. 대학을 졸업하고 고용된 신입 개발자들은 시작하기 좋은 곳으로 테스트 개발을 찾는다.. 전체 프로젝트를 이해할 수 있는 기회뿐만 아니라, 많은 테스트 코드들이 사용되는 것은 아니기 때문에 압박을 덜 수 있고, 사용자가 직면할 버그에 대한 잠재적인 부담(나중에라도 느낄)을 덜 수 있다. ... 새로운 멤버가 오면 기존의 테스트 개발자들은 기능 개발로 옮겨 새로운 엔지니어에게 길을 터준다. 신입 엔지니어들은 시간이 지남에 따라 능력이 좋아지고, 품질을 진지하게 다루게 된다.
... TE의 미래. 테스트 엔지니어링은 테스트 설계 역할로 변화해야 한다. ... 테스터들이 피드백을 주면 TE는 커버리지를 확인하고 리스크 영향을 계산하고, 그 경향이 줄어들고 있음을 확인하고, 테스팅 활동을 적절히 조정한다. ... 이러한 업무들은 테스트 생성도 없고, 테스트 수행도 없고, 실제 테스팅 자체가 없다. '없다'라는 것은 너무 강력한 표현일지도 모르겠지만, 여하튼 그러한 업무들이 매우 최소화된다. 우리가 생각하기에 TE는 보안 전문가와 같은 역할을 갖거나 다른 이들이 수행하던 테스팅 활동의 관리자가 될 것이다.
... "부록 B. 크롬에 대한 테스트 투어"는 테스트에 재미있는 여행 이름을 부여했다.
... 중간에 언급된 각종 툴에 대한 더 자세한 내용이 "부록 C. 툴과 코드에 대한 블로그 포스트"에 준비되어 있다.
소프트웨어 테스팅 마이크로소프트에선 이렇게 한다
저자 : 앨런 페이지 , 켄 존스톤 , 비제이 롤리슨
출판사 : 에이콘출판
출판일 : 2009.12.01
책에도 나오지만, 구글이 소프트웨어 개발 테스팅의 르네상스를 열었다면, 그 처음의 태생은 마이크로소프트의 활동이라 할 수 있을 것이다.
다음엔 이 책을 읽어야겠다.
'정보, 통신, 기술 > 읽은 것들' 카테고리의 다른 글
| 클라우드의 충격 (0) | 2015.06.29 |
|---|---|
| [서평] 능률적인 프로그래머 (0) | 2015.01.31 |
| Node.Js 노드제이에스 프로그래밍 (0) | 2013.06.16 |
| 소프트웨어 제품 마케팅 (2) | 2013.05.20 |
| 스크럼 - 팀의 생산성을 극대화시키는 애자일 방법론 (0) | 2012.09.02 |