[번역] 당신이 프로페셔널한 테스터가 아닌 10가지 이유 - Part 1

오늘 소개해 드릴 글은 Joel Montvelisky 의 “10 Reasons why you are NOT Professional Tester!”입니다.
누가바닷컴의 @OEHAN 님이 적극 추천해 주신 글입니다.

이 글은 당신이 프로페셔널한 테스터가 아닌 10가지 이유에 대해서 말하고 있습니다.
첫 번째 포스트에서 5가지 이유를, 이어지는 두 번째 포스트에서 나머지 5가지 이유를 설명하고 있습니다. 원 블로그에서는 저자 개인적으로 선택한 이유들이므로 프로페셔널한 테스터가 되지 못하는 다른 이유가 있다고 생각한다면 피드백을 주고 이에 대해 논의해보자고 제안하고 있습니다.
그래서인지는 몰라도 저자의 2번째 포스트에는 20개가 넘는 댓글이 달리며 이에 대한 활발한 논의가 진행되고 있습니다. 국내에서도 이번 기회에 이런 논의가 한 번쯤 진행되면 좋겠다는 생각이 듭니다.

개인적으로도 공감하는 내용이 많고 관심이 가는 주제인 만큼 2번째 포스트도 곧 번역하도록 하겠습니다.

번역 및 포스트에 대해서는 원 저자의 허락을 받았습니다.   

당신이 프로페셔널한 테스터가 아닌 10가지 이유 - Part 1

By JOEL MONTVELISKY

당신은 프로페셔널한 테스터인가? 만약 당신이 이 포스트를 읽을 정도라면 그럴지도 모른다. 이 포스트를 내가 썼다고 해서 그렇게 이야기하는 것은 아니다. 나보다 더 나은 것들을 공유해줄 테스터들은 수없이 많다.

만약 여유로운 시간에 테스팅 스킬을 발전시키기 위해 QA와 관련된 글들을 찾아서 읽을 정도라면, 아마 당신을 아직은 그리 많지 않은 프로페셔널한 테스터로 분류해도 괜찮을 것이다. 그리고 나는 그런 사람들이 점점 더 늘어나길 바란다.

 

완벽한 변명거리를 찾아보자

지난 주 나는 링크드인(LinkedIn)에서 IT 업종의 수많은 사람들이 “왜 테스팅이 전문적인 직업으로 간주되지 못할까?”라는 질문에 대해 열띤 토론을 벌이는 것을 볼 수 있었다.

 

이 질문에 대해 “대학에서 정식으로 테스팅에 관해 가르치지 않으니까”에서부터, “아직 테스팅은 새로운 분야이고 어떻게 이를 전문적으로 수행할지에 대해 아직도 배워나가고 있는 단계니까”에 이르기까지, 각기 다양한 답변들이 이어졌다.   

 

나는 또한 하릴없이 테스터들의 등뒤에 대고 “일하는 방식이 전문적이지 않으니까 전문직으로 대접받지 못하는 거지”라고 비난하고 가는 사람도 발견할 수 있었다.

 

나는 사람들이 그런 이야기를 들을 때마다 단순히 자기연민에 빠지거나, 혹은 스스로가 부당하게 희생되었다고 생각하기에 바빠서 그 근본적인 원인이 바로 우리에게 있다는 사실을 간과하고 있다고 생각한다.  

 

거울 속에서 답을 찾아라

자, 좀 더 솔직해져 보자. 우리가 비전문직으로 대접받는 것은, 우리가 스스로 프로페셔널한 테스터처럼 행동하는 것을 중요하게 생각하지 않아서이다.

 

내 경험에 의하면 테스터들이 일을 진지하게 받아들이고 이를 개선하려고 노력하는 곳에서는 언제나 그들 역시 존경 받으며, 그들이 수행하는 작업 역시 조직에 가치 있는 것을 제공하는 것이라고 인정받았다.

 

핵심은 바로 이것이다.

당신이 프로페셔널한 테스터가 아닌 10가지 이유는 무엇인가?

 
1 당신은 테스팅이 기술적인 전문직이 아니라고 생각하고 제품의 기반이 되는 코드를 이해하려고 노력하지 않는다. 

만약 당신이 소프트웨어 개발 분야에서 일하고 있다면, 소프트웨어 공학에 대해 최소한의 이해는 하고 있어야한다. 테스터로서 당신은 제품을 분석하고, 변경사항과 수정내용이 어떻게 제품에 영향을 끼치고 버그를 만들어내는지 이해하기 위해 코드를 읽을 줄 알아야 한다. “블랙박스” vs “화이트박스”라는 대결 구도를 내세우며 고전적인 패러다임 뒤에 숨는 것을 끝내야만 하는 것이다.  
물론 당신이 원하지 않는다면 굳이 코드를 작성하지 않아도 일을 계속할 수 있다. 하지만 당신이 코드를 읽을 수 없는 한, 당신은 전체 테스팅 프로세스에서도 가장 중요한 입력값을 제대로 이해하지 못하고 있는 것이나 다를 바 없다.

2 개발자로부터 빌드를 받으면서 “가서 테스트나 해”라는 말을 듣기 전까지는 프로세스에 참여하지 않는다.

솔직하게 한 번 물어보자. 우리가 개발 프로세스에 포함되는 시점은 언제부터인가? 이론상으로는 요구사항을 수집하고 분석하는 단계에서부터 팀의 다른 사람들과 함께 우리의 일이 시작되어야 한다. 하지만 현실에서는 개발자들이 기능에 대한 피드백을 달라고 요구하면서 우리에게 첫 빌드를 넘기기 전까지는 그 어떤 정보도 제공받기 힘든 것이 사실이다.

왜 이런 일이 계속 일어날까? 대부분의 테스터들은 개발이라는 악순환의 제일 마지막 고리 부분에 우리가 위치하고 있기 때문이라고 대답할 것이다. 다른 사람들이 다음 프로젝트를 대비하며 그들의 업무를 준비하기 시작할 때도 우리는 항상 이전 프로젝트의 테스팅 업무로 눈코 뜰새 없이 바쁘기 마련이다.

하지만 사실 하루에 2시간 정도 짬을 내어 기능 설계 회의에 참여할 수 없다는 것은, 곧 당신의 시간관리가 엉망이라고 말하는 것과 다를 바 없다. 당신이 개발 프로세스에 포함될 수 없는 이유도 바로 이것이다. 당신이 이를 중요하게 여기지 않거나, 그게 아니라면 당신이 이를 원하지 않기 때문이다.

3 고객지원 팀에서 당신에게 필드에서 발생한 버그를 재현해 달라고 요청할 때를
제외하면 고객들과 교감할 일이 없다.  
당신이 수행하는 업무는 필드에서 제품이 사용되는 방식대로 이를 테스트하고 버그를 사전에 발견해 내는 것이다. 제품이 발매되고 나서 이를 사용할 사용자에게는 이것이 아주 중요한 의미를 가진다.  

당신의 직업은 바로 개발팀 안에서 고객의 변호사 역할을 하는 것이다. 테스트를 계획하고 환경을 설정하는 것 모두가 고객이 어떤 일을 할지를 고려해서 수행되어야 한다. 또한 당신은 고객의 니즈와 제약된 환경을 고려해 기능적인 피드백을 개발팀에 줄 수 있어야 한다.

이런 상황에서 당신이 고객을 잘 모르면서 어떻게 그들을 대변하고 그들이 수행하는 작업을 시뮬레이션 할 수 있겠는가? 가장 최근에 고객들이 당신의 제품을 어떻게 이용하는지 알기 위해 현장을 방문해 본적이 언제인가? 정말 당신 스스로 고객이 당신의 시스템을 가지고 하는 일을 잘 알고 있으며, 고객의 제한된 작업 환경 역시 잘 알고 있다고 말할 수 있는가? 아마 대답은 아니오 일 것이다.

 

앉아만 있지 말고 현장에 나가 당신의 고객을 만나보라! 고객을 이해하고 알 수 있을 때까지, 테스터로서 당신의 일은 계속되어야 한다.  

 
4 리스크 관리는 보험이나 자산관리에서나 사용하는 단어라고 알고 있다.

테스팅에는 아주 간단한 진리 몇 가지가 있다. 그 중 “어떤 테스터도 가능한 모든 경우를 테스트 할 수 있는 충분한 시간을 가질 수 없다”라는 진리는 정말 간단하면서도 명백한 진리다. 기본적으로 리스크 관리가 필요하게 된 이유가 바로 이것이다. 우리는 어떤 것이 테스트되어야 하며, 그 중 어떤 것이 가장 먼저 테스트되어야 하는지, 그리고 테스트 결과에 따라 어떤 작업들이 뒤를 이어 수행되어야 하는지를 알기 위해 작업에 우선순위를 부여한다.

 

이는 단지 리스크 관리의 가장 단순한 측면을 본 것에 지나지 않는다. 리스크 관리를 좀 더 깊이 살펴보면, 오히려 당신의 팀과는 아무런 관련도 없는 것처럼 느껴질 수도 있다. 리스크 자체는 테스팅과는 직접적인 연관이 전혀 없기 때문이다.

 

모든 테스터들은 그들이 테스트하는 제품에서 어느 부분이 가장 위험한 부분인지를 잘 알고 있다. 항상 예상보다 더 많은 버그가 발생하는 부분과, 계획되지 않은 일정과 환경으로 인해 담당 개발팀의 작업이 항상 늦게 전달되는 부분이 바로 가장 위험한 부분인 것이다.

 

테스터로서 우리가 하는 일은 이러한 부분을 정확하게 알아내고, 프로젝트 기간 내내 해당 부분을 담당하고 있는 개발팀에게 이에 대해 경각심을 가지도록 일깨워주는 것이다. 이를 통해 제품의 다른 부분을 활용해 기능을 개발할지, 아니면 시스템을 안정화하기 위해 시간이 필요할 지 결정할 수 있게 된다. 이런 “계획되지 않은 이슈들”은 항상 그 제품의 상태를 단적으로 말해주고 있는 것이다.

 

당신은 이미 발생했거나 아니면 앞으로 발생할 가능성이 있는 모든 이슈, 즉 제품에 영향을 미칠 수 있는  모든 이슈를 분석하고 이를 해결할 수 있는 실마리를 던져주어야 한다. 프로젝트 팀이 현실적인 목표를 세우고 제한된 시간과 예산 안에 이를 달성할 수 있도록 도와주어야 하는 것이다.

5 당신은 당신이 수행하고 있는 테스팅의 가치를 개선할 생각이 전혀 없다.

테스팅이라는 일은 여러 모로 아직은 미지의 영역이다. 당신이 테스팅을 수행할 수 있는 방법도 가지각색이며, 테스팅이라는 세계를 전문적인 영역으로 개선할 수 있는 방법 역시 다양하다.

 

이러한 테스트 개선 작업은 대부분 개별적으로 수행된다. 또한 개별 테스터들의 역량을 개선하는 것을 기반으로 현재 상황에서 테스트에 대한 필요성을 부각시키고 이를 가로막는 제약 사항을 개선하는 것, 테스터가 활용할 수 있는 정보의 폭을 넓히는 것 등 여러 분야에서 동시에 개선이 수행될 수도 있다. 

 

간단하게 말해서 당신 스스로 프로페셔널한 테스터가 될 수 있는 방법은 한 가지가 아니라는 것이다. 하지만 이러한 개선 방법들은 결코 쉬운 일이 아니며 금방 이루어지지도 않는다. 따라서 당신이 정말 테스팅을 통해 개발 프로세스에 도움을 주어야겠다고 결심하지 않는 이상, 그리고 어떻게 이 목표를 이룰 수 있는지 이해하지 않는 이상 당신의 테스팅 스킬을 발전시키고 이를 통해 당신의 조직에 유용한 가치를 제공하기 힘들 것이다.  

 

그러면 어떻게 이런 개선을 이룰 수 있을까?

가장 처음 해야 할 일은 당신이 테스트로서 가지고 있는 강점과 약점을 분석하는 것이다. 이를 통해 당신이 개선하기를 원하는 부분(또한 개선을 통해 조직에도 도움이 되는 부분)을 정해야 한다. 그 다음 당신이 선택한 부분을 개선하는데 도움을 줄 수 있는 방법을 찾아보아야 한다.

 

한 가지는 분명하다.

당신이 이를 운에 맡기거나, 다른 테스터들이 당신을 이끌어주기를 바란다면 절대 이룰 수 없다는 것이다.

 

다음 포스트에서는…

곧 다음 포스트를 올릴 것을 약속한다. 일단 1부를 여기서 마무리하고 이번 주안에(아니면 다음 주 초에) 이어지는 포스트를 올릴 것이다. 여기에는 당신이 프로페셔널한 테스터가 될 수 없는 나머지 다섯 가지 이유에 대해서 언급할 것이다.

 

다음의 다섯 가지 이유에서는 스크립트 테스팅을 주로 수행하고, 툴로서 자동화를 사용하지 않으며, 일반적인 스킬들을 어떻게 관리할 지에 관한 내용이 이어지므로, 테스터로서의 캐리어 패스를 관리한다는 측면에서도 계속 관심을 가져주길 바란다.

 

내가 제시한 이유들에 대해서 자유롭게 피드백을 전달해 주기 바란다. 또한 당신이 생각하기에 우리가 동료들로부터 전문직으로 대접받지 못하는 추가적인 이유가 있다면 이에 대해서도 얘기해 주기를 바란다. 나는 우리 모두가 이 주제에 대해 충분한 인사이트와 좋은 의견을 제시할 수 있다고 믿고 있다.