버그 관리의 중요성 팀 단위로 개발을 할 경우 서로가 서로의 버그를 발견하는 경우가 있는데, 많은 경우 구두로 이러한 과정이 이루어진다. 간단하면서도 심각한 버그라면 발견시 바로 해결하기도 하지만, 많은 버그들이 뒤로 미루거나 다른일과 겹치거나 하면서 잊혀져 버진다. 그 결과 버그가 계속적으로 누적되고, 발생했던 버그가 또 다시 발생하고 이 버그가 해결했던 버그인지 아닌지도 헷갈리고 해결해야 되는건지 아닌건지도 헷갈리는 최악의 상황에 도달하게 된다. 때에 따라서는 소모적인 책임공방도 벌어지게 된다. 메일로 발견된 버그를 보고하면 그나마 좀 낳긴 하지만 임시방편일 뿐이라는 건 사용해본 사람은 안다. 결국 프로젝트는 이런저런 자잘한 버그들 때문에 문제가 계속되고 어찌어찌해서 급하게 출시를 하더라도 완성도가 떨어지는 제품을 고객에게 내놓게 된다. 버그 관리 버그를 관리하고 감시하기 위해서는 버그에 대해서 심각도와 우선순위등을 할당하게 된다. 그래서 아래의 용어에 대해서 명확히 이해를 하고 있어야 버그관리가 제대로 이루어질 수 있을 것이다. 버그 심각도 (Severity) Blocker :개발 혹은 테스트 작업을 진행할 수 없게 만듦 버그 처리 결과 버그에 어떤 일이 발생했는지 나타낸다. FIXED (해결됨) : 테스트가 완료되었으며 버그 트리에 해결되었다고 표시된다. INVALID (버그아님) : 기술된 문제는 버그가 아니었음. WONTFIX (해결불가) : 기술된 문제는 해결될 수 없는 버그이다. LATER (나중에) : 기술된 문제는 본 제품에서는 수정될 수 없다. 차후 제품에 수정이 가능할 수 있다. REMIND (기억할 것) : 기술된 문제는 본 제품의 현재 버전에서는 수정할 수 없는 버그이지만, 앞으로 계속 영향을 끼칠 것으로 예상된다. DUPLICATE (중복됨) : 기술된 문제는 기존의 버그와 중복되었다.(혹은 유사 버그가 이미 존재함) 버그를 중복되었다고 표시하기 위해서는 기존의 버그 번호를 필요로 한다. WORKSFORME (파악할 수 없음) : 버그를 재현해 보려고 많은 노력을 기울였지만 실패했으며, 생성된 코드를 분석해봐도 왜 보고된 문제가 발생했는지를 파악할 수 없는 상태이다. 이 문제를 해결하기 위해서는 추가적인 정보가 필요하고, 그럴경우 이 버그는 다시 할당될 수 있다. 혹은 문제를 파악할 수 있을 만한 다른 개발자에게 할당할 수 있을 것이다. [출처] Bug Tracking System에서 알아두어야 할 용어|작성자 지연아빠 Critical : 프로그램이 깨지거나, 데이터 손상 및 메무리 누수가 발생함 Major : 기능상 중요한 결정이 발견됨 Normal : 일반적인 문제로 반드시 고쳐야할 버그 Minor : 기능상 그리 중요하지 않은 결점 혹은 쉽게 해결할 수 있는 문제 Trivial : 오탈자, 텟스트 정렬 문제와 같은 외형적인 문제 Enhancement : 기능 및 성능 개선 관련 사항 버그 처리 우선순위 (Priority) 즉시 (P1) : Prevents work from getting done, causes data loss, or BFI("Bad First Impression") 가장 먼저 처리해야함 긴급 (P2) : Workaround required to get stuff done. 보통 (P3) : Like P2, but rarely encountered in normal usage. 낮음 (P4) : Developer concern only, API stability ro cleanliness issue. 없음 (P5) : Nice to fix, but in a pinch we could live with it. 가장 나중에 처리해도 됨 버그 상태 정보 UNCONFIRMED (승인되지 않음) : 최근에 테이터베이스에 등록된 버그로, 아무도 이 버그에 대해서 확인을 해보지 않았다. 즉 아직 버그인지 아닌지도 검증이 되지 않은 상태다. 등록된 버그를 Confirm할 수 있는 사용자는 이 버그를 승인할 수 있으며, NEW(새로운 버그)로 하거나 해결될 경우 RESOLVED등의 상태로 변경이 가능하다. NEW (신규 버그) : 이 버그는 최근에 버그를 할당받은 담당자에 의해서 버그로 인정되었으며, 이에 대한 처리가 이루어져야 한다. 이 상태의 버그는 수락(accept)될 수 있으며, 필요한 경우 다른 사람에게 전달될 수(ASSIGNED)있다. 만약 다음 단계로 더 이상 진행이 안된다면 계속 NEW상태로 남아 있을 것이고, 문제가 해결된다면 RESOLVED 상태로 전이될 수 있을 것이다. ASSIGNED ( 할당됨 ) : 이 버그는 아직 해결되지 않았지만, 버그를 처리할수 있는 적합한 사람에게 할당되어져 있음을 의미한다. REOPENED (다시 오픈됨) : 이전에 해결(CLOSED)되었던 버그라고 하더라도 다시 재현될 수 있고, 혹은 담당자가 봤을 때 버그처리가 명확하게 되어있지 않음을 인지할 수도 있을 것이다. 이 경우 REOPENED 상태가 될수 있을 것이다. 이 상태의 버그들은 ASSIGNED 혹은 RESOLVED 상태로 전이될 수 있다. RESOLVED (처리됨) : 처리가 되었으며, 품질보증(QA) 담당자의 검증을 기다린다. 이 상태의 버그들은 REOPENED, VERIFIED 상태로 혹은 CLOSED 상태로 전이될 수 있다. VERIFIED (검증됨) : QA 담당자가 버그와 처리결과를 보고 적절하게 처리가 완료되었는지를 검증하게 된다. CLOSED (닫힘) : 버그가 완전히 사라졌다고 간주되는 상태다. 그러나 불행히도 다시 살아나는 경우가 발생할 수 있는데, 이때는 REOPENED 상태가 되어야 한다. http://blog.naver.com/eddykim72?Redirect=Log&logNo=40040460022
by Anna 안나 2008. 7. 6. 17:25