『뷰티풀 테스팅』 포스트모르템

지난 11월 14일, 제가 역자로 참여한 『뷰티풀 테스팅』의 번역본이 1년 반의 작업 끝에 드디어 출간되었습니다.

 

400 페이지가 넘는 책을 처음 받아본 그 순간, 정말 뭐라 형용할 수 없는 복잡한 감정이 느껴지더군요.
무엇보다도 뭔가를 만들어냈다는 뿌듯한 성취감이 복잡다단했던 감정의 절반을 넘었던 것 같습니다. 그 산출물에게 매겨질 성적은 둘째 치더라도 오랜 기간 쏟아 부은 시간과 노력이 하나의 산출물로 손에 쥐어진다는 것은 언제나 감동적인 것 같습니다.

 

다른 역자 분들과 함께 오랜 기간에 걸쳐 공동의 산출물을 만들어낸다는 점에서 이번 번역 작업도 하나의 소프트웨어나 게임을 만드는 프로젝트와 다를 바가 없었던 것 같습니다. 오늘은 최근 유행하는 포스트모르템 형식을 빌어 지난 1년 반 동안의 작업을 돌아보고자 합니다.

 

소개

『뷰티풀 테스팅』의 번역에는 저를 포함해 총 4명의 역자가 작업에 참여했습니다. 이 중 2분은 『소프트웨어 테스팅 마이크로소프트에서는 이렇게 한다』(에이콘, 2009)에도 역자로 참여하신 분들이고, 저도 리뷰어로 참여했던 경험이 있는 지라 그 분들과 함께 『뷰티풀 테스팅』의 작업에 동참하는 것은 무척 기대되고 설레는 일이었습니다.

이미 많은 분들이 원서로 『Beautiful Testing』을 보신 것으로 알고 있습니다. 소프트웨어 테스팅에 대한 에세이 형식의 글뿐만 아니라, 각 도메인 별로 특화된 에피소드나 기법을 다양하게 들려주고 있어서 흥미롭게 읽으신 분들이 분들이 많은 것 같습니다.

아마존의 평점에서는 별 5개 만점에 별 4.9개를 기록하고 있습니다.   

 

데이터

제목: 뷰티풀 테스팅 - 27인의 테스터가 들려주는 아름다운 이야기

저자: Adam Goucher / Tim Riley 엮음

역자: 김민영 / 김윤명 / 진석준 / 조현길

발행자: 김지영

발행처: ㈜지앤선

ISBN: 978-89-93827-38-5

총 페이지 수: 455 페이지

 

 

목차

1부.         아름다운 테스터

 1장.         무엇이 좋은가?

 2장.         아름다운 테스팅은 이해 관계자를 만족시킨다

 3장.         오픈 소스 QA 커뮤니티 만들기

 4장.         협력은 아름다운 성능 테스팅을 위한 초석이다

2부.         아름다운 프로세스

 5장.         퍼지 테스팅을 통한 사무용 소프트웨어의 신뢰성 확보

 6장.         버그 관리와 테스트 케이스 효과성

 7장.         아름다운 XMPP 테스팅

 8장.         대규모 테스트 자동화의 아름다움

 9장.         아름다운 것이 추한 것보다 낫다

 10장.       난수 발생기 테스팅

 11장.       변화 중심의 테스팅

 12장.       실생활에서 사용되는 소프트웨어

 13장.       소프트웨어 개발은 창조적인 과정이다

 14장.       테스트 주도 개발: 아름다움의 새 기준

 15장.       사업 성공의 초석이 된 아름다운 테스팅

 16장.       소셜 텍스트의 양파 껍질 벗기기

 17장.       아름다운 테스팅이란 효율적인 테스팅이다

3부.         아름다운 툴

18장.       버그를 찾기 위한 버그 심기: 아름다운 뮤테이션 테스팅

19장.       아름다운 테스팅으로써의 레퍼런스 테스팅

20장.       클램 안티 바이러스: 공개 툴을 활용한 오픈 소스 테스트 하기

21장.       윈드밀(Windmill)을 사용한 웹 애플리케이션 테스팅

22장.       100만 개의 웹 페이지 테스팅

23장.       다양한 기기들로 구성된 시나리오 안에서 네트워크 서비스 테스트하기

 

잘된 점
 1.     구글 사이트의 활용

앞서도 언급했듯이 여러 역자가 참여하고 번역서라는 산출물을 만들어내는 번역 작업 역시 하나의 팀 프로젝트로 볼 수 있습니다. 오히려 구성원들이 물리적으로 모이기 힘든 실정이므로 전체 작업의 진행 상황을 체크하고 필요한 커뮤니케이션을 제공하기 위한 공간이 필요했습니다.
이번 작업에서는 이전 『소프트웨어 테스팅 마이크로소프트에서는 이렇게 한다』의 작업에서도 활용했던 구글 사이트를 프로젝트 관리 툴로 활용했습니다. 역자 별 번역 분량의 할당, 진척 상황 확인, 오프라인 미팅 이후 회의록의 공유, 심지어는 작업 도중 발생하는 소소한 에피소드나 고민거리들도 같이 나눌 수 있는 공간으로 잘 활용되었던 것 같습니다. 프로젝트 관리 도구의 필요성을 절감할 수 있는 좋은 기회였습니다. 

 
 2.     다양한 분야에 종사하는 베타리뷰어 참가 

제가 몸담고 있는 스터디 그룹인 ‘그린시그널’과 테스팅 팀 블로그 ‘누가바닷컴’의 식구들, 그리고 각 역자들의 직장 동료 분들이 베타리뷰어로 참가해 주셨습니다. 보안, 의료, 임베디드, H/W 및 일반 상용 애플리케이션 등의 다양한 분야에서 풍부한 경험을 가지고 계신 테스터/QA 분들이 소중한 의견을 모아 주셨습니다.
좀 더 여유를 가지고 더 다양하고 깊은 의견을 받고 이를 반영하지 못한 점이 아쉽기는 합니다.
이 자리를 빌어 바쁜 시간에도 리뷰어로 참여해 주신 모든 분들에게 감사의 말씀 전합니다.

 
3.     SNS의 활용

제 개인적으로는 이번 번역 작업에 트위터나 페이스북 등의 SNS가 큰 도움이 되었습니다.
테스팅 분야의 단어들은 아직 제대로 한글화가 되지 않은 것도 많고, 여기저기서 다른 말로 번역한 경우가 많아서 어떻게 번역해야 모든 사람들이 고개를 끄덕일 수 있을까라고 고민한 적이 한 두 번이 아니었습니다.

물론 『개발자도 알아야 할 소프트웨어 테스팅 용어』와 『소프트웨어 테스팅 마이크로소프트에서는 이렇게 한다』가 큰 도움이 되었습니다만, 그래도 스스로 정확하게 번역했다고 자신하기가 힘든 단어와 문장들이 많았습니다. 이런 경우 트위터나 페이스북에 질문을 던져 더 많은 경험과 지식을 가지신 분들의 의견을 참조할 수 있었습니다.

“System of systems” 같은 단어의 적절한 표현에 대해 물어봤을 때, 트위터를 통해 권원일 대표님이 “거대 시스템즈”가 적합하지 않느냐고 의견을 주시기도 했습니다. 역시 이 자리를 빌어 SNS를 통해 개인적으로 도움주신 분들에게도 고맙다는 말씀 전해드립니다. 

 

아쉬웠던 점
1.     가이드라인의 부족

번역을 하나의 소프트웨어 프로젝트와 비교한다면 우리에게 작업을 의뢰한 출판사가 제품에 대한 요구사항을 제시하는 핵심 이해관계자라고 할 수 있을 겁니다.
번역 작업이 진행되는 동안 역자들끼리는 구글 사이트와 오프라인 모임을 통해 자체적인 커뮤니케이션을 유지할 수 있었지만, 출판사의 산출물에 대한 요구사항(이를 테면 번역 스타일 및 편집 스타일에 대한 가이드)이나 프로젝트 일정에 대한 요구사항을 들을 기회가 거의 없었습니다.
물론 출판사마다 역자들의 작업을 관리하는 스타일의 차이가 있기는 하지만, 책을 편집하고 출판해야 하는 출판사가 산출물에 대한 기준이나 가이드를 미리 제시해 준다면, 역자들이 처음부터 그에 맞추어 편하게 작업을 진행할 수 있으리라 생각됩니다. 
개발자들이 “프로젝트 초기에 모든 게 명백하고 개발 기간 내내 절대 변경되지 않는 요구사항”을 필요로 하는 것처럼 말이죠.

물론 현실은 그럴 수 없다는 것을 이번 작업을 통해서 다시 한 번 느끼게 됐습니다.    

 
2.     얼리 테스팅!!!

상대적으로 길었던 초벌 번역이 끝나고 나서 첫 교정 작업에 들어갔을 때였습니다.
막상 제가 번역했던 원고를 다시 들여다보니 ‘정말 이게 제대로 시간들여 번역한 게 맞는 건가’라는 생각이 들 정도로 번역의 품질이 엉망이었습니다.
초벌 번역을 빨리 끝내야 한다는 부담감에 무작정 진도 나가는 것에만 집중하다 보니, 전후 단락과의 문맥을 고려하지 못했던 것입니다. 한 단락은 괜찮은 것 같은데 전체 장의 전후를 고려해서 읽다 보면 어색해지는 부분도 있었고, 좀 더 심층적인 조사와 공부가 필요한 부분인데도 표면적인 의미만으로 해석을 한 경우도 많았습니다.

각 섹션 별로 초벌을 끝낸 다음 바로 리뷰를 시작하는 식의 짧고 반복적인 프로세스를 도입했더라면, 후반 교정 작업에 드는 시간을 훨씬 단축할 수 있었을 뿐만 아니라 좀 더 일률적인 스타일을 가지게 되었을 텐데 하는 아쉬움이 많이 남습니다.

이런 점에선 참 소프트웨어 개발 프로젝트나 번역 작업이 많이 비슷한 것 같네요.

 
3.     완벽하려고 하지 마라  

후반부 작업이 길어졌던 또 하나의 이유는, 여러 차례 교정 작업을 수행했기 때문입니다.
역자의 입장에서는 번역의 품질이 언제나 만족스러울 수가 없고 교정 작업을 할 때마다 부족한 부분이 눈에 띄기 마련입니다. 하지만 완벽한 제로디펙트(zero-defect)의 제품이 없는 것과 마찬가지로, 번역 작업 역시 완벽을 가하려고 한다면 책이 언제 출판될지 모르겠더군요.

마지막 교정을 볼 때쯤엔 사실 지치기도 해서 오히려 집중도도 떨어졌습니다. 투입되는 리소스에 비해 얻는 효과가 하향 곡선을 그리기 시작할 때쯤, 더 이상의 리소스 투입이 의미가 없다는 것을 우리는 잘 알고 있습니다.
하지만 현실에서는 이 또한 어려운 이야기라는 걸 다시 한 번 느낄 수 있었습니다.

 

개인적으로는 한 사람의 역자와 한 사람의 리뷰어가 팀을 이루고, 산출물이 나오기 시작하는 초기부터 리뷰어가 산출물을 검토하는 형태가 가장 이상적이지 않을까 하고 생각합니다.

결론

지난 1년 반 동안 번역 작업을 수행하면서, 번역 프로세스를 좀 더 효율적으로 개선할 수 없을까를 나름 고민해 봤습니다. 개인적으로는 한 사람의 역자와 한 사람의 리뷰어가 팀을 이루고, 산출물이 나오기 시작하는 초기부터 리뷰어가 산출물을 검토하는 형태가 가장 이상적인 방법이라고 생각합니다. 또한 온오프라인의 다양한 인터페이스를 통해 리뷰와 피드백을 진행하고, 구글 사이트와 같은 협업 도구를 사용해 전체 프로젝트를 관리하는 형태라면 좀 더 효율적으로 번역 작업을 진행할 수 있을 것 같습니다.

일종의 익스트림 번역이나 애자일 번역이라고나 할까요.

이런 측면에서 보면 소프트웨어 공학이나 QA의 기법들이 생활 전반에 광범위하게 적용될 수도 있을 것 같습니다. 애자일이 하나의 기법이 아니라 문화로 대접받는 것처럼 말이죠.

 

『뷰티풀 테스팅』으로 인해 국내 서점에서 ‘소프트웨어 테스팅’으로 분류되는 서가가 좀 더 채워지고, 소프트웨어 테스트 관련 정보에 목말라 하는 사람들이 조금이라도 더 정보를 얻을 수 있는 기회가 늘어나기를 바랍니다.

소프트웨어 테스팅은 아직도 갈 길이 먼 것 같습니다.
특히나 국내의 경우는 더더욱 그렇죠. 
『뷰티풀 테스팅』이 여러분들의 먼 길에 힘을 실어주는 지팡이가 되길 바라마지 않습니다.

 

다시 한 번, 이 자리를 빌어 번역 작업에 도움주신 모든 분들에게 진심으로 감사 드립니다.