몇년 전에 읽었던 "조엘 온 소프트웨어"라는 책이 있습니다. 혹시 아직 안보신 개발자 또는 개발자와 함께 일하시는 분들은 한번 읽어 보시기를 추천합니다 ; 이 책의 22장에 보면 " 테스터를 두지 않는 (잘못된) 다섯가지 이유 " 라는 부분이 있습니다. 

다섯가지 이유를 저자는  1)  버그는 프로그래머가 게을러서 생기니까요.  2) 우리 소프트웨어는 웹에 올려놓아서 버그는 금방 고쳐질 수 있으니까요. 3) 고객이 소프트웨어를 테스트해줄 테니까요. 4) 우수한 테스터는 테스터로 일하려고 하지 않거든요. 5) 테스터를 고용할 돈이 없으니까요. 로 들고 있습니다.

이러한 이유를 들어서 테스터를 두지 않는 다면 멍청한 짓이다! 라고 저자는 이야기 하고 있습니다. 저 역시 이 부분을 상당 부분 동감합니다. 제가 지금까지 보고, 겪은 거의 모든 회사는 출시 전날까지 작업을 합니다. 심지어는 패키징 하기 직전까지 코드 작업을 하는 경우가 있습니다. 그나마 그 작업이 버그 수정이라면 다행이지만, 기능 추가와 같은 신규 코드 작업도 있습니다. 그리고는 그냥 업로드 해버립니다. 가끔은 그럴때, 그런데 이거 테스트 없이 그냥 풀어도되나요? 라고 물었을때 거의 모든 사람의 경우 (심지어 나 역시) "테스트 서버(베타 서버)에 올릴 것이니까 괜찮아, 버그 테스트는 유저들이 해줄테고 리포트 들어온거 수정해서 다시 패치 하면 되지" 라는 말을 합니다. (반성중)

바른 자세일까요? 네. 마치 이건 도덕 시험 같습니다. 누구나 저런 자세가 옳다고는 생각하지 않습니다만 "현실"을 생각하면 어쩔 수 없다는 거죠. 네. 저도 현실을 생각해서 저렇게 행동하고 답 했습니다. 그런데, 왜 현실을 고려 할 수 밖에 없는 것일까요? "테스터를 고용할 돈이 없으니까요" 라고 말합니다. 와우! 다섯가지 이유를 하나씩 정말 다 따라갑니다! 

버그가 없이 프로그램을 작성 할 수 있는 프로그래머는 세상에 없습니다. 버그는 프로그래머가 미처 생각하지 못하고 지나친 부분에서 발생합니다. 버그는 프로그램에게는 필연적인 존재입니다. 어떻게 해서든지 출시전에 그 문제점을 찾아서 프로그래머에게 전달을 해야 합니다.

기업에게 있어서 "이미지"라는 것은 매우 중요한 요소입니다. 유저(고객)에게 각인 되는 이미지 중에서 제일 강한 녀석은 바로 첫 인상이죠. 사람과 마찬가지 이지만 말이죠. 어쨋든, 고객이 다운로드 받은 프로그램을 실행 했는데 어처구니 없는 버그가 나온다? ... 그 엄청난 이미지 훼손을 회복하는데 걸리는 시간은 예상을 뛰어 넘습니다. 또한 만약에 그것이 이미 시장에서 어느 정도의 점유율을 차지 하고 있는 제품이 아닌 신규로 릴리즈 된 녀석이라면 시장의 기대 값은 정말 순식간에 0점까지 치닫게 됩니다. 고생은 고생대로 하고, 욕은 욕대로 먹고.. 한 국가에만 릴리즈 되는 것이라면 그나마 이정도 선이지만 해외 파트너사로 릴리즈 했을때는 ... 이거 참 난감해집니다.

이러한 문제는 테스터 조직을 갖추게 된다면 상당 부분 해결이 되지 않을까요?

테스터는 꼭 전문가여야 할 필요는 없습니다. 특정 고객층을 목표로 배포 되는 프로그램이 아닌 대부분의 프로그램은 불특정 다수에게 배포 되어 사용이 되어집니다. 테스터 조직을 전문적으로 관리해줄 관리자와 일반 사용자 처럼 해당 프로그램을 사용해줄 테스터만 있어도 충분한 효과를 낼 수 있습니다! 출시가 잦아서 잦은 테스트가 필요한 제품이 아니라면, QA 조직의 대부분을 임시직 (계약직을 비롯한 파트타임 아르바이트)으로도 충분합니다. 오히려 불특정 다수에게 배포 되는 프로그램은 전문적 지식을 갖추지 않은 일반인 파트타임 아르바이트가 더 효과적일 수도 있습니다. 아니면 해당 소프트웨어를 사용하는 사람들 중에 일부를 파트 타임 아르바이트로 고용해서 테스트를 진행 하게 할 수도 있습니다!

버그가 발견 되면 프로그래머는 슬퍼 할 수 밖에 없습니다. 내 자식 같은 코드에서 버그가 .... 가 아닌 한 밤중에 끌려 나올수도 있기 때문입니다!!! 한 밤중에 긴급 점검을 위해서 택시를 타야 하는 경우, 얼마나 가슴이 아픈지 모릅니다.

테스트 조직에 모든걸 다 해결해 주리라고는 믿지 않습니다. 다만, 테스트 조직의 QA 단계를 지나치면서 고객에게 가는 버그의 수를 줄이고, 버그에서 깍아 먹는 회사 이미지를 보호하고, 한 밤중에 긴급 점검으로 끌려 나오는 빈도 수를 줄이기는 해주리라고는 믿습니다.

아, 그렇다고 프로그래머에게 테스트를 맡기면 안됩니다. 프로그래머는 테스트를 싫어합니다. 또한 테스트를 진행해도 일반 테스터 보다 버그 발견률이 낮을 수도 있습니다. 그것은 아이러니 하게도 프로그래머는 정상적인 방법으로만 사용을 하는 경향이 크기 때문입니다. 하지만, 애시당초 정상적인 프로세스 상에서 버그가 발견 되서 출시 되는 경우는 적습니다. 일반 사용자는 정상적은 방법으로만 사용하지 않습니다. =_= 

아 뭐 ..

그냥 테스트 전문 조직이 있었으면 좋겠다는 푸념이었습니다. 버그 없는 게임을 만들어서 유저에게 욕을 그만 먹었으면 좋겠습니다. ㄷㄷ

이제는 청춘불패나 보러 가야겠습니다. ...;

p.s 테스트 조직에게 출시 거부권이 있다면 더 좋겠지만, 현실적으로는 힘들겠군요. 어떤 회사도 출시를 늦출리는 없을테니 프로그래머를 더 쪼아서 ... ... 저도 프로그래머인지라 차마 더 쪼임 당할 수 있는 발언은 차마 할 수가 없군요 ㅋㅋ

posted by Yuno.org
  • 레이니아 2010.03.20 18:21

    (테스터를 여럿 해본 입장에서) 잘 읽고 갑니다^^
    이상하게 꼭 테스터가 버그보고를 한 이후에 프로그래머분들이 버그재현하실 때에는 꼭 정상작동하곤 해서 마찰이 잦곤 했는데...(...)

    알 수 없는 특정한 조건에서 버그가 튀어나올때 프로그래머분들의 얼굴에 생기는 고뇌는 지금 생각해도 가슴이 아프네요:(

    다시한번 글 잘 읽고 갑니다^^

  • YDK 2010.03.20 21:03

    학교를다니는 학생입니다. 늘 제가 만든코드를 테스트하는과정에서는 버그가 없는데 교수님께 제출하는날부터 거의 매일 버그의 존재를 이메일로 받습니다. 실무에서도 똑같네요, 뼈속깊은곳까지 습관을 들여놔여 겠습니다. 좋은글 잘 보고 갑니다.^^

  • sziim 2010.03.22 13:05

    좋은글 잘 보았습니다.
    작년에 인턴으로 소프트웨어 기업에서 소프트웨어 테스트 엔지니어로 일할 기회가 있었는데
    그곳은 출시 전에 QA승인 없이 출시가 불가능한 프로세스를 갖고 있었습니다.
    그때는 그러한 프로세스... 당연히 학교에서 배우던대로 진행되는구나 싶었는데

    어느덧 학교를 졸업하고 취직을 하니 실제로 저 프로세스를 운용하는 회사는 없는거 같더군요.
    생각해보니 제가 일했던 그 곳도 단기간 수정 불가능한 이슈는 1차 업데이트로 모두 돌려버리고 출시일에 맞춰 출시했지만요 ㅋ