테스팅 심리학 (1)

View Comments

Posted by OEHAN

율리우스 카이사르는 다음과 같은 명언을 남겼다.

 인간은 자신이 보고 싶어하는 것만 본다.
그리고 베르그송은 이렇게 이야기 했다.
 우리의 눈은 마음이 이해할 준비가 되어 있는 것만 본다.
우리는 이렇게 자신이 기대하는 대로 보는 경향이 있다. 실제 이것에 대한 심리학적 연구도 있다고 한다. 열심히 구글링을 했지만 찾지는 못했다. 어쨌든 이것과 관련해서 Cem Kaner는 자신의 저서(Testing Computer Software)에 다음과 같은 아주 중요한 말을 남겼다.

If you want and expect a program to work, you will be more likely to see a working program - you will miss failures. If you expect it to fail, you'll be more likely to see the problems. If you are punished for reporting failures, you will miss failures. You won't only fail to report them - you will not notice them.

요약해보면, 당신이 많은 버그를 찾길 원한다면 많은 버그를 찾을 것이고, 테스트 중인 프로그램이 올바르게 동작하길 기대한다면 많은 버그를 놓칠 것이다, 라는 것이다. 정말 그러한가? 개발자의 테스팅과 테스터의 테스팅, 각각의 결과를 서로 비교해보면 알 수 있다.

개발자는 프로그램이 잘 동작하여 문제없이 시장에 출시되길 바라는 사람이다. 그래서 개발자가 하는 테스팅은 문제를 발견한다기 보다는 제품이 잘 동작하는지를 확인하는 것에 좀 더 포커스가 맞춰져 있다. 또한 인간이라면 지니고 있는 인지 부조화 현상 때문에 자신의 코드는 문제가 없다고, 심지어는 완벽하다고 생각하는 사람들이다. (이것 관련해서는 ikooyas 님의 포스팅 참조 http://ikooyas.tistory.com) 테스팅 결과, 아주 기본적인 기능들이 일부 문제가 있음을 발견하고, 그것들은 큰 어려움없이 수정된다.

개발 내부 테스팅이 완료되고, 소프트웨어가 테스터에게 주어진다. 테스터는 문제를 발견하는 사람이다. 그래서 테스터가 하는 테스팅은 완벽하지 못한 제품 안에 잠재된 버그들을 하나라도 더 찾아내는데 포커스가 맞춰져 있다. 아주 기본적인 기능들에 대한 확인 뿐만 아니라 테스터 자신의 모든 경험과 사고력을 총동원하여 조합 테스팅, 시나리오 테스팅, 몽키 테스팅 등 다양한 테스팅을 통해 복잡하고 미묘한 (수정하기 까다로운) 문제들을 발견해낸다.

간혹 개발자가 정상 동작한다고 알려준 기본적인 기능에서도 문제가 발견될 때가 있다. "대체 개발자는 뭘 테스트한거야?!!"라고 소리치지만 이러한 인간의 심리적인 현상을 이해한다면 충분히 납득할만한 사실이다.

다시 정리해보면, 어떤 마음 가짐으로 소프트웨어를 바라보고 테스팅에 임하느냐는 정말 중요한 이야기이다. 테스터가 버그를 찾는 일에 혈안이 되어있지 않으면 곤란하다. Myer의 책에 다음과 같은 비유가 나온다. 당신이 어느 날 갑자기 아프기 시작해서 의사를 찾기로 마음먹는다. 의사에게 찾아가 진단을 받는다. 진단 결과, 의사는 당신의 몸에 아무런 이상이 없다는 판정을 한다. 실제로 당신이 어떤 병에 걸렸다면, 병을 찾지 못한 이 의사를 우리는 어떻게 평가할 수 있을까? 테스터는 의사이고, 당신이 검증하는 소프트웨어는 아픈 환자라고 생각해보자. 버그를 찾지 못하는 테스터를 우리는 어떻게 평가할 수 있을까? 이 이야기에서 의사와 테스터의 능력과 자질이 문제였을지도 모르지만, 나는 그것보다 '마음 가짐'이 더 중요하다고 본다.

이처럼 인간이 지닌 심리적인 취약점(?)들은 우리가 생각하고 행동하는 것에 많은 영향을 미친다. 여기서 외부적인 환경 요소도 중요하다. 테스터가 버그를 찾아냈음에도 환영받지 못하는 분위기라던가, 테스팅 팀이 독립적인 위치를 고수하지 못하고 개발팀 내부에 소속되어 있다면 테스터가 버그를 발견한 것에 대해 질책이 있을 수도 있다. 시장 출시 일자가 가까울 수록 점점 더 그럴 것이다. 당장 출시해야 하는데 이제와서 이런 문제(Showstopper Defect)을 발견하면 어떡하냐고 소리를 칠 것이다. DRE(Defect Removal Efficiency) 관점에서 볼 때 심각도가 높은 문제가 개발 프로세스 뒷단에서 발견된 것은 분명 문제가 있지만, 무작정 테스터를 나무랄 일은 아니다. 그는 다시는 이러한 심각도 높은 문제들을 보고하지 않을 것이기 때문이다.

테스터가 자신의 일에 대해 자부심을 갖지 못하는 것도 영향을 미친다. 낮은 대우, 낮은 연봉, 낮은 인지도 등 많은 것들이 테스터로 하여금 자부심을 갖지 못하게 하고 결국 테스팅 효율은 떨어지게 된다. 만약 이런 사람이 있다면 Cem Kaner가 쓴 다음 글귀를 명심해야할 것이다.

You take a destructive attitude toward the program when you test, but in a larger context your work is constructive.
테스터는 테스팅을 할 때 제품에 대하여 "파괴적인" 태도를 취하게 되지만 이것은 큰 맥락(품질개선) 속에서 "건설적인" 일이 된다,는 것이다. 테스터는 다른 말로 Devil's Advocate이라고 정의하는 사람들도 있다. 그 참된 의미를 되짚어볼만 하다.


-------------------------------------------------
심리학적인 이론들에 근거해서 글을 풀어나가려 했는데 쓰다보니 이상하게 되었다는... :-)

 

2 Comments (+add yours?)

  1. Favicon of http://www.facebook.com/profile.php?id=100001445663340 BlogIcon 한주성 2012/01/24 23:24

    작년 글을 지금 다시 보니 감회가 새롭네요.
    좋은 글 항상 감사합니다.

     Reply  Address

  2. Favicon of http://noogabar.com BlogIcon OEHAN 2012/08/08 09:06

    저도 잘 봐주셔서 감사해요.

     Reply  Address

Leave a Reply

트랙백0 Tracbacks (+view to the desc.)

Trackback Address :: http://noogabar.com/trackback/102 관련글 쓰기

Newer Entries Older Entries