1. 버그 수정하기
앞의 "소프트웨어 테스팅의 현실"로 돌아가 보자. 우리는 모든 노력을 기울여 테스트를 계획하고 실행한다 해도 찾아낸 모든 버그가 수정되지 않는다는 것을 배웠다. 어떤 버그는 완전히 사라질 것이다. 그리고 다른 몇몇은 소프트웨어가 다음에 출시될 때까지 수정 작업이 연기될 것이다. 이런 경우 매우 의기소침해지거나, 이러한 일이 가능하다는 사실에 놀라기까지 할지도 모른다. 하지만 이제 소프트웨어 테스트에 대해서 훨씬 더 많은 것을 알고 있는 독자들이므로 모든 버그를 수정할 수 없는 것이 현실인 이유에 대해 짐작하고 있길 바란다. 앞장에서 버그를 수정하지 않는 이유로 제시되었는 이유는 다음과 같다.

(1) 쫓기는 작업
일정 모든 프로젝트에서 마찬가지이지만, 소프트웨어 기능은 너무 많은 데 비해 그것을 코딩하고 테스트할 인력은 부족하고 마감까지 남은 시간 역시 부족하다. 만약 세금 준비 프로그램 작업을 하고 있다면 세금 징수 날짜는 변하지 않으므로 그 전까지 소프트웨어를 출시해야만 한다.

(2) 진짜 버그가 아닌 경우
"그건 버그가 아니라 기능이야!" 라는 말을 들어본 적이 있을 것이다. 기능에 대한 오해나 테스트 오류, 명세서 변경 등으로 인해 버그처럼 보이는 것이 기능으로 둔갑하는 경우가 종종 있다.

(3) 고치기 위험한 버그
불행하게도 소프트웨어는 깨지기 쉽고, 스파게티처럼 서로 꼬여 있는 경우가 너무나 많다. 버그 하나를 수정하면 다른 버그가 발생되는 경우도 있다. 빡빡한 일정에 맞춰 제품을 출시해야 한다는 압력 속에서 소프트웨어를 변경한다는 것은 너무 위험하다. 따라서 새로운 버그나 알려지지 않은 버그가 또 만들어지는 것을 피하기 위해 버그가 있다는 것을 알리는 데에서 그치는 경우가 많다.

(4) 고칠 가치가 없는 버그
잔인하게 들리겠지만 이것은 현실이다. 자주 나타나지 않는 버그나 잘 사용되지 않는 기능에서 나타나는 버그는 무시되는 경우가 많다. 사용자가 다른 방법을 사용하면 충분히 방지할 수 있는 버그는 종종 수정되지 않은 채 남겨진다. 위험도를 고려한 상업적 결정인 것이다.

이 목록에 한 가지 항목을 더 추가하겠다. 이 항목 때문에 버그가 수정되지 않는 일이 종종 있다.

(5) 비효과적으로 보고되는 버그
테스터가 특정 버그가 수정되어야 하는 이유에 대해 충분한 사례를 제공하는 않는 경우이다. 결과적으로 버그가 문제점이 아닌 것으로 오해되고 제품 출시를 연기할 만큼 중요하게 여겨지지 않는다. 또는 수정하기에 너무 위험한 것으로 인식되거나 수정할 가치가 없는 간단한 것으로 간주된다.

Chicken Little의 경우 하늘이 무너지고 있다고 소리를 지르며 뛰어 다니는 것은 일반적인 관점에서 문제점(물론 실제 하늘이 무너지고 잇었던 것도 아니며, 그녀의 주장이 명백해 보이지도 않았다)을 공유하는 효과적인 접근법이 아니다. 대부분 발견된 버그는 이렇게 극적인 것들이 아니다. 다라서 발견한 사항을 최대한 명백하고 간결하게 팀에 알려, 수정 여부를 판단할 팀 구성원들에게 수행할 작업을 결정하는 데 필요한 모든 정보를 제공해야 한다.

소프트웨어 개발 모델의 종류가 다양하고 팀이 처한 상황도 모두 다르기 때문에 팀또는 프로젝트에서 정확하게 어떤 방법으로 버그 수정 여부를 결정해야 할지 단정할 수는 없다. 많은 경우 프로젝트 매니저가 단독으로 이를 결정하거나, 프로그래머와 함께 결정하거나, 위원회에서 이를 결정한다.

하지만 일반적인 경우 테스터가 보고하는 버그를 검토하고 버그를 수정할 것인지 결정하는 담당자 또는 그룹이 존재한다. 이때 결정 과정에서 테스터가 버그를 설명하기 위해 제공하는 정보가 사용된다.

자신이 제출한 버그가 수정되어야 한다는 점에 대해 모든 사람을 설득하기 위해 변호사나 토론전문가가 될 필요는 없다. 일반적인 상식과 기본적인 커뮤니케이션 기술만 있으면 된다. 이 장의 나머지 부분에서는 버그를 기록하고 추적하는 다른 시스템에 대해 알아볼 것이다. 하지만 여기에서는 버그를 보고하는 데 지켜야 할 기본적인 원칙만을 알아보자.