현재 일하고 있는 회사에서는 버그 관리 시스템으로
Bugzilla를 사용하고 있다. 개발팀에서 빌드가 이루어진 제품을 QA팀이 가져가서 테스트를 하게 되고, 테스트 중에 발견된 버그들이 이
Bugzilla에 등록되게 된다. 그리고 개발자들은 등록된 버그를 해결하고 다시 그것을 QA팀에 통보를 한다. 이런 과정들을 반복하면서 버그가 줄어들고 또 제품의 Quality가 높아지게 되는 것이다.
나는 지금까지 3개의 버그 관리 시스템을 사용했다. 처음 써 본것은 Microsoft의 RAID이다. 이 제품은 상용 제품은 아니고, Microsoft에서 내부적으로 사용하는 것인데, Microsoft 컨설턴트 분들과 프로젝트를 진행할 때에 이것을 2번 정도 사용을 했었다. 그리고 얼마전까지 속했던 프로젝트에서는
Microsoft Visual Studio 2005 Team System에 포함되어 있는 버그 관리 시스템을 사용을 했다. 그리고 지금은
Bugzilla까지..
이 3개의 시스템은 사실 아주 비슷한 구조를 가지고 있다. 버그를 등록하고 상태를 변경하고(상태에는 Open, Resolved, Fixed, Re-open 등등이 있고) 그리고 메일 등으로 alert을 제공하고 등등.. 그래서 사실 어떤 버그 관리 시스템을 쓰더라도 특별한 차이가 있는 것은 아니다.
중요한 것은 어떻게 쓰느냐이다. 버그 관리 시스템을 그냥 버그 리스트로만 봐서는 안 된다고 생각한다. 버그 관리 시스템은 버그의 관리 뿐 아니라. 버그와 그에 연관된 많은 정보들이 모두 모아져야 한다. 그러기 위해서 내가 생각하는 몇 가지 원칙을 좀 제안해 보고자 한다.
1. 자신의 코드에서 버그를 찾아서 수정했을 때에도, 버그로 기록하자.버그의 갯수는 물론 개발자를 평가하는 기준이 될 수도 있다. 그래서 대부분 테스트 팀에 넘어가기 전에 자기가 발견하고 수정해 버린 버그에 대해서 버그 관리 시스템에 등록을 하지 않는 경우가 대부분이다. 하지만 나는 그것들도 기록해두는 것이 좋다고 생각한다. 어떤 버그 혹은 이슈는 두고두고 개발자를 괴롭히는 경우가 많다. 그럴 때에 대부분 "그게 뭐였지.." 하면서 기억을 뒤지게 되는데, 버그 관리 시스템에 등록되어 있다면 더 쉽게 찾을 수가 있다.
그리고 하나의 버그를 찾아서 그것을 기록하고 정리하는 과정에서, 그 버그에 대해서 완전하게 이해할 수가 있다. 그러면 자신의 코딩 습관에서 버그를 유발시키는 코드에 대해서 더 잘 이해할 수 있을 것이고 그럼으로써 더 좋은 코드를 작성할 수 있게 될 것이다. 그리고 처음에 말했던, 자신의 버그 숫자가 늘어나는 문제 때문에 등록을 망설인다면, 더 좋은 코드를 작성할 수 있기 때문에 가면 갈수록 버그 숫자는 줄어들게 될 것이다.
2. 버그를 기록할 때는, 재현에 필요한 모든 정보를 남겨야 한다.이것은 사실 개발자보다는 테스트, 매니저 등에게 사실 하고 싶은 말이다. 우리는 버그 관리 시스템에서 자주 이런 아주 간단한 버그의 내용을 보게 된다. "OOO 기능 작동하지 않음", ""XXX 기능 에러 남" 등등.. 그런데 개발자들에겐 이런 정도의 말은 사실 이해하기에 너무나 부족한 말이다. 틀림없이 테스트해서 내보낸 것인데, 어떤 상황에서 에러가 나는 것인지, 무슨 짓을 하다가 발생한 에러인지 확실히 알 수가 있어야 한다. 이런 식으로 커뮤니케이션하다가 서로간에 사이가 안 좋아지기도 한다..^^;;
버그를 해결하는 과정의 첫 걸음은 바로 "재현(Reproduction)"이다. 즉 다른 사람이 발견한 버그를 개발자가 재현해보고, 그것을 해결할 실마리를 얻을 수가 있는 것이다. 그런데 이 재현을 하기 위해서는 상세한 정보가 필요하다. 버그가 발견된 머신의 소프트웨어 상황이라던지(어떤 브라우저, 어떤 OS 등등) 어떤 오퍼레이션을 어떻게했는지 등의 상세한 정보가 있어야 바로 그 버그를 재현할 수가 있다. 이런 정보가 없이는 버그를 재현하기가 힘들다. (아예 잘 되지 않는 경우도 있다. 실제로 소프트웨어 사용 습관이 사람마다 매우 다른데, 그래서 개발자는 자신의 사용습관만을 테스트해서 버그를 찾지 못했지만, 테스터는 사용 습관에 따라서 버그를 찾을 수도 있기 때문이다. 이 경우, 개발자는 이런 사용습관에 대한 정보가 없이는 버그를 재현해내기가 매우 힘들다)
재현에 필요한 모든 정보를 남겨야, 개발자가 재현하는 데 드는 시간도 줄어들 수 있고, 개발자와 테스터 간의 커뮤니케이션(혹은 말다툼) 시간도 줄일 수가 있고 결과적으로 많은 시간을 절약할 수가 있다. 그 시간에 버그를 더 수정할 수도 있을 것이고, 전체적인 퀄리티를 더 높일 수도 있으며 혹은 뭔가 다른 일을 하면서 개인적인 성취를 이루거나, 사회에 공헌을 할 수도 있을 것이다. ^^;;
3. 개발자는 버그에 대해서 되도록 자세한 정보를 Comment로 남기는 것이 좋다.개발자들도 버그를 수정한 다음에 Comment를 자세하게 남겨야 한다. "버그 맞습니다. 고치겠습니다", "버그 수정되었습니다", "버그 아닙니다" 이 정도의 커멘트로는 역시 대화가 되지도 않고, 이후에도 아무런 도움이 되지 않는다.
재현이 안 되었다면 자신이 재현을 한 과정과 환경을 써야 하고, 재현이 되었고 실마리를 찾았다면 그 실마리를 적어야 한다. 수정을 했다면 어떤 모듈을 어떤 식으로 고쳤는지 기록해야 한다. 물론 이것이 개발자만 보는 시스템이 아니기 때문에, 자세한 기술적 내용을 쓸 필요가 없기도 하고 그렇게 쓰지 말라는 말을 들을 지도 모르겠다. 하지만 그런 부분은 그 사람들이 가려서 읽으면 된다.
기술적인 내용 등을 자세하게 쓴다면, 개발자는 이 버그 관리 시스템을 일종의 KnowledgeBase로 활용할 수가 있다. 그리고 개인적으로뿐만 아니라, 전체적으로도 이런 자세한 내용은 분명히 도움이 될 것이다. 비슷한 증상이나 버그 혹은 기술적인 문제 때문에 다른 개발자가 지금 고생하고 있을 수도 있다. 그런 사람들에게 장황하게 설명하기보다는 Bug No XXX를 참조하세요라고 말할 수가 있다.. 훨씬 편리한 것이다.
4. 버그로 인해서 소스 코드가 수정되었다면, 그 수정된 부분에 등록된 버그ID등을 주석으로 남겨서 연결고리가 될 수 있도록 해야 한다.버그를 해결하기 위해서 소스 코드를 수정하게 될 것이다. 아마 대부분 수정하면서 그 내용을 주석으로 남길 것인데, 거기에 버그 번호를 붙이는 것이 좋다. 나중에 "이 버그는 어떻게 해결하셨어요?" 라고 누군가 물어볼 때, "아..기억이 안나..ㅜ.ㅜ" 보다는, 에디터를 열고 버그 번호로 찾으면 쉽게 찾아서 잘난 체 할 수가 있다.
Visual Studio Team System처럼 소스 제어와 버그를 링크할 수 있다면, 더 쉽게 찾을 수가 있다. 이런 기능은 적극적으로 활용해야 한다. 물론 귀찮다. 나도 VS2005 Team System 사용했을 때 이 기능은 전혀 사용하지 않았다. 하지만 나중에는 좀 후회를 했다. 나중에 버그나 Work Item과 관련된 소스 혹은 코드 일부를 찾는 일은 정말 힘들다. 코딩한지 3달 이상된 코드에 대해서는 거의 못 찾는다고 해도 과언이 아니다. 미리미리 준비를 해두는 것이 좋다.
이상, 버그 관리 시스템을 잘 쓰기 위한 생각들을 좀 정리를 해 보았다. 처음에는 귀찮고 개발할 시간을 뺐는 것처럼 보여도 결국에는 도움이 되는 것이 바로 버그 관리 시스템이라는 생각이 든다. 기왕 쓰는 것이라면 최선의 활용방법을 찾는 것이 더 좋을 것이다.
* 더 좋은 아이디어나 노하우가 있다면 댓글이나 트랙백으로 한 마디씩 해주셨으면 합니다..
invalid-file
