버그질라Bugzilla - 버그 추적 사용

Bugzilla 

version 0. 1

Contents

 버그 추적 시스템?

 Life Cycle of a Bug

 Using Bugzilla

 Administering Bugzilla

버그 추적 시스템?

 왜 버그 추적 시스템을 사용해야 하나?

 프로그래머가 모든 버그를 기억할 수 있나? 

 아니요

 쪽지로 버그를 보관한다면? 

 가능은 하지만 관리하기 힘들다

 사용자가 메일로 버그를 보고한다면? 

 메일은 관리하기 힘들다.

 만약 버그 정보에 대해서 체계적으로 유지하고 싶다면 ? 

 쪽지, 메일, 게시판 모두 힘들다

 그렇다면 대안은 ? 

 Bugzilla

버그 추적 시스템?

 실제 사용 사례

 Free Software Projects

 Mozilla: https://bugzilla.mozilla.org/ 

 Linux Kernel: http://bugzilla.kernel.org/ 

 Gnome: http://bugzilla.gnome.org/ 

 KDE: http://bugs.kde.org/ 

 Apache Project: http://issues.apache.org/bugzilla/ 

 Open Office: http://www.openoffice.org/issues/query.cgi 

 Eclipse: http://bugs.eclipse.org/bugs/ 

 Linux Distributions

 Red Hat: https://bugzilla.redhat.com/bugzilla/ 

 Mandriva: http://qa.mandriva.com/ 

 Gentoo: http://bugs.gentoo.org/ 

 TurboLinux: http://the.turbolinux.co.jp/bugzilla/ 

 Novell: https://bugzilla.novell.com/ 

 Companies

 Ximian: http://bugzilla.ximian.com/ 

 NASA: http://cvs588.gsfc.nasa.gov/bugzilla/ 

 Id Software: http://zerowing.idsoftware.com/bugzilla/ 

버그 추적 시스템?

 버그 처리와 개발 시간

 만약 치료할 수 있는 버그를 나중에 한번에 처리하려 한다면?

 과연 버그 발생 코드를 쉽게 생각해낼 수 있을 까요?

• 아닙니다. 새로운 코드를 작성하기 전에 버그를 수정해야 합니다.

 나는 쉽게 생각해낼 수 있다.!! 그러므로 나중에 처리해야지..라면?

• 아닙니다. 코드를 작성하는 시간은 예측할 수 있으나 버그를 수정하는 시간은 예측 할 수 없습니다.  결국 프로젝트 일정이 불안해집니다.

 만약 버그의 상태를 모르고  버그를 수정 한다면?

 빙산의 일각인 버그를 수정하려 한다면 개발 시간이 엄청 소모된다.

 남이 처리한 버그를 처리하려고 노력하는 현상이 생길 수 있다.

Life Cycle of a Bug

Life Cycle of a Bug

 UNCONFIRMED

 최근에 등록된 버그

 정말 버그인지 모르는 상태

 Status Change

 NEW :사용자가 승인

 RESOLVED  : 해결

 NEW

 목록에 추가된 버그

 반드시 처리되어야 함

 Status Change

 ASSIGNED : 다른 사람에게 전달

 RESOLVED : 문제가 해결된 상태

Life Cycle of a Bug

 ASSIGNED

 해결 못했지만 적합한 사람에게 할당

 Status Change

 NEW : 다시 다른 사람에게 할당

 RESOLVED  : 해결

 RESOLVED

 처리가 된 상태

 Status Change

 REOPEN : 부정확한 처리

 VERIFIED : 검증이 필요

 CLOSED : 완전한 처리

Life Cycle of a Bug

 REOPEN

 해결한 버그지만, 부정확하게 처리

 만족스럽지 못한 처리

 해당 버그가 재연된 경우

 Status Change

 ASSIGNED : 다른 사람에게 할당

 RESOLVED  : 해결

 VERIFIED

 QA 담당자가 버그와 처리결과를 살펴봄

 고객에게 전달되는 시점까지 남아있음

 Status Change

 CLOSED :고객에게 인도 될 때

 REOPEN : 처리결과가 불 만족스러울 때

 CLOSED

 처리결과 정확

 해당 버그가 죽었음

 Status Change

 REOPEND : 좀비처럼 돌아 다닐 때

Life Cycle of a Bug

Life Cycle of a Bug

 RESOLUTION

 FIXED

 테스트 완료 버그 트리에 해결

 INVALID

 기술된 문제는 버그가 아님

 WONTFIX

 기술된 문제는 절대로 해결될 수 없는 버그

 LATER

 기술된 문제는 이번 버전에서는 수정이 불가능한 버그

 REMIND

 100% 수정할 수 없는 버그이고 계속 영향을 끼칠 것으로 예상

 DUPLICATE

 기존버그와 중복

 WORKSFORME

 생성된 코드를 분석해도 왜 이런 행동을 하는지 파악할 수 없는 상태 추후에 추가 정보가 들어온다면 버그를 다시 할당

Life Cycle of a Bug

 Severity

 Blocker

 개발 혹은 테스팅 작업을 진행할 수 없게 만듦.

 Critical

 프로그램이 깨지거나, 데이터 손상 및 메모리 누수가 발견됨

 Major

 기능상의 중요한 결점이 발견됨

 Normal

 일반적인 문제로 반드시 고쳐야 할 버그

 Minor

 덜 중요한 결점이 발견되거나 쉽게 해결될 수 있는 버그

 Priority

 즉시 (P1)  >  긴급 (P2) > 보통(P3) > 낮음(P4) > 없음(p5)

Bugzilla Main Page

Search existing bug reports

 Find a Specific Bug 

 Advanced Search

 Status 

 Open : 현재 버그로 등록된 버그 리스트

 Close : 처리 완료된 버그 리스트

 ALL : 모두

 Product

 프로젝트 명

 Words

Search existing bug reports

 Find a Specific Bug 

 Product

 Component

 Version

 Status

 Resolution

 Severity

 Priority

 Hardware

 OS

 Email and Numbering

 Bug Changes

Search existing bug reports

 Find a Specific Bug 

 검색된 버그 리스트를 보여준다.

Editing bug reports

 Editing bug reports

 Product

 Comments

 CC

 버그가 수정 되었을 때 메일을 전송 해야할 주소

 Attachment

 첨부 파일

 기타 라디오 버튼

Enter a new bug report 

 Select Project 

 프로젝트를 선택

Enter a new bug report 

 Enter a new bug report

 새로운 버그 등록

 주의사항

 정확하고 자세히 남기기

Reporting and Charting Kitchen 

 Reporting and Charting Kitchen

 PIE

 BAR

 TABLE

 surprising? 

Administering Bugzilla

 Parameters : Bugzilla 환경 설정

 User Preferences : 일반 User가 보는 페이지 환경 설정

 Users : User 리스트 검색

 Products : 프로젝트 생성 와 컴포넌트 생성 및 제거

 Flags 

 Field Values : Bugzilla 검색 결과 및 에디트 

 Groups : 그룹관리

 Keyword : 프로젝트 용어 설명 추가 삭제 

 Whining : Bugzilla 서버에서 사용자 또는 관리자에게 메시지 전달설정

Parameters

 Parameters : Bugzilla 환경 설정

 Required Settings

 Administrative Policies

 User Authentication

 Attachments

 Bug Change Policies

 Bug Fields

 Bug Moving

 Dependency Graphs

 Group Security

 Localization

 LDAP

 Email

 Patch Viewer

 Query Defaults

 Shadow Database

 User Matching

User Preferences

 일반 User가 보는 페이지 환경 설정

 일반 User가 Bugzilla를 사용할 때의 페이지 설정

Users

 User 리스트 검색

 등록된 User를 검색한다.

 Group으로 검색가능

Products

 프로젝트 생성 와 컴포넌트 생성 및 제거

 새로운 프로젝트 생성

 Product : 프로젝트 명

 Description : 프로젝트 설명

 Maximum votes per person : 버그로 인정할 사람의 수

 State : 몇 명이 인정해야 UNCONFIRMED state에서 벗어나는 가의 사람 수

 Version : 버전

Field Values

 Bugzilla 검색 결과 및 에디트

 버그 입력시 현재 개발환경에 대한 설정

Change Group

 그룹관리

 새로운 그룹추가

 그룹설정

Whining 

 Bugzilla 서버에서 사용자 또는 관리자에게 메시지 전달설정

 시간을 설정하여 사용자 또는 관리자에게 메시지를 전달할 수 있는기능