개발자에게 테스트를 하라고 시키는 것은 여러가지로 비효율적인 일입니다.
테스트는 테스터가 하는 것이 훨씬 시간도 덜들고 S/W의 품질도 빨리 높일 수 있습니다.

그 이유는 이렇습니다.

첫째, 개발자에게 들어가는 시간당 비용은 테스터의 그것 보다 2배 정도 비쌉니다.
개발자 10명에게 1시간을 테스트 시키는 비용으로 테스트 20명에게 1시간을 테스트 시킬 수 있는 것이죠.
게다가 테스터는 개발자 보다 버그를 훨씬 잘 찾고 많이 발견합니다.

둘째, 개발자는 원래 테스트를 잘 하지 못합니다.
개발자가 테스트를 하나도 못한다는 얘기가 아닙니다. 또 제가 개발자라 테스트를 싫어해서 하는 말도 아니지요.
그것은 바로 좋은 개발자가 가져야할 성격이나 자세와 좋은 테스터가 가져야할 성격과 마음자세가
완전히 상반되기 때문입니다.
예를 들면, 좋은 개발자는 어떠한 풀어야할 문제를 발견했을 때
그것을 근거없이 일단 '이것을 해결할 수 있다', '잘 동작할 것이다' 라고 생각하고 문제를 분석합니다.
그렇지 않으면 그 문제는 쉽게 풀리지 않습니다.
S/W로 좋은 품질의 코드를 내놓는 좋은 개발자들은 이러한 긍정적인 마음가짐을 기본적으로 가지고 있습니다.

하지만, 반대로 좋은 테스터는 자기 앞에 있는 S/W가 '잘 동작하지 않을 것'이라고 가정하고
테스트를 해야합니다. 하나도 놓치지 않고 무자비하게 테스트하려면,
이 S/W는 그럴싸해 보이지만 사실 엉망진창일 것이라고 가정하고 하나씩 실행해 나가야 많은 문제를 발견할 수 있는 것입니다.

이런 이유 때문에 좋은 개발자는 좋은 테스터가 되기 힘들고(예외적으로 엄청 테스트 잘하시는 분도 있어요~ ^^)
그 반대도 마찬가지 입니다.

세번째, 이것이 제생각에는 가장 중요합니다만,
사용성 테스트, 즉 End User Test는 그렇게 높은 수율을 가진 결함 발견 방법이 아닙니다.
기껏 알려진 것이 높아야 35% 정도입니다. 또한 그것은 테스터가 많이 하고 있습니다.
차라리 그 시간에 더 높은 수율을 가진다고 알려진 다른 것들,
즉, Unit Test, Code Review, Code Inspection, Regression Test 같은 개발자만이 할 수 있는
다른 방법들을 시도한다면 같은 시간에 발견하는 버그의 수가 훨씬 많을 것입니다.
가장 수율이 높다고 알려진 (테스트 계의 사기캐릭터라고 불리웁니다.^^) 정형화된 코드 검토(Code Inspection)은
프로그램 내의 버그중 최고 90%를 찾아낸다고 알려져 있습니다.
이 말인즉슨 개발자가 테스트를 하고 있는것보다 같은 시간에 둘이나 셋이 모여 코드검토를 수행한다면
3배나 더 많은 버그를 찾아낼 수 있다는 뜻입니다.
(그것을 수정하는데 드는 노력까지 합친다면 훨씬 줄어듭니다.
 코드를 바로 검토했기때문에 디버깅에 드는 시간이 0이 되니까요.)

네번째 이유는요¹⁾ , 테스트 자체는 S/W 품질에 사실 아무런 도움도 주지 않는다는 것입니다.
테스트로 S/W에 결함이 있다는 것은 알수 있지만, 결함을 발견하는 것 자체는
S/W 품질을 올려주지 않습니다.
개발자에게 S/W를 Hard하게 테스트하게 한다면, 차라리 그 시간에 S/W를 더 잘 짜는 것이 낫습니다.


버그를 수정한 후에 그게 제대로 수정되었는지 한번씩 눌러보지 않냐,
개발자에게 부탁하는 테스트를 그 정도로 이해할 수 없겠느냐구요?
개발자 탁상 테스트(Desktop Test)는 모든 개발자가 하고 있습니다.
버그가 제대로 수정되었는지, 구현한 기능이 정상적으로 동작하는지, 당연히 눌러보고 돌려보고 테스트 해봅니다.
그리고 그 테스트에 걸러지지 않은 것이 버그로 나오는 것입니다.
개발자가 일부러 테스트를 하지 않은 것이 아니구요.
모아놓고 테스트를 시켜도 거기에 걸러지지 않은 것이 또 버그로 나옵니다.
어디에서 문제가 발생할 지는 아무도 모릅니다.
하지만 항상 확실한 건 전혀 생각지도 않은 곳에서 문제가 나올 것이라는 거죠.

왜 이걸 몰라주나 모르겠습니다.


1) 2010년 4월 7일 추가