[번역] How Google Tests Software - Part Seven

 

 

구글에서 테스트 엔지니어는 SWE(Software Engineer)나 SET(Software Engineer in Test)에 비해 가장 최근에 만들어진 직무이다. TE의 역할에 대해서는 아직도 논의가 진행 중이다. 현재 구글에서 TE로 일하고 있는 세대들은 새로운 길을 개척하고 이를 통해 다음 세대의 TE들이 어떤 역할을 할 것인가에 대한 가이드를 제시하고 있는 것이다. 이 글에서 보여주고자 하는 것은 바로 구글에서 현재 가장 부각되고 있는 TE들의 업무에 관한 프로세스이다.

 

사실 모든 제품에 TE가 필요한 것은 아니다. 실험적인 제품이나 구체적으로 정의된 미션 혹은 유저 스토리가 없는 초기 제품에는 TE들이 큰 신경을 쓸 필요가 없다. 프로젝트가 취소될 가능성이 있거나, 개념 증명(proof of concept)[1]이 실패할 가능성이 있을 때, 혹은 아직 사용자들이 많지 않거나 구체적인 기능 정의가 되지 않았을 경우에는 주로 이를 개발한 사람들이 직접 테스트를 수행하게 된다.

 

양산이 확정된 제품이라 할지라도 기능이 불안정하고 어떤 기능이 양산 단계에 포함될지 아직 최종적으로 결정되지 않은 개발 초기에는 테스트 엔지니어들이 할 일이 그리 많지 않다. 너무 이른 시기에 너무 많은 리소스를 테스팅에 투자하는 것은 곧 테스팅을 제외한 다른 일들을 하지 못할 수도 있다는 것을 의미한다. 제품이 최종 형태에 가까워진 후반에 탐색적 테스팅이라도 수행해서 버그를 하나라도 더 찾아내려고 노력하는 것보다, 프로젝트 초기부터 적절하게 테스팅을 계획하는 것이 훨씬 더 적은 테스트 엔지니어들을 필요로 한다.  

 

프로젝트에 테스트 엔지니어들을 투입할 때 가장 신경 써야 하는 두 가지 항목은 바로 리스크를 어떻게 다룰 지와 투자에 대비해 얼마나 효과를 거둘 수 있을 지다. 고객에 대한 리스크와 기업이 가지고 있는 리스크를 모두 감안한다면, 항상 더 많은 테스팅이 필요하고 그에 맞게 더 많은 테스트 엔지니어의 투입이 불가피하다. 얼마나 많은 테스팅이 더 수행되어야 하느냐의 문제는 얼마나 많은 잠재적인 수익을 더 올릴 수 있느냐의 문제와 같이 고려되어야 한다. 정확하게 몇 명의 TE가 필요한지 파악해 이들을 적재적소의 업무에 투입하고, 그에 걸맞은 효과를 거두어야 하는 것이다.

 

TE들이 업무에 투입된다고 해도 모든 것을 처음부터 시작하는 것은 아니다. 이미 SWE나 SET들이 테스트 엔지니어링이나 품질에 관련된 다양한 작업들을 수행하고 그 산출물들을 만들어 놓았을 것이기 때문이다. 추가로 투입되는 TE들은 이들이 만들어놓은 산출물을 기반으로 업무를 시작하는 것이다. TE들은 업무에 투입된 초반에 아래와 같은 사항들을 결정하고 파악해야 한다.

 

■ 소프트웨어의 취약점은 어느 부분인가?

■ 보안 및 개인 정보, 성능이나 신뢰성과 관련된 부분은 무엇인가?

■ 1차적으로 선정된 주요 사용자 시나리오들이 모두 정상적으로 동작하는가?

모든 해외 사용자들의 경우에도 동일한 결과가 도출되는가?

■ 다른 하드웨어나 소프트웨어 제품과 정상적으로 상호작용하는가?

■ 문제가 발생했을 때 이를 분석하는 업무는 얼마나 효율적으로 수행되는가?

 

이 모든 것들은 소프트웨어 릴리즈에 필요한 리스크 프로파일에서 잠재적으로 문제를 야기할 만한 사항들이다. TE가 이와 관련된 모든 일을 수행할 필요는 없지만 이러한 작업들이 완료되었는지, 그리고 그 영향으로 인해 다른 추가적인 작업이 필요한지는 파악하고 있어야 한다. 테스트 엔지니어들은 궁극적으로는 비효율적인 설계와 혼란스러운 UX, 기능적인 버그, 보안 및 개인 정보 이슈와 그 밖의 여러 문제들로부터 고객과 기업을 보호하기 위해 고용되어 있는 것이다. 구글에서 제품이나 서비스의 전반적인 면에서 취약점을 찾아내기 위해 고용된 유일한 정규직 사원이 바로 테스트 엔지니어들이다. 이처럼 테스트 엔지니어들은 SET에 비해 조금 덜 관행적이고 덜 정규화된 업무를 수행한다. 모든 단계의 프로젝트에서 TE들에게 참여를 요구할 수 있다. 아이디어를 고안하는 단계에서부터 버전 8에 이르기까지, 심지어는 반대에 부딪히거나 보류하기로 결정된 프로젝트에도 TE들의 참여를 요구할 수 있다. 보안 분야와 같이 전문성이 요구되는 스킬을 보유한 TE는 한 번에 여러 프로젝트에 동시에 참가하기도 한다.  

 

TE의 업무는 그들이 참여하는 프로젝트가 무엇인가에 따라 명확하게 달라진다. 일부 TE들은 마치 SET들처럼 그들 업무의 대부분을 프로그래밍 작업에 할애하기도 한다. 이런 경우에도 이들은 다른 개발자들에 비해 사용자 시나리오에 좀 더 높은 비중을 두면서 업무를 수행한다. 다른 TE들은 일반적으로 이미 개발된 코드와 설계 중에서 장애를 유발하는 오류를 발견하고, 이로 인해 발생하는 장애 모드(failure mode)를 분석한다. 이러한 업무를 통해 코드를 최적화 하는 것이 TE가 수행하는 일이다. 처음부터 코드를 만드는 것이 TE의 업무가 아니다. TE들은 다른 누구보다 구조적으로 사고해야 하며, 테스트를 계획하고 완료하는 데 있어서 그들이 가지고 있는 시스템에 대한 경험을 적용하고, 실제로 제품이 사용되는 방법을 꼼꼼하게 반영할 필요가 있다. TE는 요구사항과 일치하지 않는 점을 찾아내고 애매모호한 문제가 발생하는 원인을 밝혀내며, 이러한 문제들에 관해 커뮤니케이션 하는 데 있어서 누구보다 뛰어나야 한다.

 

성공적인 TE라면 이 모든 것들을 개발팀을 비롯한 다른 사람들의 감정과 뚜렷한 개성까지 고려하면서 완수할 것이다. 오류가 발견되었을 때 테스트 엔지니어들은 적절하게 소프트웨어를 분석하고 해당 이슈들을 SWE, PM 그리고 SET들이 해결하도록 넘겨주어야 한다. 

 

앞서 TE에 대한 이런 설명들을 본다면 TE는 적절한 가이드도 없는 상황에서 기술적인 스킬과 리더십, 그리고 제품에 관한 깊은 지식을 동시에 가지고 있어야 하는 놀랄만한 직업이다. 많은 사람들이 이것이 쉽지 않은 일이라고 말한다. 구글에는 테스트 엔지니어들로 구성된 강력한 커뮤니티가 존재하고 있으며, 이 커뮤니티를 통해 직면한 이런 문제들을 해결해 나가고 있다. 구글의 모든 직무 중에서도 TE는 아마 가장 피어 서포트(Peer support)가 잘 이루어지는 일일 것이다. TE는 또한 통찰력과 함께 리더십이 동시에 요구되는 직무이기도 하다. 이는 최고의 테스트 매니저들이 TE 출신이라는 것에서도 증명되는 사실이다.

 

구글의 테스트 엔지니어들이 일하는 모습을 보면 마치 어떤 고착화된 근무 형태가 없다는 착각을 불러일으킬 정도로 유연하다. TE들은 프로젝트가 진행되는 어느 순간에도 투입이 가능하다. TE들은 투입되는 즉시 해당 프로젝트의 상태와 코드, 설계 그리고 사용자들이 어떤 상태인지를 신속하게 파악해야 하며 무엇에 집중해야 하는지를 결정해야 한다. 만약 프로젝트가 이미 시작한 상태라면, 테스트 계획을 가장 먼저 검토해 보아야 한다. TE들은 종종 라이프 사이클의 후반부에 제품이 양산 가능한 상태인지를 평가하거나, 혹은 ‘베타’ 버전을 릴리즈 하기 전에 주요한 이슈들은 없는지 살펴보기 위해 프로젝트에 투입된다. 만약 이미 어느 정도 제품이 완성된 프로젝트에 TE들이 새롭게 투입되거나, TE들이 미리 일부라도 경험을 해 본 프로젝트에 투입된다면 그들은 대부분 테스트 계획에는 크게 신경 쓰지 않고 탐색적 테스팅부터 시작해 보려고 할 것이다. 어떤 경우에는 프로젝트가 한동안 릴리즈 되지 않고 단순히 기능이나 보안 관련 패치, UX 업데이트 등의 업무만이 수행되는 경우도 있다. 이런 경우에는 또 다른 접근법이 필요하다. 구글에서 TE가 수행하는 일은 이처럼 매우 다양하다.

  

[1] 역자 주: 제품이나 기술, 정보 시스템 등이 조직의 특수한 문제를 해결할 수 있다고 증명하는 과정. 아직 시장에 나오지 않은 신제품에 대한 사전 검증을 위해 사용된다.

출처: 네이버 지식 사전 http://terms.naver.com/entry.nhn?docId=44615