Bug Tracking과 Issue Tracking의 차이에 대해서 의견을 밝혀봅니다.
이 글은 Common Sense님의 글에 트랙백하기 위해서 작성합니다.
질문: Bug Tracking과 Issue Tracking의 차이는? 결론: Bug와 Issue가 가지는 단어의 의미차이 입니다.
여러 책이나 문서에서 “결함(Bug)이라는 단어보다는 논쟁/논의(Issue)라는 단어를 선호하기도 합니다.“라고 완곡하게 표현합니다.
Bug Tracking이나 Issue Tracking이나 모두 “일을 잘 하자고"하는 시스템입니다만, 그 잘 하자는 일에 접근하는 본질적인 시각의 차이는 있습니다.
단순하게 말해서, 요청자(주로 고객이거나 사용자)가 요청하는 모든사항(요청사항 = Ticket으로 발행되는것)이 결함(Bug)는 아닐 것입니다. 물론 결함이 주로겠지만, 기능개선도 있을것이고, 기능개악(^^;)도 있을것이고, 무엇인지 정의하기 어려운 부분도 있을 것입니다.
조금 말꼬리 잡는것 같습니다만, 발생하는 일 기준으로 Issue Tracking이 좀더 넓은 광의의 것을 다룬다면, Bug Tracking은 Issue중에서 Bug로 판명난 것만 다룬다는 것이 [단어상으로는 맞습니다.] :)
다만 단어에 따라서 처리하는 프로세스와 집계하는 방법, 등록되는 속성의 종류 등이 솔루션의 종류에 따라 달라지게 된다고 보시면 좋을 듯 합니다. (물론 버그질라등에서 관리가 되기는 합니다만.) 해결된 이슈 혹은 버그가 어느 릴리즈에서 반영되는지에 대한 [Product Dashboard] 혹은 [Release Dashboard]류는 Bug Tracking 만으로는 추적, 보고 하기가 조금 어렵습니다. (주로 다른 솔루션과 연동을 해야하지요)
실루엣팀의 경우에는 CodeInside2(동영상) 라고하는 협업솔루션을 만들어서 Issue + Bug + Task + All = WorkItem 으로 다루어 처리하고 있습니다.
추가적으로 BTS (저는 개인적으로 이 약어를 좋아하지는 않습니다. Bug Tracking System으로 전체를 기술하는 것을 좋아하지요)를 어떠한 솔루션을 사용하면 “현재 조직의 문제가 해결되는가?“보다는, “어떤 솔루션 (심지어 Excel File)을 사용 하더라고 조직이 체계적으로 관리 하고자 하는 의지만 있다면 상태를 관리하는 것은 가능하다. 솔루션은 조직원들이 가장 사용하기 간편한 것이 좋은것이다.“라고 말하고 싶습니다. :)
어떻게 좀더 도움이 되셨는지요? :)