소프트웨어 테스팅, 진정 누구를 위한 테스터가 될 것인가.

다 쓰고 나서 느낀겁니다만, 조금 길게 되어버렸습니다. 실은 시간이 흐름에 따라 점점 떨어지는 글 실력에다가, 횡설수절 하는 것까지 겹쳐지면서 더이상 퇴고(堆敲)하는 것은 고사하고, 글 마무리 짓는 것 부터 힘들어지네요. -_-; 그래도 읽으실 분 계신다면 안 말립니다~ ^ㅡ^

내부적으로 왠만한 테스트를 거친 제품이라면, 임의로 선택된 베타 테스터에게 건네지게 됩니다. 이 베타 테스터들도 말이 테스터지 결국 최종 사용자입니다. 정식적으로 공개되기 이전의 제품을 소수의 선택된 일반 사용자들이 가지고 ‘놀 수’ 있도록 기회가 주어지는 것이 결국 베타 테스팅이니까요.

사담입니다만, 제가 베타 테스팅을 해본 경험이라곤, 디아블로 2 클로즈드/오픈 베타 테스트 그리고, 와우 오픈 베타 테스트 뿐입니다. 그것도 정식으로 블리자드에 결과나 버그를 보고한 적은 없으니 참 ‘일반적인’ 테스터였죠. 😀

그런 제가 9월 부로, 어느 덧 근 2개월 동안 SV&V 부서에서 테스트 일을 맡아왔습니다. 아직 인턴 기간은 10개월이나 남아 있으니 섣부른 결론은 이른 시기이기도 하지만, 제가 요즘 스스로에게 질문을 내던지는 것이 바로 ‘나는 과연 진정으로 뛰어난 테스터 인가 아니면 골치아픈 베타 테스터일 뿐일까?’ 입니다.

뛰어난/훌륭한 내부 테스터 VS. 성가신/골치아픈 베타 테스터

회사에서 월급 (격주간으로 급료를 주니, 격주급이라고 불러야 될려나요) 을 받아서 생활하는 저로서는 회사를 위해 일을 하는 건 당연한 건지도 모릅니다. 물론 일이란 자기 자신, 결국 돈을 벌기 위해 하는 것이다 하는 철학적/논리적인 문제는 우선 잠시 접어두기로 하죠. 그런 제가 과연 회사에 이득을 주고 있는 것인가 아니면, 되려 항상 일을 크게 만들어서 손해를 불러 일으키고 있는 건 아닌지 가끔씩 궁금해 집니다.

그도 그럴 것이 제가 고집하는 테스트 방식은 항상 ‘이렇게 하면 어떻게 될까요?’ 하는 생각에서 멈추는 것이 아니라 ‘이렇게 하면 어떻게 되는 지 한번 해봅시다.’ 랍니다. 물론 이것이 꼭 나쁜 방식은 아니지만, 최선의 방식도 아닌 것이 바로 이런 이유 때문이죠.


  • 우선 근본적으로, 주어진 시간과 인력을 따진다면 모든 변수를 일일히 다 따져 보기란 불가능합니다.

  • 자신이 진짜 최종 사용자가 아닌 이상, 진정으로 무엇이 요구되는 지를 알기란 참 힘들죠. 조금은 자격지심인 것이, ‘제품 요구 사항/문서를 바탕으로 나는 이렇게 이렇게 되기를 기대했었고, 테스트한 결과 제품은 내가 기대한 모든 일들을 제대로 해냈다.’ 라는 게 대부분의 테스터들이 (저를 포함) 할 수 있는 말입니다. 하지만 이것이 충분하냐? 그건 모릅니다. 알 수가 없어요. 사용자가 어떤 (멍청한) 행동을 할지 어떻게 안단 말입니까.

결국 제가 하는 테스팅 방식은 회사에겐 그다지 유익하지 않을 지도 모릅니다. 우선적으로는 겉으로 드러난 부분을 중점적으로 확인해보면 될터인데, 숨겨진 곳곳 다 찔러보는 게 제 테스팅 방식이다 보니, 마감전에 출시를 완료해야 겠는 데 사용자 배려를 이유로 항상 이곳 저곳 안 ‘쑤셔’ 보는 데가 없게 되어 버렸네요. 덕분에 다른 테스터들이 발견하지 못한 버그들을 곧잘 발견해내곤 합니다. 문제는 이 발견이 가끔은 이미 때로는 너무 ‘늦을 때가’ 있다는 것에 있습니다.

그렇다면 이 경우에, 한 개인이 아닌 회사에 종속되어 있는 사람은 어떻게 처신해야 할까요. 뒤늦게서야 발견된 문제를 과연 보고해야 될까요? 아니면, 최종 사용자가 직접 보고하기를 기다려서 그때 해결해야 할까요. 맡은 프로젝트의 중요성과 제품의 완성도, 역할에 따라서, 이 문제는 좀 더 복잡해집니다. 솔직한 심정으론, ‘나만 모른 척’ 하면 아무도 알지 못할 경우도 꽤나 있습니다.

모른 척 시치미 VS. 무조건 보고

상사가 과연 어떤 부하를 제일 아낄지는 저로선 당장은 알 길이 없습니다. 저도 부하사원을 좀 거느리게 되면 알게 될까요? 제 경험에 비추어선 궁극적으로는 아랫사람은 위 두가지 선택권 사이에서 갈등하게 될 것 같습니다.

솔직히 살짝 모른 척 하고 넘어가 버리면, 나중에 자기 자신에게 돌아오더라도, ‘아, 그건 계획에 없었는데, 사용자가 조금 예측 못했던 (멍청한) 일을 벌였나 보군요’ 라고 말입니다. 위 변명은 자기 자신의 직업이 테스터라면 (아직 인턴이지만, 저처럼 말입니다) 더욱더 잘 먹혀 들어갈 겁니다. 상사도 모든 변수를 다 테스트 해볼 수 없다는 건 인정하고 있을 테니까요.

하지만, 무조건 보고하는 경우엔 어떨까요. 상황에 따라 다르지만, 보통의 경우, ‘오 좋은 발견/지적 이야’ 하는 식의 칭찬이 나올지도 모릅니다. 그래도 극심한 상황에선 예를 들어 이미 제품이 다른 부서의 손에 건네 졌다던가 하는 상황에선 마냥 칭찬이 나오지는 않겠죠. 그렇지만 여전히, 문제는 문제이기에 보고되어서 문서화 된 후 최종사용자에게 알려진다는 건 참 중요한 부분입니다. 최종 사용자/고객 이 아무것도 모른 상태에서 뒷통수를 맞는 일이 생기는 경우와, 발생할 가능성이 높은 문제점에 대해 이미 인지하고 있다가 진짜 그런 문제가 발생했을 때의 경우는 전혀 다르니까요. 적어도 후자의 경우에선 ‘우리가 진작에 말씀드렸지 않습니까’ 하는 입장 표명이 가능하지 않습니까. 그에 비해 전자의 경우엔 문제가 심각한 경우 소송을 당해도 할 말이 없을 지도 모릅니다.

그렇기에, 길게/멀리 보자면, 문제가 발견 되었으면 상사한테 꼭 보고하는 것이 최선인것 같습니다. 뭐 당연한 것 처럼 들릴지도 모르겠지만, 욕먹을 각오 하고 보고하는 것이 얼마나 힘든 일인데요.

결국엔,

전 인턴입니다. 그냥 잊혀지겠지 하고 넘어 가려하는 생각은 이미 옛날에 은하수 저편으로 관광보냈습니다. 그래서 항상 다 찔러보고 문제가 생기면 꼭 보고하는 쪽을 선택했습니다. 보고해야할 거리인지 아닌지의 기준은 제가 감히 잴 수 있는 게 아니더라구요. 😀 덕분에 저는 나름대로 친하게 지내는 웹개발부 팀에게 ‘성가신 베타 테스터’로 보여 질지도 모르겠습니다. 가끔 돌이켜 보면서 후회/한탄 하기도 하지만, 어딘가에서 읽었던 문구를 신조로 삼고 버텨내고 있답니다.

그 문구는 바로,

“과거를 이야기하는 사람들이 있을 때, 미래를 준비하는 사람이 있습니다.”

실은 위 문구는 어디선가 인터뷰 관련 기사가 올라왔을 때, 인터뷰때 하는 좋은 말 중에서 건진겁니다. 어디서 봤는 지 기억이 안나네요. 다음에 찾게 되면 올리죠. 여하튼 미래를 준비하는 사람이 되기 위해 과거에 크게 연연하지 않기로 했습니다. 😀