효과적인 버그 처리 방법
2008/12/09 13:31 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
RSS Feed
HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다.
의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다.
개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다.
주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다.
여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠.
개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기술을 잘 아는 관리자가 있기도 하고 기술을 잘 모르는 관리자가 있기도 합니다. 하루에 버그가 하나도 보고되지 않을 수도 있고, 하루에 수백개의 버그가 보고되는 경우도 있습니다.
이러한 모든 경우에도 버그는 가장 적절한 개발자에게 신속히 할당이 되어서 신속히 해결을 해야 합니다. 해결이라함은 꼭 버그를 Fix하는 것을 의미하는 것이 아니고 연기할 수도 있고, 수정하지 않기로 할 수도 있고, 버그가 아닌 경우도 있죠. 어쨌든 이런 요구를 항상 만족시키기란 쉽지 않죠.
그래서 사람들이 찾아낸 방법이 "자율"입니다. 완전한 자율은 아니고 "Process"와 적당히 혼합된 "자율"입니다. 소프트웨어 개발에 있어서 "자율"은 매우 자주 등장하니 그리 놀랄 일도 아닙니다.
버그할당의 의무와 역할을 관리자에게만 두는 것이 아니고, 개발자도 그 역할을 조금씩 나눠 갖는 겁니다.
버그가 보고되면 관리자나 관련 개발자나 누구나 먼저 인지를 한 사람이 버그를 할당하는 겁니다. 여기서 버그를 할당했다고 해서 당장 버그를 고친다는 의미는 아닙니다.(이는 버그 관리 정책에 따라서 다릅니다.)
모든 개발자가 모든 버그를 다 감시할 수는 없겠죠. 버그의 카테고리는 기능별, 모듈별로 모두 등록을 해 놓아서 카테고리와 담당개발자의 연관성을 높이고 개발자들은 자신과 주로 관련된 카테고리들만 감시를 해도 충분합니다. RSS Feed를 지원하는 Bug Tracking System이 있으면 이렇게 감시를 하기 편리합니다. 그리고 나면 버그 해결 스케쥴은 시스템을 이용하여 정할 수도 있고, 회의를 하기도 합니다.
버그할당의 최종 책임은 관리자에게 있으므로 이렇게도 할당이 안된 버그는 관리자가 처리를 해야죠.
이러한 방법은 대부분의 경우에 상당히 효율적입니다만, 자율에 의한다는 것은 각 구성원의 성숙도에 많은 영향을 받으므로 이를 감안해서 시행해야 할 것입니다.
버그의 처리에는 시간이 걸릴 수 있어도 버그의 인지는 신속해야 하고, 버그의 할당도 빠르게 이루어져야 합니다. 버그인지 자체가 일주일 이상 걸리는 상황이라면 그 기간 동안 버그는 완전히 방치가 되고 있는 상황이라고 할 수 있습니다. 그래서 회사에 따라서는 버그 인치와 처리 시간을 줄이기 위해서 KPI에 이 수치를 포함해서 평가의 지표로 삼곤 하는데, 별로 바람직한 시도는 아닙니다. 어차피 자율에 의한 방법이기 때문에 좀더 성숙한 개발 문화와 이를 북돋울 약간의 당근만이 필요할 뿐입니다.
이미지출처 : Microsoft Office Online
'기반시스템 > 버그관리' 카테고리의 다른 글
| 이슈관리시스템을 쓰면서 일이 더 많아졌다. (10) | 2011/07/20 |
|---|---|
| 버그관리시스템 사용 현황 조사 결과 (2) | 2009/04/12 |
| 효과적인 버그 처리 방법 (6) | 2008/12/09 |
Trackback Address: http://allofsoftware.net/trackback/33
자율에 의해 버그가 잘 처리 되고 개발자가 자기 모듈에서 버그가 발생된다면 해당 개발자가 맡아 주는 것이 좋겠죠? 그러나 버그 리포트만 보고 어느 모듈에서 버그가 있는지 알기 어려울때가 있고 또 이전 모듈을 담당한 개발자가 더이상 일하지 않을수도 있고, 우리의 관리자가 개발자의 이름을 다 기억 못할수도 있고 등등등. 이럴때 이전 버그 할당한 히스코리나 버그의 증상을 바탕으로 버그 트래킹 시스템이 자동으로 이 버그를 픽스할만한 후보를 3명 정도 찝어 준다면 어떨까요? 물론 이 3명을 정확하게 찝어줘야 겠지만.
HannaKim님 안녕하세요.
자동으로 후보를 찍어주는 시스템이 효과를 발휘하면 대형 프로젝트에서는 정말 멋진 시스템이 될 것 같은데요. 혹시 그런 시스템을 만드신다면 기대하고 싶네요.
테스트팀이 개발 설계때 부터 투입되고 개발과 테스트관련 작업?이 같이 진행되면 Bug를 발견한 테스터가 직접 개발자를 Assign해도 좋다고 생각합니다. 물론 그 만큼 개발과 테스트가 유기적으로 진행되고 있어야하겠지요. 개발자와 1:1로 개발, 테스트를 진행했었는데 이게 가장 효율적이었습니다.
즉, 현재 조직 상황과 프로세스에 따라 다르게 적용되어야 한다고 생각합니다. 프로세스 성숙도와 규모에 따라 적용하는 것이 달라지겠지요.
Clear Quest를 사용하면서 큰 틀은 함께하면서 팀마다 다른 스키마를 적용했었습니다.
정의의소님 안녕하세요.
각 개발자가 컴포넌트를 완전히 구분해서 개발을 하신 경우겠네요.
테스트팀은 말씀하신 대로 개발 초기부터 투입이 되어야 합니다. V-Model만 보더라도 테스트팀이 요구사항단계부터 투입이 됩니다.
소프트웨어 개발은 원리를 이해하는 것이 정말 중요하다고 생각합니다.
관리자 및 개발자의 성숙한 소프트웨어 개발 프로세스 문화 뿐 아니라 QA팀에서의 Report도 많은 비중을 차지할 것 같습니다.
일단 버그의 담당자를 지정하기 위한 자료는 Issue Report 가 전부이기 때문이죠.
그리고 Stracking System을 Product별로 커스터마이징 해서 킥 오프 단계에서 각 개발 컴포넌트와 그 담당자를 매칭해 주고 자동 Assign 하면서 이 관계를 지속적으로 업데이트하는 방법도 효율적일 것 같습니다.
(가능한 Tracking System 및 양질의 Issue Report, 모든 부서의 원활한 커뮤니케이션이 선행되어야 하는... 어려운(...?!?!?!) 점이 있겠지만요.)
Noel님 안녕하세요.
상당히 Detail하게 적어주셨네요. 말씀하신 모든 부분이 이슈 할당 및 처리에 도움을 주는 방법들이죠.
버그 리포트 주체를 QA팀이 아닌 "누구나"로 확장하면 또 고려해야 할 것들이 있겠죠.
워낙 다양한 경우가 있어서 원리만 잘 이해하고 있으면 응용력이 생기죠.
이런 좋은 경험들이 다양한 경우에 응용력을 키워 줍니다.