효과적인 버그 추적을 위한 10계명

 1.유능한 테스트 담당자는 항상 버그 재현 과정을 최소한의범위로 축소하기 위해 노력한다. 이런 노력은 프로그래머가 버그의 원인을 찾아내는 데 크게 도움이 된다.

 2.처음 버그를 등록한 사람만이 그 버그를 종결할 수 있다는 점을 명심하라. 누구든 버그를 수정할 수는 있지만, 처음 버그를 발견한 사람만이 그 버그가 완벽하게 고쳐졌는지도 확인할 수 있다.

 3.버그를 해결하는 방법에는 여러 가지가 있다. FogBUGZ 데이터베이스를 이용하면, 수정완료, 수정불가, 연기, 재현불가, 중복버그, 설계상의오류 등으로 버그를 처리할 수 있다.

 4.‘재현 불가’라 함은 어느 누구도 그 버그를 다시 재현해낼 수 없는 경우를 말한다. 버그 보고서에 버그 재현 과정이 누락되어 있는 경우, 프로그래머들은 종종 재현 불가 판정을 이용한다.

 5.버전 관리에 유의하라. 테스트 담당자에게 제출하는 소프트웨어에는 항상 빌드(build) ID를 명시해야 한다. 그렇지 않으면, 가엾은 테스트 담당자가 디버깅도 되지 않은 소프트웨어 버전을 가지고 버그 수정 여부를 테스트하는 상황이 벌어질 수도 있다.

 6.테스트 담당자들이 버그 추적 데이터베이스를 사용하려 들지 않아서 애를 먹고 있는 프로그래머들이 있다면, 버그 데이터베이스 이외의방법으로는아예버그보고서를접수하지도마라. 혹시 테스트 담당자가 이메일로 버그 보고서를 보내오거들랑, “이 내용을 버그 데이터베이스에 입력해 주세요. 이메일은 추적관리가 불가능하답니다.” 라는 짤막한 메시지와 함께 버그 보고서를 되돌려보내라.

 7.반대로, 프로그래머들이 버그 추적 데이터베이스를 사용하려 들지 않아서 애를 먹고 있는 테스트 담당자들이 있다면, 그냥 아무말도하지마라. 버그 정보를 버그 데이터베이스에 입력하면, 데이터베이스가 알아서 프로그래머에게 이메일을 보내줄 테니까.

 8.동료 프로그래머들이 버그 추적 데이터베이스를 사용하려 들지 않는다면, 버그 수정 업무를 할당할 때 꼬박꼬박 버그 추적 데이터베이스를 이용하라. 결국은 동료들도 그 뜻을 이해하게 될 것이다.

 9.거금을 들여 설치한 버그 추적 데이터베이스를 아무도 사용하지 않아서 고민하는 관리자가 있다면, 프로그래머들한테 새로 개발할 기능을 할당할 때도 버그를 이용해 보라. 버그 추적 데이터베이스는 “구현 예정 기능” 데이터베이스로서도 손색이 없다.

 10.버그 추적 데이터베이스에 새로운 필드를 추가하고픈 유혹을 이겨내라. 아마 매달 누군가는 데이터베이스에 추가할 새 필드에 대한 그럴듯한 아이디어를 내놓을 것이다. 솔깃한 아이디어는 얼마든지 있을 수 있다. 이를테면, 버그가 발견된 파일을 추적할 필드를 만든다거나, 버그 재현 가능 비율을 퍼센티지로 추적할 필드를 추가한다거나, 버그 발생 횟수를 기록할 필드를 만든다거나, 버그가 발생한 시스템에 설치된 DLL의 버전을 기록할 필드를 추가한다거나, 기타 등등. 이런 아이디어에 현혹되어서는 안 된다. 이런 제안에 넘어가다 보면, 버그 추적 데이터베이스는 결국 수천 개의 데이터 필드로 가득차게 될 것이고 아무도 그 데이터베이스에 버그 보고서를 입력하려 들지 않을 것이다. 버그 추적 데이터베이스가 실효성을 거두려면 모든 사람들이 그것을 사용해야 한다. 그런데, “공식적으로” 버그를 입력하는 일이 너무 번거로운 작업이 된다면 아무도 버그 추적 데이터베이스를 이용하려 들지 않을 것이다.
 
출처 : http://korean.joelonsoftware.com/Articles/PainlessBugTracking.html