[번역] How Google Tests Software - Part Five

 

잠시 쉬어가는 포스트(Brief Interlude)를 포함해, 장장 6편에 이르는 제임스 휘태커(James Whittaker)의 연작 “How Google tests software” 시리즈의 번역이 끝났습니다.

 

이번 연작은 소프트웨어 테스팅의 새로운 트렌드를 배울 수 있는 좋은 기회였던 것 같습니다.
아울러 테스팅의 기본적인 아키텍트는 변하지 않는다는 사실 역시 확인할 수 있었습니다.

 

주변의 TE들에게도 기회가 될 때마다 말해주지만, 제임스 휘태커가 이 포스트를 통해 여러 번 언급했듯이
소프트웨어 테스팅의 무게 중심은 점점 블랙박스에서 화이트박스로 이동하고 있습니다.
단순한 수동 블랙박스 테스팅을 자동화할 수 있는 스크립트 수준의 코딩 뿐만 아니라, 코드 기반에서 자동화된 테스트를 수행할 수 있는 능력까지 요구하는 시대가 도래하는 것 같습니다.

 

아직은 소프트웨어 테스터의 코딩 능력을 주제로 다룬 여러 글에서 개발자 수준의 코딩 능력이 필요 없다고는 말하고는 있지만, 일관적으로 코드를 작성하는 수준은 아니더라도 읽고 이해할 수 있는 수준은 필요하다고 말하고 있는 실정입니다.

 

지난해 발간된 『소프트웨어 테스팅 마이크로소프트에선 이렇게 한다』에서도 보이듯이, 코딩 능력 유무에 따라 테스트의 직군이 구별되는 것이 일반적인 트렌드가 되지 않을까 싶습니다.
아직 블랙박스 테스트 영역조차 제대로 알지 못하는 나에게는 여러 가지 숙제를 안겨준 것 같네요. 

 

이 연작 이후로도 제임스 휘태커는 활발하게 구글 테스팅 블로그에 좋은 글들을 올리고 있습니다.

기회가 된다면 계속해서 그의 글을 번역해 봐야겠습니다.

 

Happy Testing.

 PS> 'Debugging sucks Testing Rocks' 이미지는 구루님의 블로그 포스트 "구글 화장실 이야기"에서 가져왔습니다. 구글의 테스팅 문화에 관심이 있으시다면 해당 포스트와 첨부파일들을 일독해 보시기를 권장합니다.

How Google Tests Software – Part Five

Wednesday, March 23, 2011 8:27 PM

 

By James Whittaker

 

구글에서는 코드, 통합 그리고 시스템 테스팅을 구별해 사용하는 대신, 테스트의 형식보다는 규모를 강조하는 소규모, 중규모 그리고 대규모 테스트라는 단어를 사용한다(Instead of distinguishing between code, integration and system testing, Google uses the language of small, medium and large tests emphasizing scope over form). 소규모 테스트는 규모가 작은 코드를 커버한다. 서로 다른 3종류의 엔지니어[1]들이 이 모든 유형의 테스트에서 자기가 할 일을 수행하며, 여기에는 자동화 테스트나 수동 테스트가 모두 포함된다. 

 

소규모 테스트(Small Tests)는 대부분(하지만 항상 그런 것은 아니다) 자동화되고 단일 기능이나 단일 모듈의 코드에 대해 수행된다. 대부분의 소규모 테스트는 SWE(Software Engineer) 혹은 SET(Software Engineer in Test)에 의해 작성되며 테스트 수행을 위한 목업(mock)이나 가상 환경이 필요한 경우도 있다. TE들은 특정한 장애를 분석할 필요가 있을 때 미리 작성된 이러한 테스트를 수행한다. 소규모 테스트에서는 데이터 손상(data corruption), 오류 상태(error conditions) 그리고 OBOE(Off-by-one-errors)[2]와 같은 전형적인 기능 이슈들에 초점이 맞추어진다. 소규모 테스트는 코드가 어떤 것을 수행해야 하는가라는 질문에 답하기 위해 수행된다(The question a small test attempts to answer is does this code do what it is supposed to do?).

 

중규모 테스트(Medium Tests)는 자동화되거나 혹은 수동으로 수행될 수 있다. 2개 혹은 그 이상의 기능들이 포함되며 특히 이들 기능간의 상호작용을 커버한다. 나는 많은 SET들이 이 테스트를 ‘하나의 기능과 그 가까운 주변을 테스팅하는 것(testing a function and its nearest neighbors)’이라고 설명하는 것을 자주 들을 수 있었다. SET들은 개별적인 기능 구현이 완료되는 시점에 맞추어 제품 사이클의 앞단에서 이러한 테스트들을 개발하고, SWE들은 테스트를 작성하는 일에 참여해 실제로 사용하는 테스트 코드를 디버깅하고 유지하는 일을 수행한다. 만일 테스트가 실패하거나 중단된다면, 개발자들이 스스로 테스트 코드를 손보기도 한다. 개발 사이클의 후반에 이르러서는 TE들이 테스트가 난해하거나 자동화 비용이 엄두가 나지 않을 경우에는 수동으로, 그밖의 경우에는 자동화를 통해 중규모 테스트를 수행한다. 중규모의 테스트를 통해서는 일련의 주변 기능들이 다양한 정상적인 방식으로 상호작용을 잘 수행하고 있는가라는 질문에 답할 수 있다(The question a medium test attempts to answer is does a set of near neighbor functions interoperate with each other the way they are supposed to?).    

 

대규모 테스트(Large Tests)는 3개 혹은 그 이상의 기능을 커버하고 가능한 많은 실제 사용자 시나리오를 반영한다. 모든 기능의 통합을 고려해야 하지만, 대규모 테스트는 결과 주도적(results driven)이기도 하다. 예를 들어, ‘소프트웨어가 사용자가 기대한 대로 동작하는가(did the software do what the user expects?)’와 같은 질문에 답하기 위해 테스트가 수행되기도 한다. 테스트와 관련된 3가지 직군 모두 대규모 테스트를 작성하는데 투입되며, 자동화에서부터 탐색적 테스팅에 이르기까지 가능한 모든 수단이 테스트를 완수하기 위해 동원된다. 대규모 테스트를 통해 답하고자 하는 질문은 바로 제품이 사용자가 원하는 방식으로 동작하는가이다(The question a large test attempts to answer is does the product operate the way a user would expect?).

 

소규모, 중규모 혹은 대규모라는 단어 자체가 중요한 것이 아니다. 당신이 원하는 대로 불러도 상관없다. 중요한 것은 구글의 테스터들이 무엇이 테스트되어야 하고, 어떻게 테스트가 수행되어야 하는지를 동일한 단어로 공유하고 있다는 사실이다. 만약 어떤 진취적인 테스터가 4번째 단계의 테스트를 거대 테스트(enormous test) 라고 이름 붙이고, 이런 단어를 사용하기 시작한다면 회사 내의 다른 테스터들은 쉽게 거의 모든 기능을 커버하는 시스템 전반을 다루는 폭넓은 테스트를 연상할 것이며, 이 테스트를 수행하는데 아주 오랜 시간이 필요할 것이라고 생각할 것이다. 더 이상 추가적인 설명이 필요한가?

 

어떤 테스트가 얼마나 필요한가를 결정하는 것은 무척 유동적인 프로세스이며, 제품에 따라 그 범위가 아주 다양하다. 구글은 제품을 자주 릴리즈하고 사용자들이 제품을 쉽게 사용할 수 있도록 만들어 그들로부터 피드백을 얻는 과정을 반복하는 선순환 구조를 선호한다. 만약 우리가 어떤 새로운 제품을 개발하거나 기존 제품에 새로운 기능을 추가한다면, 사용자들이 가능한 빨리 이 제품과 기능을 활용할 수 있도록 하는 것이 구글의 일반적인 방식이다. 사용자와 외부 개발자들을 일찌감치 개발 프로세스에 동참시킴으로써, 우리가 만드는 제품이 시장에서 좋은 반응을 얻을 수 있을지를 미리 감지해 낼 수 있기 때문이다.

 

마지막으로, 구글은 이 3가지 규모의 테스트 모두에서 자동화와 수동 테스팅 중 특히 자동화 테스팅이 수행되는 것을 선호한다. 만약 테스트가 자동화될 수 있고, 사람의 영리함이나 직관이 필요하지 않다고 판단되면 해당 테스트는 자동화된다. 모든 범주의 테스트에서 단 한 가지 영역, 즉 사람의 판단이 필요한 부분만 수동 테스트의 영역으로 남게된다. 유저 인터페이스가 아름다운지, 데이터의 일부가 노출됨으로써 개인 정보 보호가 침해되는지 등이 여기에 속한다.

 

사실 말은 이렇게 하지만, 아직도 구글에서는 스크립트화 되거나 탐색적으로 수행되는 수많은 수동 테스팅이 수행되고 있다는 점 역시 간과해서는 안된다. 하지만 이런 테스팅도 자동화된 관리 체계(the watchful eye of automation) 아래에서 수행되고 있다. 최첨단의 레코딩 기술[3]이 수동 테스트를 빌드 이후에도 자동으로 빌드를 수행해주는 자동화 테스트로 변환해 주고 있으며, 이는 리그레션을 최소화 해주고 수동 테스터들이 항상 새로운 이슈에 집중할 수 있도록 만들어주고 있다. 우리는 또한 버그 리포트를 제출하고 수동 테스팅을 수행하기 위한 과정 또한 자동화하려고 노력하고 있다. 예를 들어, 수행 중이던 자동화 테스트가 중단된다면 시스템은 그 사태를 야기한 것으로 간주되는 최종 변경 사항을 저장하고 해당 개발자에게 메일을 보내는 동시에 버그 파일을 저장한다. 한 길 사람속까지 모두 자동화하려는 지속적인 노력은 바로 현재 구글이 만들어가고 있는 차세대 테스트 엔지니어링 툴의 디자인 스펙인 것이다.

 

여기서 언급된 툴들은 향후의 포스트에서 다루어 질 것이다. 나의 다음 글은 SET의 생활을 다루는 것이 될것이다. 계속 관심있게 구독해 주길 바란다.

     

---

[1] 역자 주: SWE(Software Engineer), SET(Software Engineer in Test) 그리고 TE(Test Engineer)를 의미한다.

연작의 두 번째 포스트(http://angel927.tistory.com/105) 참조.

[2] 역자 주: 코드에서 루프가 사용된 경우 예정된 횟수보다 한 번 더 순회하거나 혹은 더 적게 순환하는 경우를 말한다. http://en.wikipedia.org/wiki/Off-by-one_error 

[3] 역자 주: 원문에는 ‘Industry leading recording technology’ 라고 되어있으며, SIKULI(http://sikuli.org/)와 같이 발전하고 있는 ‘캡쳐 & 리플레이’ 기술을 의미하는 듯함.