[번역] How Google Tests Software - Part Three

How Google Tests Software – Part Three

Wednesday, February 16, 2011 2:47 AM

 

By James Whittaker

 

구글에서 어떻게 테스트를 진행하는지에 대한 지난 두 개의 포스트에 대해 수많은 질문들이 쏟아졌다.

주요한 질문들은 다음 포스트에서 답해 줄 것이다.

자, 이번 주제에 대한 포스트를 시작해보자.

 

구글에서 품질은 테스트와 동일한 의미로 사용되지 않는다(At Google, quality is not equal to test).

사실 나는 이 명제가 구글 뿐만 아니라 어디에서나 통하리라고 믿는다. ‘품질은 테스트될 수 없다(Quality cannot be tested in)’는 문구는 그 자체가 ‘참’인 클리셰(Cliché)[1]라고 할 수 있다. 자동차에서부터 소프트웨어에 이르기까지 처음부터 올바로 만들어지지 않았다면 결코 이후에라도 올바른 것이 될 수 없다. 볼트 하나를 끼워넣어 사후 품질을 유지할 수 있다고 하더라도 이를 위해 결국 막대한 리콜을 감내해야 하는 자동차 회사에게 얼마나 값비싼 비용을 치렀는지 한 번 물어보라.

 

품질에 관한 문제는 간단하지도 않을 뿐더러, 정확할 수도 없다. 품질이 테스트될 수 없다는 것은 참이다. 하지만 테스팅 없이는 품질에 관한 그 어떤 것도 개발될 수 없다는 것 역시 사실이다. 어떻게 테스팅도 하지 않고 당신이 만들어 낸 그 무언가의 품질이 높다고 확신할 수 있겠는가?

 

이 어려운 문제에 대한 간단한 해결책은 바로 개발과 테스트를 별개의 것으로 다루지 않는 것이다. 테스팅과 개발은 손을 맞잡고 나아가는 것이다. 작은 규모의 코드를 작성하고 당신이 만든 것을 테스트 해보라. 그 이후 조금 더 많은 코드를 작성하고 조금 더 많이 테스트를 수행해보라. 이번에는 코드를 작성하는 도중에 혹은 그 이전에 테스트를 계획해 보라. 테스트는 개발과 다른 별개의 행위가 아니라, 이미 스스로가 개발 프로세스의 일부인 것이다. 품질과 테스트가 동일한 것을 의미하지는 않는다. 개발과 테스트를 믹서기에 집어넣고 둘을 구별할 수 없을 때까지 섞은 다음에야 품질과 테스트가 동일하다는 명제가 달성된다.

 

구글에서는 이것이 우리의 명백한 목표다. 개발과 테스팅을 통합해 이 중 하나를 하지 않고서는 다른 하나를 할 수 없도록 만드는 것이다. 작은 빌드를 만들고 이를 테스트 해보라. 그보다 조금 더 큰 빌드를 만들고 조금 더 많이 테스트 해보라. 여기서 핵심은 누가 테스팅을 수행하느냐이다. 구글에서 실제로 오직 테스트 업무 만을 수행하는 테스터의 수는 지극히 적으므로, 이 질문에 대한 가능한 해답은 바로 개발자가 한다는 것이다. 실제로 코딩을 한 사람보다 더 테스팅을 잘할 사람들이 누가 있겠는가? 코드를 직접 작성한 사람보다 누가 더 버그를 잘 찾아낼 수 있겠는가? 누가 가장 버그를 만들어내고 싶어하지 않겠는가? 구글에 테스트만 전문으로 수행하는 테스터들이 적은 이유는, 바로 개발자들이 품질을 책임지고 있기 때문이다(The reason Google can get by with so few dedicated testers is because developers own quality). 사실, 테스팅에 많은 비중을 두는 팀들은 일반적으로 뭔가 잘못되어가고 있다고 간주되기 십상이다. 대규모의 테스트 팀을 가지고 있다는 것은 코드/테스트의 조합이 균형을 이루고 있지 못함을 보여주는 강력한 신호이다. 테스터를 더 투입한다고 해서 문제가 해결되는 것은 결코 아니다.

 

이 말은 곧, 품질은 결함 검출보다 예방 활동에 더 가깝다는 것을 의미한다(This means that quality is more an act of prevention than it is detection). 품질은 개발 관련 이슈이지, 테스팅 관련 이슈가 아니다. 이를 좀 더 확대 해석해 보면, 개발 활동의 일부로 테스팅 활동을 구현할 수 있다는 것을 의미한다. 만약 하나의 증분(increment)에 버그가 너무 많은 것으로 판명된다면, 그 실수를 롤백 할 수 있는 프로세스를 만들어낼 수 있었다. 우리는 제품 출시 이후에 밝혀질 수많은 사용자 이슈를 미연에 방지했을 뿐만 아니라, 리콜이 필요한 버그(recall-class bugs)가 없다는 것을 확인하기 위해 필요한 수많은 테스터들의 수도 줄일 수 있었다. 구글에서 테스팅은 이러한 예방 활동이 얼마나 잘 수행되고 있는지 알아내는 것을 그 목표로 한다. 지속적으로 버그를 만들어내는 사람인 동시에 이를 예방해야 하는 사람들인 SWE – SET 들이 얼마나 더 후자의 일을 잘하고 있는지에 대한 증거를 찾아내는 것이 TE들이 해야 하는 일이다. TE들은 이런 프로세스가 제대로 수행되지 않는다고 판단될 경우 이에 대해 경고한다.   

 

개발과 테스팅을 조합해야 한다는 신념은 ‘당신이 테스트한 기록은?(Where are your tests?)’이라고 물어보는 항목이 포함된 코드 리뷰 노트에서부터, 화장실에서조차 개발자가 가장 훌륭한 테스팅 수행자임을 상기시켜주는 그 악명 높은 ‘화장실의 테스팅(Testing On The Toilet)[2]’ 가이드에 이르기까지 구글의 모든 곳에서 표현되고 있다. 테스팅은 개발에 있어서 피할 수 없는 한 부분이 되어야 하며, 개발과 테스팅이 결합해야만 품질이 달성될 수 있는 것이다. SWE는 테스터이며, SET도 테스터이고, TE 역시 테스터다.

 

만약 당신의 조직이 이러한 결합을 추진하고 있다면, 그 성공과 도전의 역사를 우리에게도 공유해주기 바란다. 만약 이러한 결합을 추진해 본 경험이 없다면, 지금이야말로 당신의 조직이 변해야 하는 시기다. 개발자들이 품질 문제에 전념할 수 있도록 만들어라. 베이컨과 달걀이 나오는 아침식사를 위해 닭은 단순히 알만 제공하지만 돼지는 스스로를 헌신해야 한다는 소프트웨어 업계의 오랜 격언[3]을 잘 알고 있을 것이다. 이 말은 물론 사실이다. 당신의 개발자가 돼지라고 한다면, 정말 그들이 품질에 헌신하고 있는지를 살펴보라. 만약 그들이 닭이 되기를 원한다면, 이미 문제는 시작되고 있는 것이다.

 

-- continue --

   

---

[1] 역자 주: 판에 박은 듯한 문구 또는 진부한 표현을 가리키는 문학용어

[2] 역자 주: http://xguru.net/494?replytocom=6626 참조

[3] 역자 주: http://daeny2.springnote.com/pages/5307607 참조