테스트와 품질

  SW 개발 과정에는 수많은 테스트 절차가 있다. 회사마다 실시하는 종류는 다르겠지만 위키피디아에 기록된 것만 해도 무려 16가지나 된다.^[각주:1] 요즘 읽고 있는 책에 테스트에 관한 흥미로운 견해가 있어 본문을 옮겨 본다.

  테스트를 많이 할수록 품질이 좋아진다고 생각하는 사람도 있다. 정말 그랬으면 좋겠지만, 안타깝게도 그렇지가 않다. 테스트하면 결함을 찾는 데 도움이 되긴 하지만 코드 여기저기 숨어있는 결함을 테스트만으로 찾아내는 건 불가능하다. 아무리 열심히 테스트해도 상당수의 결함이 잡히지 않고 남아있을 것이고, 여기서부터 불편한 진실이 나타나기 시작한다. 테스트에서 기존 결함 중 특정 비율(예를 들어 65%)만큼을 찾아낸다고 해 보자. 그러면 테스트를 통해 찾아낸 결함이 많아질수록 찾아내지 못한 결함도 많아지리라고 예상할 수 있다. 테스트에서 결함이 많이 발견되면 실제 출시된 제품에 있는 결함 개수가 줄어드는 게 아니라 늘어나는 것이다. 직관적으로 보면 말이 안된다는 생각이 들 수도 있는데, 테스트 과정이 버그를 다 잡아내기 위한 절차라기보다는 품질을 측정하기 위한 통계적인 방법이라고 보면 이해가 될 것이다. 이런 이유 때문에 소프트웨어 공학 분야에서는 기능 테스트와 시스템 테스트를 각각 "기능 검증 테스트", "시스템 검증 테스트"라고 부른다. 소프트웨어 공학을 과학적으로 공부해 온 사람은 테스트 작업이 문제를 고치기 위한 작업이라기보다는 검증 절차에 가까운 것으로 봐야 한다는 인식이 자리 잡았기 때문이다. (..중략..) 안타깝게도 아직은 아무도 버그가 없는 소프트웨어를 개발하는 방법을 발견하지 못했다. 테스트를 통해 모든 버그를 찾을 수는 없기에, 테스트만을 통해서 최고 품질의 코드를 만들어내는 것은 불가능하다. 많은 회사에서 그런 시도를 했지만 모두 실패로 돌아가고 말았다. 역사적으로 보면, 코드 품질을 개선하고 버그를 없애는 데 있어서 가장 좋은 방법은 코드 검토다. 최고 품질의 코드를 개발하기 위해서는 설계 및 명세서, 코드 검토, 형식적인 인라인 (런타임) 확인 테스트, 측정 코드(Instrumented Code), 철저한 테스트 중 어느 하나도 소홀히 해서는 안 된다.

- 프로그래머로 사는 법, 한빛미디어, p324

  결론은 버그는 다음 그림과 같이 개발 후반부로 늘어나는 수정하는 비용이 늘어나기 때문에 초반에 잡으라는 말이다.

  위 그림은 SW를 업으로 삼는 사람이라면 책이나 교육을 통해 몇 번은 보았을 것이다.^[각주:2] 물론 폭포수 모델을 가정하고 있기는 하지만 개발 방법론이 무엇이 됐든 프로젝트 후반부로 갈수록 버그 수정 비용이 늘어난다는 점이다. 하지만 현실에서는 잘 지켜지지 않는다. 당장 눈앞에 구현해야 할 기능과 지난번에 만들어 둔 버그들이 쌓여 있기 때문이다. 시간이 항상 부족하기 때문에 본인이 작성한 코드를 대충 테스트하고 검증 부서에 넘겨 버리기 일쑤다. 악순환이다. 더 문제는 이게 반복되면 '기능 완료'의 정의가 기본기능만 돌아가지만 벌레가 스멀스멀 기어 다니는 상태로 받아들여진다는 것이다.

  많은 코드를 작성하고 버그는 있지만 기능은 완료시킨 것이 성과의 지표가 되는 문화도 이런 엉성한 SW가 만들어 지는 데에 한 몫 한다. 버그 트래킹 시스템에 올라와 있는 버그를 많이 수정한 사람이 일을 잘한다고 여기기도 한다. 물론 그 사람이 수정한 이슈가 다른 사람이 만든 버그를 잡았다면 훌륭한 일이다. 그런데 자기가 버그를 왕창 만들어 낸 장본인이라면? 그 사람은 일을 잘 하는 사람인가, 그렇지 않은 사람인가? 관리자는 지표로 나타나는 분석 내용을 좋아하기 마련이지만 버그 수정 개수만을 가지고 성과를 판단하는 오류는 범하지 말아야 한다.

  습관은 반복적인 행동으로 이루어진다. 나쁜 습관도 마찬가지다. 아직 나쁜 습관에 물들지 않았다면 좋은 습관을 가지도록 노력하자. 코드리뷰를 귀찮게 여기지 말고 개발과정의 필수과정으로 인정하는 문화가 정립돼야 한다. 테스트 코드의 커버리지가 70%밖에 되지 않는다면 나머지 30% 부분은 직접 실행해 보아야 할 것 이다. 당신이 관리자라면 기능 완료의 정의를 돌아가는 SW가 아니라 완성도 높은 SW로 받아들여야 한다. 

  테스트는 검증부서만의 몫이 아니다. 검증부서는 현재 SW의 상태를 "검증"한다는 것을 다시 한 번 명심하자.

1. https://en.wikipedia.org/wiki/Software_testing [본문으로]
2. 그린 코드 구현 전략 - 정적 프로그램 분석, http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33321 [본문으로]