2009년부터 4년 넘게 이 공간에 쓸데 없이 주절 주절 소프트웨어 테스팅과 관련이 있다고 생각하는 글을 137편을 끄적거렸습니다. 매달 2편 정도의 글을 썼습니다. 그다지 많이 쓰지도 않았는데.. 이제는 예전에 제가 무슨 글을 썼는지 잘 기억이 안납니다. 이 블로그 서비스는 구글이 제공하는 서비스임에도 불구하고 검색 기능은 아주... 엉망인지라... 지금 쓰고자 하는 이 글도 예전 언젠가 썼었던 기억이 있는데.. 아무리 찾아보아도 아니보여서 다시 써봅니다. 이번에 제가 얘기하고 싶은 주제는 메트릭입니다. 우리는 소프트웨어를 개발하고 테스트를 진행하면서 제품의 품질과 테스트의 진척을 판단하기 위해 꽤 많은 메트릭을 사용하고 있습니다. 결함 갯수, 수정된 결함 수, 잔존 결함 수, 결함 수정 기간, 작성된 테스트 케이스 수, 품질 지표, 실행된 테스트 케이스 수, 실패한 테스트 케이스 수 등등등... 정말로 많은 메트릭 종류가 있습니다. 그리고 이러한 메트릭을 기반으로 사람을 평가하고 제품을 평가합니다. 많은 조직에서는 좀 더 의미있는 메트릭을 수집하고자 매우 많은 노력을 하고 있습니다. 그래서.. 그 많은 메트릭을 수집하셔서 품질이 좀 나아지셨습니까? 테스터의 역량이 향상되셨습니까? 개발자로부터 유입되는 결함은 좀 줄어드셨나요? 물론, 괄목할만한 성과를 얻는 조직도 있습니다. 하지만 많은 조직은 분명 열심히 하고 있다고 생각하는데 성과는 높지 않습니다. 그리고 더 나은 메트릭을 찾아서 킬리만자로의 표범처럼 헤메이고 있습니다. 자.. 더 나은 메트릭을 찾아 헤메기 전에 왜 나아지지 않는 것일까요? 수집하는 메트릭이 좋지 않아서일까요? 잘못된 메트릭을 수집하고 있어서 그런걸까요? 결론적으로는 메트릭을 수집하기 때문에 그렇다고 볼 수 있습니다. 어쩌면 메트릭을 수집하지 않음으로 인해 더 나은 경험을 해보실 수도 있습니다. 이 무슨 해괴한 이야기인가 싶으신가요? 관리자는 숫자에 대한 맹신과