김기창 교수님의 '한국 웹의 불편한 진실'을 읽으면서 매번 하던 생각을 글로 올려보고자 한다. 누누히 얘기했던 말이지만 많은 사람들은 테스팅을 개발이 끝난 후에 기능 확인이나 하는 활동쯤으로 생각하는 경우가 많다. 테스팅을 이렇게 생각할 경우 테스팅 활동은 매우 제약적이 될 수밖에 없다. 테스팅을 하기 위해서는 테스트 케이스를 만들어야 하고 테스트 케이스에 꼭 포함되어야 할 항목 중에는 기대 결과와 실제 결과가 있다. 이 두 결과가 차이가 생긴다면 우리는 그것을 결함이라고 한다. 여기서 기대 결과의 기준이 되는 것을 테스트 오라클이라고 하는데.. 일반적으로 많이 사용되는 테스트 오라클은 기술명세서 계열의 문서들이다. 그런데 테스터가 무조건 YES!!! 만을 외치는 예스맨이 된다면 기술 명세서 계열의 모든 항목들은 진리가 된다. 거기에는 어떠한 의심도 개입할 여지가 없어져 버린다. 하지만 과연 그럴까? 그러한 명세서들이 항상 참일수 있을까? 명세서도 사람이 작성한다. 그리고 그러한 명세서에 담긴 내용들은 고객의 요구사항이다. 하지만 진짜로 고객의 요구사항을 수렴해서 작성된 명세서가 몇이나 될까? 아니면 고객의 요구사항이 반영된 명세서가 있다 할지라도 그것이 정말 고객이 원하던 것이라고 누가 말할 수 있을까? 고객의 요구사항을 수집/분석하고 문서로 만드는 과정 중에 사람이 실수할 여지는 얼마든지 충분할 만큼 넘쳐난다. 자신의 생각조차 글로 옮기는 것이 힘든 법인데.. 하물며 다른 사람의 생각을 글로 옮긴다면 그 과정에 잘못 전달되는 것들은 얼마나 될지 아무도 알 수 없다. 그래서 테스터는 이 모든 것을 의심하고 문제를 제기할 수 있어야만 한다. 그리고 이것이 테스터가 개발 초기부터 참여해야 하는 이유이고, 테스터의 존재 이유이다. 모두가 당연하다고 생각하고 모두가 참이라고 하는 것도 테스터라면 한번 더 의심하고 한번 더 생각해 볼수 있어야 한다. 그리고 그 기준은 항상 사용자 즉, 고객이 되어야 한다. 하지만 이런 의심이 너무 깊어져서 직업병 수준이...