[번역] 테스터의 커리어 패스

원문: http://bit.ly/2vuAzKS

이 글은 게스트 작가인 저스틴 로만(Justin Rohrman)이 작성한 것이다. 저스틴은 2005년부터 다양한 분야에서 전문 소프트웨어 테스터로 일하고 있다. 가장 최근에 그가 수행한 업무는 Excelon Development에서 소프트웨어 테스터를 위한 컨설팅이었다. 아울러 AST(Association for Software Testing)의 의장으로 활동하면서 다양한 프로젝트를 원활하게 수행하도록 돕는 역할을 하고 있다.  

---

테스터로 몇 년의 경력을 쌓고 나서 스스로에게 이런 질문을 던져 보았다.

“이제 어디로 가지?”

스스로 이런 질문을 던져 본 사람이 비단 나 하나뿐만은 아니었을 것이다. 특히나 테스팅 분야는 진입하고 떠나가는 사람들이 유별나게 많다. 사회 생활을 테스터로 시작하고 몇 년 동안 테스터로 일하다가 프로그래머로 전직하는 사람들도 있다. 어떤 사람들은 PM(Product Manager)으로 전직해 관리자의 길을 가기도 한다. 테스터의 커리어는 평탄하지 만은 않으며, 평범한 조직도에 얽매이지 않는다.

테스터라는 직종에 쉽게 접근하고, 그 이후 평이하게 갈 수 있는 길을 찾기 힘든 것이 사실이다.

이제 소프트웨어 테스터로서 선택할 수 있는 몇 가지 커리어 옵션을 살펴보고 이들 커리어를 선택하기 위해 필요한 몇 가지 제안을 함께 제시하고자 한다.

지금의 회사 안에서

---

당신이 다니고 있는 회사 어딘가(혹은 쉐어포인트 안에 라도)에는 인사팀이 존재하고 있을 것이며, 그렇다면 회사 전체의 모양 – 누가 어떤 역할을 수행하고, 누가 누구에게 보고해야 하고, 그리고 어떤 과정을 거쳐 승진할 수 있는지 설명하는 조직도도 반드시 어딘가 존재할 것이다. 누군가는 버그 수정을 확인하거나 작고 간결한 기능 변경을 확인하는 것과 같은 일을 하는 주니어 테스터로 일을 시작할 것이다. 이들은 결국 더 복잡하고 더 오래갈 수 있는 프로젝트에서 독립적으로 일할 수 있는 스텝 레벨까지 올라가는 것을 원할 것이다. 뿐만 아니라 시니어 역할, 리드 역할 그리고 다양한 아키텍처의 역할을 수행할 수도 있을 것이다.

이런 각 레벨과 역할들이 사실 명확하게 구분되어 있는 것은 아니다. 당신이 다니고 있는 회사가 각각의 직책을 명확하게 구분하고 있다고 하더라도 실제로는 어느 정도 겹치는 부분도 있을 것이며 그 기준이 모든 사람에게 동등하게 적용되고 있는 것도 아닐 것이다. 얼마나 많은 책임을 지고 있는지, 얼마나 더 독립적으로 일할 수 있는지, 얼마나 많은 영향력을 행사할 수 있는지가 관건일 뿐이다.

나도 처음에는 테스트 케이스를 수행하고, 버그 수정을 확인하는 일을 수행하는 주니어 테스터로 시작했다. 내가 걱정해야 하는 유일한 일은 단지 내게 주어진 일을 완수하는 것이었다. 나는 충분히 그 일을 잘 해냈고 누군가는 내가 주니어 역할보다 더 어려운 일을 맡을 수 있다고 생각했던 것 같다. 그 다음부터 테스트 케이스를 수행하는 일은 조금 줄어들었고 그 대신 좀 더 창조적이면서 답이 정해지지 않은 문제를 해결하는 일들이 내게 주어졌다. 매일 내가 해야할 일들 중에서 혼자 할 수 있는 일들이 줄어들었고 개발팀의 다른 사람들과 협업해야 하는 일들이 늘어났다. 개발자들은 시도 때도 없이 인스턴트 메신저를 통해 나에게 메시지를 보내 그들이 만든 것들을 테스트 빌드에 커밋 하기 전에 자기 자리로 와서 변경 사항을 검토해 줄 것을 요청했다.

시간이 지날수록 개발자나 테스터와 짝을 이루어 업무를 진행하는 일이 많아졌다. 또한 자동화 테스트나 빌드 시스템, 가벼운 성능 테스팅과 같은 전문적인 영역에서 업무를 수행하는 나 자신을 발견할 수 있었다. 개발자 그룹이나 관리자, 의사 결정권자들이 참여하는 다양한 회의에서도 좀 더 전문적인 역할을 수행할 수 있게 되었다.

물론 나와 다른 경로로 가는 사람들도 많다. 대학에서 대기 공학(atmospheric science)을 전공했던 내 친구는 소프트웨어 회사의 지원부서에서 첫 사회 생활을 시작했는데, 몇 년이 지난 다음 테스터로 이직했다. 오늘날 그녀는 회사에서 소프트웨어 테스팅에 대한 생각을 재정립하고 어떻게 이 업무를 수행해야할지 가이드를 제시하는 일을 하고 있다. 또 다른 친구는 지난 10년 가량을 프로그래머로 재직하고 이후 5년 가량을 테스팅 업무에 종사했다. 지금은 그의 독립적인 회사를 운영하고 있다.

앞서 두 친구의 경우처럼, 그리고 더 많은 다른 사람들이 그러하듯 잠시 테스팅에 몸담고 떠나는 경우가 비일비재하다. 이런 경험이 그들로 하여금 더욱 숙련된 인력이 되도록 만든 것은 자명한 일이다.

세상 밖에서

---

직장 생활의 초반에는 무척 코드를 작성하는 일을 하고 싶었다. 그 무렵 API를 조금 손봐서 피트니스(Fitnesse)라는 툴을 활용할 수 있도록 테스트 스위트를 만들려고 한 적이 있다. 개발자와 관리자에게 부탁하고 논의하면서 그 툴에 대한 다양한 정보를 얻을 수 있었지만 결국은 그 작업을 완료하지 못했다. 어떤 개발자도 그들이 다룰 수 있는 툴의 목록에 하나의 툴을 더하기 위해 시간을 투자하고 싶어하지 않았기 때문이다. 그들은 기본적인 기능 구현과 빠듯한 런칭 일정에 시달리기 일쑤였다. 관리자들 역시 영업부와 제품 담당 매니저들과 함께 어려운 일을 수행하느라 늘 바빴기 때문에 테스팅 같은 전략적인 목표를 고려하기 쉽지 않았다. 결국 그 누구도 새로운 테스팅을 도입하는 리스크를 감당하려는 사람들이 없었던 것이다.

1년 정도 지난 다음 난 결국 그 회사를 떠나기로 마음먹었다. 그 다음 회사는 REST API를 활용해 만들어진 마케팅 플랫폼 회사였다. 이 회사에는 POC(Proof Of Concept)를 위해 만들어진 소규모 테스트가 수행되고 있었다. 하지만 실질적인 효과를 거두지 못하고 있었고 지속적 통합(CI; Continuous Integration) 시스템 상에서도 수행되지 않고 있었다. 나는 리드 테스트 직무로 면접을 진행했지만, 좀 더 기술적인 업무를 수행하고 싶었다. 회사에서도 흔쾌히 이 부분에 동의해 주었기 때문에 기꺼이 이번 회사에 합류할 수 있었다. 처음 몇 주 동안은 Frisby.js라고 부르는 자바스크립트 프레임워크를 조사하는 데 시간을 투자했다. 입사 초기에는 테스트 코드를 만들기 위해 개발자와 짝을 이루었지만 이후에는 스스로 테스트 코드를 작성하고 이후 코드 리뷰를 함께 수행했다. 수행되지 않는 테스트는 아무런 도움도 되지 않는다. 따라서 그 다음에는 운영부서 담당자들과 함께 짝을 이뤄 빌드 서버에 Frisby를 설치해 API 브랜치에서 코드 변경이 있을 때마다 테스트가 수행되도록 만들었다.

두 번째 직장은 내게 스킬을 발전시킬 수 있는 발사대가 되었다. 테스트 코드를 작성할 수 있는 새로운 기법들을 경험할 수 있었으며, 지속적 통합 시스템에도 손을 댈 수 있었고, 페어 프로그래밍과 페어 테스팅의 놀라운 효과도 경험해 볼 수 있었다.

새로운 경험을 획득하고 연봉을 올릴 수 있는 가장 쉬운 방법은 좀 더 높은 직급으로 승진하고 좀 더 전문적인 고급 인력이 되는 것이다. 이는 안락하고 편안한 상황을 미련없이 버릴 수 있을 때만 가능하다. 지금 일하는 회사를 무작정 떠나라는 것이 아니다. 하지만 당신의 미래를 지금의 회사가 보장해 주는 것도 절대 아니다. 배우고 싶은 스킬이 있고, 실제로 그 스킬을 통해 실무를 진행하고 싶은데 지금의 회사에서 이끌어줄 사람이 없다면, 그 기회는 지금 다니는 회사가 아닌 다른 곳에 있는 것이며 이 기회를 찾아야만 할 것이다.

 

급변하는 소프트웨어의 세계에서

---

10년 전 테스터들은 상세한 명세서를 가지고 자세한 테스트 계획을 수립하고, 그에 맞춰 테스트 케이스를 작성한 다음 그 케이스를 그대로 실행에 옮기고는 했다. 5년 전부터는 테스터들이 개발 조직으로 스며들어가 유저 스토리를 활용하고, 소프트웨어를 더 빠르게 제품화 할 수 있도록 개발자와 짝을 이루어 테스팅 작업을 수행하기 시작했다. 오늘날 우리는 숙련된 테스터들이 능숙하게 프로그래밍을 진행하고 다양한 툴을 전문가처럼 다루고 있는 것을 쉽게 목격할 수 있다. 이들은 코드가 작성되기 시작하는 시점부터 개발자와 짝을 이루어 함께 작업하고, 코드가 체크인 되기전에 이를 검토하고, 자동화 코드를 작성하고, 개발 파이프라인을 구축하는 작업을 함께 수행한다.

개발팀과 동떨어져 일해왔던 테스터들은 이런 시류에 올라타 자기 스스로를 개발할 기회를 놓친 것이다. 이들은 회사가 제공하는 복지와 연봉에 목매고 있거나, 언제든지 다른 회사로 이직할 준비가 되어 있다고 스스로 착각에 빠져 있는 것이다. 유저 스토리에 목매는 사람들은 다음 릴리즈에 어떤 것이 포함되어야 하는지에 대한 정보가 전혀 없거나 거의 없는 상황에 처해있는 것이다.  

적극적으로 커리어 패스를 관리한다면 재직 중인 회사에서 필요로 하는 적절한 인재가 될 수 있으며 아울러 더 넓은 소프트웨어 개발 시장에서 필요로 하는 인재가 될 수 있을 것이다. 그렇다고 로드맵이 필요한 것은 아니다. 테스터로서의 경력이 사전에 세세하게 계획을 짤 수 있는 워터폴 프로젝트는 아니기 때문이다. 하지만 어떤 스킬이 필요하고 실제 업무에 반영할 수 있는 기술에 대해 고민해 보는 것은 분명히 이 길을 헤쳐 나갈 수 있게 해주는 이정표가 될 것이다.

테스터로서 당신의 경력이 조직도나 회사 내 승진 체계에서 그려질 수 있는 것은 아니다. 대신 지금 당신이 무슨 일을 하고 있는지, 어떤 것에 흥미가 있는지, 그리고 그것을 어디서 얻을 수 있을지에 대해 깊이 고민해봐야 한다.

빌드 시스템이나 API 자동화의 전문가가 되고 싶은가? 그럼 그런 전문가가 되면 된다.  

소프트웨어 테스팅을 수 년간 배우고 PM으로 이동한 다음, 프로그래밍도 배워보고 다시 테스팅으로 돌아오고 싶은가? 마음 먹은 대로 해라.

모든 경험과 다양성들이 당신을 더욱 나은 존재로 만들어 줄 것이다. 켐 케이너(Cem Kaner) 박사는 그의 경력이 품질을 핵심으로 그 주위를 돌면서 추는 춤과 같았다고 말했다. 다양한 역할을 거치면서 소프트웨어 품질을 더욱 깊이 이해할 수 있었다는 것이다.

춤추길 두려워해서는 안된다.