반응형

bugzilla에 대해서

bugzilla는 [http]mozilla.org에서 개발하고 제공하는 버그 추적(bug-tracking)시스템이다. 버그 트래킹 시스템은 개인이나 그룹이 어떤 프로제트를 진행함에 있어서 어느 부분에서 언제 버그가 발생했는지, 버그가 얼마나 치명적인지, 어떤 우선순위로 해결해야 하는지, 해결되었다면 누구에 의해서 언제 어떻게 해결되었는지를 DB에 남김으로써 발생된 버그에 대해서 체계적으로 관리 할 수 있도록 도와 준다.

bugzilla를 이용한 버그 관리

버그관리의 중요성

특히 팀단위로 개발을 할 경우 서로가 서로의 버그를 발견하는 경우가 있는데, 많은 경우 구두로 이러한 과정이 이루어진다. 간단하면서도 심각한 버그라면 발견시 바로 해결하기도 하지만, 많은 버그들이 뒤로 미루거나 다른일과 겹치거나 하면서 잊혀져 버린다. 그결과 버그가 계속적으로 누적되고, 발생했던 버그가 또다시 발생하고 이 버그가 해결했던 버그인지 아닌지도 헷갈리고 해결해야 되는건지 아닌건지도 헷갈리는 최악의 상황에 도달하게 된다. 때에 따라서는 소모적인 책임공방도 벌어지게 된다.

메일로 발견된 버그를 보고하면 그나마 좀 낳긴 하지만 임시방편일 뿐이라는건 사용해본 사람은 안다.

결국 프로젝트는 이런저런 자잘한 버그들 때문에 문제가 계속되고 어찌어찌해서 급하게 출시를 하더라도 완성도가 떨어지는 제품을 고객에게 내놓게 된다.

이런 문제를 해결하기 위해서 전문제품을 구입하거나, 팀이나 회사차원에서 나름대로 고심해서 시스템을 구축하기도 하는데, 솔직히 왠만한 규모의 개념있는 회사가 아닌다음에야 이런건 신경도 쓰지 않는다. 다행히도 공개되었으면서도 사용하기 편하고 강력한 버그트래킹 시스템이 있으니 바로 bugzilla다.

bugzilla의 설치

bugzilla는 영어권에서 개발된 프로그램이라서 모든 메시지가 영어로 되어있다. 그러나 한글화된 버젼이 있으니 이걸 받아서 설치하면 된다. [http]bugzilla 한국어 프로젝트를 방문해서 최신버젼을 다운받도록 한다. 여기에서는 2.16.3 한글 버젼을 기준으로 설치하도록 하겠다.

다음은 bugzilla설치를 위한 기본 환경이다.
  1. bugzilla는 웹기반 프로그램으로 Apache(12)나 IIS서버가 설치되어 있어야 한다.
  2. Perl(12) CGI(12)프로그램이다. 반드시 Perl이 설치되어 있어야 한다.
  3. 버그관련 정보를 DB에 저장하기 위해서 Mysql을 이용한다.

웹서버설치와 Mysql(12)설치는 여기에서 다루지 않을 것이다. 이와 관련되어서는 다른 사이트들을 참고하기 바란다.

Perl 모듈 설치
bugzilla는 상당히 방대한 시스템이며, 대부분이 perl로 이루어져 있기 때문에 perl 내부적으로 많은 모듈을 사용한다. 이런 이유로 제대로 bugzilla를 설치하기 위해서는 다음과 같은 모듈이 필수 적으로 설치되어 있어야 한다. 물론 Perl은 당연히 설치되어 있어야 하며 5.6.1 이상을 권장한다. 대부분 5.8이상이 설치되어 있으니 perl이 문제되는 경우는 없을 것이다.
  1. Template(2.07)
  2. AppConfig(1.52)
  3. Text::Wrap(2001.0131)
  4. Data::Dumper
  5. DBD::mysql(1.2209)
  6. DBI(1.13)
  7. Date::Parse
  8. CGI::Carp
다음은 반드시 필요하진 않지만 부가적인 기능을 위한 옵션 모듈들이다.
  1. GD(1.10) 버그 차트기능
  2. Chart::Base(0.99c) 버그 차트기능
  3. XML::Parser Xml
  4. MIME::Parser email기능

위의 모든 모듈들은 [http]CPAN에서 구할 수 있다. 모듈을 일일이 다운받아서 컴파일하고 설치해도 되겠지만 다음과 같이 자동으로 설치할 수도 있으니 활용해보기 바란다.(필자는 그냥 일일이 받아서 설치했다) 
# perl -MCPAN -e 'install "Bundle::Bugzilla"'
위의 방법을 이용하더라도 GD, Chart::Base, MIME:Parser은설치가 되지 않는다.

bugzilla 설치
bugzilla를 다운받아서 웹서버의 cgi(12)디렉토리에 압축을 풀도록 한다.

그다음 checksetup.pl을 실행해서 bugzilla의 환경을 설정한다. mysql계정등의 정보를 설정하게 되는데, 간단하게 설정을 마칠 수 있을 것이다. 
# ./checksetup.pl

이제 버그질라 페이지에 접근하도록 한다. 만약 에러메시지를 출력한다면 서버에서 직접 ./index.cgi를 실행시켜서 제대로 작동이 되는지 확인해보자. 문제없이 작동하는데도 에러가 떨어진다면 파일권한 문제인 경우가 대부분이다. cgi파일들이 실행권한으로 되어 있는지, 각 디렉토리가 nobody권한으로 읽을 수 있도록 되어있는지 확인해 보자.

bugzilla를 설치하기 전에 간단하게 테스트해보고 싶다면 [http]joinc bugzilla에서 테스트해보기 바란다.

bugzilla 상태 정보

버그를 관리하고 감시하기 위해서 버그질라는 발생된 버그에 대해서 심각도와 우선순위등을 할당하게 된다. 다음은 이들 버그의 상태정보에 대한 정보들이다. 아래의 용어들에 대해서 명확히 이해를 하고 있어야 버그관리가 제대로 이루어질 수 있을 것이다.
버그 심각도 (serverity)
  • Blocker : 개발 혹은 테스트 작업을 진행할 수 없게 만듦
  • Critical : 프로그램이 깨지거나, 데이터 손상및 메모리 누수가 발생함
  • Major : 기능상의 중요한 결점이 발견됨
  • Normal : 일반적인 문제로 반드시 고쳐야할 버그
  • Minor : 기능상 그리 중요하지 않은 결점, 혹은 쉽게 해결할 수 있는 문제
  • Trivial : 오탈자, 텍스트 정렬문제와 같은 외형적 문제
  • Enhancement : 기능 및 성능개선 관련 사항

버그 처리 우선순위 (Priority)
수정해야할 버그들의 중요도와 순서를 기술한다. 프로그래머 혹은 엔지니어가 자신들이 해야할 일에 대한 우선순위를 결정할 수 있도록 정보를 제공한다.
버그 상태정보(Status) 
  +-----------+       +-------------+        +------+       +-------------+
  | 버그 발생 | ----> | UNCONFIRMED | -----> | NEW  | ----> | ASSIGNED    | 
  +-----------+       +-------------+        +------+       +-------------+
                            |                   |                | | |
                            |                   |                | | |
        +-------------+     |                   |                | | |
        | RESOLVED    | <---+                   |                | | |
        |             | <-----------------------+                | | |
   +----|             | <----------------------------------------+ | |
   |    |             | <---------------------------------+        | |
   |    |             | <---+                             |        | |
   |    +-------------+     |                             |        | |
   |                        |                             |        | |
   |    +-------------+     |                             |        | |
   +--->| VERIFIED    | ----+                             |        | |
   +----|             | ----------------->>---------------|--------+ |
   |    +-------------+                                   |          |
   |                                                      |          |
   |                                                      |          |
   |    +-------------+             +----------+          |          |
   +--->| CLOSE       | ----------> | REOPENED | ---------+          |
        |             |             |          | ------------>>------+  
        +-------------+             +----------+
버그의 상태를 나타낸다.
  • UNCONFIRMED(승인되지 않음)
    최근에 데이터베이스에 등록된 버그로, 아무도 이 버그에 대해서 확인을 해보지 않았다. 즉 아직 버그인지 아닌지도 검증이 되지 않은 상태다. 등록된버그를 Confirm할수 있는 사용자는 이 버그를 승인할 수 있으며, New(새로운버그)로 하거나 해결될 경우 (RESOVED)등의 상태로 변경이 가능하다.
  • NEW(신규버그)
    이 버그는 최근에 버그를 할당받은 담당자에 의해서 버그로 인정되었으며, 이에 대한 처리가 이루어져야 한다. 이 상태의 버그는 수락(accept)될 수 있으며, 필요한 경우 다른 사람에게 전달될 수(ASSIGNED) 있다. 만약 다음 단계로 더 이상 진행이 안된다면 계속 NEW상태로 남아 있을 것이고, 문제가 해결된다면 RESOLVED 상태로 전이될 수도 있을 것이다.
  • ASSIGNED(할당됨)
    이 버그는 아직 해결되지 않았지만, 버그를 처리할 수 있는 적합한 사람에게 할당되어져 있음을 의미한다.
  • REOPENED(다시 오픈됨)
    이전에 해결(CLOSED)되었던 버그라고 하더라도 다시 재현될 수 있고, 혹은 담당자가 봤을때 버그처리가 명확하게 되어있지 않음을 인지할 수도 있을 것이다. 이경우 REOPENED 상태가 될수 있을 것이다. 이상태의 버그들은 ASSIGNED 혹은 RESOLVED 상태로 전이될 수 있다.
  • RESOLVED(처리됨)
    처리가 되었으며, QA(품질보증)담당자의 검증을 기다린다. 이 상태의 버그들은 REOPEND, VERIFIED 상태로 혹은 CLOSED 상태로 전이될 수 있다.
  • VERIFIED(검증)
    QA담당자가 버그와 처리결과를 보고 적절하게 처리가 완료되었는지를 검증하게 된다.
  • CLOSED(닫힘)
    버그가 완전히 사라졌다고 간주되는 상태다. 그러나 불행히도 다시 살아나는 경우가 발생할 수 있는데, 이때는 REOPENED 상태가되어야 한다.

버그 처리결과
버그에 어떤 일이 발생했는지를 나타낸다.
  • FIXED(해결됨)
    테스트가 완료되었으며 버그트리에 해결되었다고 표시된다.
  • INVALID(버그아님)
    기술된 문제는 버그가 아니였음
  • WONTFIX(해결불가)
    기술된 문제는 해결될 수 없는 버그이다.
  • LATER(나중에)
    기술된 문제는 본 제품에서는 수정될 수 없다. 차후 제품에 수정이 가능할 수 있다.
  • REMIND(기억할 것)
    기술된 문제는 본 제품의 현재 버젼에서는 수정할 수 없는 버그이지만, 앞으로 계속 영향을 끼칠 것으로 예상된다.
  • DUPLICATE(중복됨)
    기술된 문제는 기존의 버그와 중복되었다(혹은 유사한 버그가 이미 존재함). 버그를 중복되었다고 표시하기 위해서는 기존버그 번호를 필요로 한다.
  • WORKSFORME(파악할 수 없음)
    버그를 재연해 보려고 많은 노력을 기울였지만 실패했으며, 생성된 코드를 분석해봐도 왜 보고된 문제가 발생했는지를 파악할 수 없는 상태이다. 이 문제를 해결하기 위해서는 추가적인 정보가 필요하고, 그럴경우 이 버그는 다시 할당될 수 있다. 혹은 문제를 파악할 수 있을 만한 다른 개발자에게 할당할 수 있을 것이다.

플랫폼
버그가 보고된 대상 하드웨어 플랫폼 정보를 기록
OS
버그가 보고된 대상 운영체제 정보를 기록한다.

버그 등록하기

이제 버그를 등록해야될 차례다. 그런데 버그를 등록한다고 해서 바로 등록되는게 아니다. 버그를 관리해야할 제품(Products)와 구성되는 컴포넌트(Component)를 먼저 만들어야 한다. (하나의 제품은 여러개의 컴포넌트로 구성되어 있고, 각 컴포넌트 별로 버그를 관리할 필요가 있기 때문이다.)

Products메뉴를 이용해서 Products를 생성할 수 있으며, Products가 생성이 되었다면, Component를 입력할 수 있다. Component까지 만들어졌다면 버그관리를 위한 기본적인 환경이 만들어 졌다고 볼 수 있다.

이제 발생한 버그들을 그때 그때 기록하고 관리하기만 하면 된다.

+ Recent posts

티스토리툴바