십 년도 더 오래전에 같이 일했던 프로그래머가 있었다. 경력이 충분히 있는 프로그래머였는데, 경력에 어울리지 않게 그 프로그래머의 코드에는 문제가 많았다. 일단 버그가 다른 프로그래머의 결과물보다 몇 배 많이 나왔다. 게다가 수정했다고 얘기한 버그가 테스트 결과 수정되지 않은 것으로 판명된 경우도 많았다. 그래서, 일반적으로 7, 8번 정도의 테스트 반복을 거치면 제품을 출시할 수 있었지만, 그 프로그래머가 맡은 제품은 15번 이상 테스트를 거치는 게 보통이었다. 심지어 나중에는 테스트팀의 암묵적인 기피대상이 되기도 했다. 테스트해야 하는 제품의 개발자가 그 프로그래머이면 테스터들이 한숨부터 쉬는 상황이 되었다. 이후 버그가 너무 많아서 프로젝트가 좌초되는 상황까지 벌어졌고, 그 프로그래머는 결국 회사를 떠나야 했다.
세상의 모든 프로그램은 버그를 가지고 있다. 구글, 마이크로소프트, 아마존의 프로그래머들도 버그를 만들어 낸다. 버그가 좀 있다고 해도 프로그래머에게 큰 흠은 되지 않는다. 하지만, 수정했다는 버그가 수정되지 않은 것으로 판명되는 것은 흠이 된다. 실행조차 되지 않는 프로그램을 테스트팀에게 넘기는 것도 흠이 된다.
그 프로그래머에게는 여러 가지 문제가 있었지만, 가장 큰 문제는 테스트를 하지 않는다는 것이었다. 프로그래머가 테스트팀처럼 테스트하기는 어렵지만, 그래도 가장 기본적인 것들은 확인하고 다음 단계로 넘겼어야 했다. 그랬다면, 버그가 수정되지 않았다는 것도 알았을 것이고, 프로그램이 실행되지 않는다는 것도 알았을 것이다. 하지만, 그 프로그래머는 코드를 자기 생각대로 수정하기만 했고, 테스트는 온전히 테스트팀의 몫으로 넘겼다.
프로그래밍을 배우면 자기가 짠 코드를 테스트하는 방법도 배운다. 테스트를 통해 자신이 작성한 코드의 완결성을 보증하는 것이 중요하다는 것도 배운다. 그런데, 경력이 쌓이면서 오히려 테스트를 소홀히 하는 경우가 종종 발견된다. 일정이 빠듯해서 테스트를 충분히 할 수 없는 경우들도 있지만, 시간이 충분한데도 테스트에 공을 들이지 않는 경우들이 있다.
아티스트들은 아직 완성되지 않은 작업물을 보여주기 꺼려한다. 작업물을 통해 아티스트의 역량이 평가되기 때문이다. 기획자들도 다듬어지지 않은 기획 내용을 공개하고 싶어 하지 않는다. 마찬가지로 프로그래머도 문제가 많은 코드를 타인에게 공개하는 것에 주의를 기울여야 한다. 프로그래머가 아닌 사람들이 직접 코드를 보고 프로그래머를 평가하기는 어렵지만, 어떤 프로그래머가 넘긴 코드를 테스트하는 과정을 통해 그 프로그래머의 역량을 가늠할 수는 있다. 그래서, 부족한 코드를 테스트 단계로 넘기는 것은 부족한 실력을 보여주는 것과 같다고 생각해야 한다.
게다가 테스터가 아무리 전문성을 확보하고 있다고 하더라도, 프로그래머만큼 코드를 이해하고 있는 것은 아니다. 따라서, 테스터가 찾아내지 못하는 버그를 프로그래머가 찾아내는 경우도 많이 있다. 특히, 프로그램에서 매우 드물게 발생하는 상황은 테스터보다 프로그래머가 더 잘 발견해낼 수 있다.
결국, 자신의 실력을 증명하기 위해서도, 제품과 서비스를 온전히 고객에게 전달하기 위해서도, 프로그래머는 테스트에 적극적이어야 한다. 좋은 테스터가 되어야 좋은 프로그래머가 될 수 있는 법이다.