| sitelink1 | http://blog.naver.com/mydaylee/140020063020 |
|---|---|
| sitelink2 | |
| sitelink3 | |
| extra_vars4 | |
| extra_vars5 | |
| extra_vars6 |
결함 추적(Defect tracking) 이란?
: 결함 추적이란 결함이 발견된 때부터 해결된 때까지의 과정을 기록하고 추적하는 작업이다. 결함 추적은 개별적 수준, 즉 각각의 결함을 추적하며, 동시에 공개된 결함의 개수, 해결된 비율, 결함을 하나 해결하는 데 소요되는 평균 시간과 같은 통계적 수준에서도 이루어진다. 버그 추적(Bug tracking) 이라고도 부른다.
결함 추적의 시기
: 결함 추적은 프로젝트 초기부터 시작해야 한다. 프로젝트 초기부터 결함 추적을 시작하면, 프로젝트 전반에 걸쳐 결함을 제거해야 하는 작업의 중요성을 자각할 수 있고, 소프트웨어에서 발견된 결함의 개수에 대한 가장 정확한 정보를 얻을 수 있다.
결함 추적의 필요성
- 결함 추적은 품질을 향상 시키므로서 개발 비용을 줄인다.
- 결함 정보를 수집하면 프로젝트의 현 상태를 추적하고 평가하며, 또한 이후의 프로젝트에서도 유용하게 활용할 수 있는 그래프와 보고서를 만들 수 있다.
결함 추적과 소프트웨어 릴리즈 시기와의 관계
: 소프트웨어를 언제 릴리즈할 것인지에 대한 질문은 아주 민감한 것으로 소프트웨어의 품질을 낮추더라도 빨리 릴리즈할 것인지와 늦게 릴리즈하더라도 높은 품질로 할 것인지에 대한 선택의 문제이다.
1. 결함 개수
- 소프트웨어를 릴리즈하기 전에 프로젝트 팀이 해야 할 일이 얼마나 남았는지 정략적으로 파악하기 위한 가장 기초적 방법이다. ‘결정적 결함 2, 심각한 결함 8, 화면 다듬기 147’ 과 같은 우선순위에 따라 결함 개수를 요약할 수도 있다.
- 매주 새로운 결함 개수와 해결된 결함 개수를 비교하면 프로젝트의 완성도를 파악할 수 있다. 만약 특정 주에 새 결함 개수가 그 주에 해결된 결함개수를 초과한다면, 프로젝트가 가야 할 길이 아직 많이 남은 것이다.
- 프로젝트의 품질을 관리하고 프로젝트가 완료에 가깝게 진척되면, 일반적으로 프로젝트 중기 이후에는 미해결 결함 개수가 적어지며 그 이후로도 계속 낮아진다.
※ ‘결함 공개’ 그래프
- 이 그래프를 작성하면, 결함을 통제하는 것을 우선하여 처리해야 함을 공개적으로 강조할 수 있고, 품질 문제를 관리하는 데 도움이 된다.
- ‘수정’ 결함선이 ‘미해결’ 결함선과 교차하는 지점은 심리적으로 중요하다. 이는 결함이 발견되는 속도보다 수정되는 속도가 더 빠르다는 것을 의미한다.
- 만약 프로젝트 품질이 관리되지 않고 프로젝트가 제자리 걸음을 한다면, 미해결 결함 개수가 계속 증가하는 것을 보게 될 것이다. 이런 경우가 발생하면 새로운 기능을 추가하기 전에 기존 설계와 코드 품질을 먼저 개선해야 한다.
2. 결함 당 공수 통계
- 결함을 수정하는 데 필요한 시간을 결함 유형별로 분류해 정리하면, 현재의 프로젝트와 차후의 프로젝트에서 잔여 결함 수정 작업을 추정하는 데이터로 사용할 수 있다. 이런 정보를 수집해 두면 프로젝트 중반기쯤 “프로젝트에는 미해결 결함 230개가 있고, 개발자가 결함 하나를 수정하는데 평균 3시간이 걸리므로, 잔여 결함을 수정하는데 대략 700시간이 필요합니다.”와 같이 말해줄 수 있을 것이다.
- 결함을 발견하여 수정하는 시기에 대한 데이터는 개발 프로세스의 효율성을 평가하는 데 사용할 수 있다. 만약 결함이 만들어진 때에 이 결함의 95퍼센트가 발견된다면, 이 프로젝트의 효율성은 대단히 높은 것이며, 그 반대로 결함이 만들어지고 몇 단계가 지나고 결함의 95퍼센트가 발견된다면 많은 개선 작업이 필요한 프로젝트이다.
결함 보고서에 추적되는 정보
- 결함ID(숫자나 기타 유일한 식별자)
- 결함에 대한 설명
- 결함이 발생된 과정
- 플랫폼 정보(CPU 타입, 메모리, 디스크 공간, 비디오 카드 등)
- 결함의 현 상태(진행 중 혹은 종료)
- 결함을 발견한 사람
- 결힘이 발견된 날짜
- 심각도(1~4와 같은 수치, 혹은 사소, 심각, 중대 등과 같은 단계)
- 결함이 생성된 단계(요구 분석, 아키텍쳐, 설계, 구축, 결함 테스트 등)
- 결함이 발견된 단계(요구 분석, 아키텍쳐, 설계, 구축 등)
- 결함이 수정된 날짜
- 결함을 수장한 사람
- 결함을 수정하는 데 소요된 공수(staff hour)
- 수정된 작업 산출물이나 결과(요구사항 기술서, 설계 다이어그램, 코드 모듈, 사용자 매뉴얼/요구 명세서, 테스트 등)
- 경과(수정 중, 검토 중, 품질 보증 검증 중, 수정 여부, 혹은 결함이 아닌 것으로 밝혀졌거나 재현할 수 없는 경우 등)
- 기타
결함을 찾는 효율적인 접근 방법
1. 오류를 안정화시킨다.
: 오류를 발생 시키는 복합적으로 사용되는 10개의 요소가 있다면 오류를 발생시키는 것과 관련이 없는 요소들이 무엇인지 테스트하여 오류와 관련없는 요소를 분리한다.
2. 오류(“결점”)의 원인을 찾아낸다.
a. 결함을 만들어내는 데이터를 수집한다.
b. 수집된 데이터를 분석하고 결함에 대한 가설을 세운다.
c. 프로그램을 테스트하거나 코드를 살펴봄으로써 그러한 가설을 증명하거나 반증할 방법을 결정한다.
d. 2(c)에서 규명한 절차를 사용하여 가설들을 증명하거나 반증한다.
3. 결함을 수정한다.
4. 수정한 내용을 테스트한다.
5. 유사한 오류를 찾는다.
결함을 찾는 데 도움이 되는 팁
1. 결함을 찾아내기 위한 기법들
- 가설을 세우기 위해서 사용할 수 있는 모든 데이터를 사용하라.
- 오류를 생산하는 테스트 케이스를 개선하라.
- 단위 테스트 슈트에서 테스트를 조사하라.
- 사용할 수 있는 도구들을 사용하라.
- 오류를 여러 가지 다양한 방법으로 재생산하라.
- 보다 많은 가설들을 세우기 위해서 더 많은 데이터를 만들어라.
- 부정적인 테스트의 결과를 사용하라.
- 가능한 가설들을 위해서 브레인스토밍을 하라.
- 책상 옆의 연습장을 두고 시도할 것들에 대한 목록을 작성하라.
- 코드에서 의심스러운 부분들을 좁혀라.
- 이전에 결함이 있었던 클래스와 루틴들을 의심하라.
- 최근에 변경된 코드를 검사하라.
- 의심스러운 코드 부분을 확장하라.
- 점증적으로 통합하라.
- 일반적으로 자주 발생하는 결함을 검사하라.
- 문제에 대해서 다른 사람에게 이야기하라.
- 문제로부터 떨어져 휴식을 취하라.
- 지저분한 디버깅에 대한 최고 시간을 설정하라.
- 순차적 대입 기법에 대한 목록을 작성하려 사용하라.
2. 구문 오류를 위한 기법들
- 컴파일러 메시지에 있는 줄 번호를 믿지 말라.
- 컴파일러 오류 메시지를 믿지 말라.
- 컴파일러의 두 번째 메시지를 믿지 말라.
- 분할 정복하라.
- 잘못된 주석과 인용 부호(따옴표)를 찾기 위해서 구문 중심의 편집기를 사용하라.
3. 결함을 수정하기 위한 기법들
- 수정하기 전에 문제를 이해하라.
- 문제만을 이해하는 것이 아니라 프로그램을 이해하라.
- 결함 분석을 확인하라.
- 긴장을 풀어라.
- 자신의 해결책이 맞다는 것을 확인하기 위해서 휴식을 취하라.
- 원본 소스 코드를 저장하라.
- 증상이 아닌, 문제를 해결하라.
- 한 번에 한 가지만 변경하라.
- 수정한 내용을 검사하라.
- 결함을 노출하는 단위 테스트를 추가하라.
- 유사한 결함을 찾아라.
좋은 결함 추적 보고서의 3요소(조엘)
1. 버그를 재현할 수 있는 과정
2. 당초 기대했던 적정 결과
3. 버그로 인한 실제 결과
효과적인 결함 추적을 위한 10계명(조엘)
1. 유능한 테스트 담당자는 항상 버그 재현 과정을 최소한의 범위로 축소하기 위해 노력한다.
이런 노력은 프로그래머가 버그의 원인을 찾아내는 데 크게 도움이 된다.
2. 처음 버그를 등록한 사람만이 그 버그를 종결할 수 있다는 점을 명심하라.
누구든 버그를 수정할 수는 있지만, 처음 버그를 발견한 사람만이 그 버그가 완벽하게 고쳐졌는지도 확인할 수 있다.
3. 버그를 해결하는 방법에는 여러 가지가 있다.
FogBUGZ 데이터베이스를 이용하면, 수정완료, 수정불가, 연기, 재현불가, 중복버그, 설계상의오류 등으로 버그를 처리할 수 있다.
4. ‘재현 불가’라 함은 어느 누구도 그 버그를 다시 재현해낼 수 없는 경우를 말한다.
버그 보고서에 버그 재현 과정이 누락되어 있는 경우, 프로그래머들은 종종 재현 불가 판정을 이용한다.
5. 버전 관리에 유의하라. 테스트 담당자에게 제출하는 소프트웨어에는 항상 빌드(build) ID를 명시해야 한다.
그렇지 않으면, 가엾은 테스트 담당자가 디버깅도 되지 않은 소프트웨어 버전을 가지고 버그 수정 여부를 테스트하는 상황이 벌어질 수도 있다.
6. 테스트 담당자들이 버그 추적 데이터베이스를 사용하려 들지 않아서 애를 먹고 있는 프로그래머들이 있다면, 버그 데이터베이스 이외의 방법으로는 아예 버그 보고서를 접수하지도 마라.
혹시 테스트 담당자가 이메일로 버그 보고서를 보내오거들랑, “이 내용을 버그 데이터베이스에 입력해 주세요.
이메일은 추적관리가 불가능하답니다.” 라는 짤막한 메시지와 함께 버그 보고서를 되돌려보내라.
7. 반대로, 프로그래머들이 버그 추적 데이터베이스를 사용하려 들지 않아서 애를 먹고 있는 테스트 담당자들이 있다면, 그냥 아무말도하지마라.
버그 정보를 버그 데이터베이스에 입력하면, 데이터베이스가 알아서 프로그래머에게 이메일을 보내줄 테니까.
8. 동료 프로그래머들이 버그 추적 데이터베이스를 사용하려 들지 않는다면, 버그 수정 업무를 할당할 때 꼬박꼬박 버그 추적 데이터베이스를 이용하라.
결국은 동료들도 그 뜻을 이해하게 될 것이다.
9. 거금을 들여 설치한 버그 추적 데이터베이스를 아무도 사용하지 않아서 고민하는 관리자가 있다면, 프로그래머들한테 새로 개발할 기능을 할당할 때도 버그를 이용해 보라.
버그 추적 데이터베이스는 “구현 예정 기능” 데이터베이스로서도 손색이 없다.
10. 버그 추적 데이터베이스에 새로운 필드를 추가하고픈 유혹을 이겨내라.
아마 매달 누군가는 데이터베이스에 추가할 새 필드에 대한 그럴듯한 아이디어를 내놓을 것이다.
솔깃한 아이디어는 얼마든지 있을 수 있다.
이를테면, 버그가 발견된 파일을 추적할 필드를 만든다거나, 버그 재현 가능 비율을 퍼센티지로 추적할 필드를 추가한다거나, 버그 발생 횟수를 기록할 필드를 만든다거나, 버그가 발생한 시스템에 설치된 DLL의 버전을 기록할 필드를 추가한다거나, 기타 등등. 이런 아이디어에 현혹되어서는 안 된다.
이런 제안에 넘어가다 보면, 버그 추적 데이터베이스는 결국 수천 개의 데이터 필드로 가득차게 될 것이고 아무도 그 데이터베이스에 버그 보고서를 입력하려 들지 않을 것이다.
버그 추적 데이터베이스가 실효성을 거두려면 모든 사람들이 그것을 사용해야 한다.
그런데, “공식적으로” 버그를 입력하는 일이 너무 번거로운 작업이 된다면 아무도 버그 추적 데이터베이스를 이용하려 들지 않을 것이다.
Mantis 운영 다이어그램(규서스)
Mantis 상태 정보
1. 이슈 상태
A. 새로운 이슈
B. 정보 부족 - 정보가 더 필요하며 처음 보고한 사람은 주목해야 함
C. 이슈 검토 - 이슈에 대해 조사했으나 확인이나 할당되지 않은 상태이며 해당 개발자는 이슈로 인정하지 않을 수 있음을 유저에게 알림
D. 확인된 이슈 - 개발자가 이슈 내용을 확인하고 재현할 수 있음. 보통 정보를 갱신하는 사람(updater)이나 다른 개발자가 설정한다.
E. 할당된 이슈 - 현재 개발자에게 할당되어 처리 중임
F. 해결된 이슈 - 이슈를 수정한 것으로 판단하며 이에 대한 확인을 기다리고 있음
G. 폐쇄된 이슈 - 이슈가 완전 해결되어 폐쇄함.
2. 심각도(Severity)
: 버그의 타격(impact)에 대하여 기술합니다.
A. 새 기능 요구
B. 사소함 - 그래픽 정렬, 형식 등 단순 외형적 문제 등 별 것 아닌 사소한 것
C. 오타 - 글, 문법, 단어 등의 오류
D. 기능 개선 (tweak) - 기능 향상 등의 개선 및 조정이 필요
E. 보통 (minor bug) - 기능상 덜 중요한 문제나 쉽게 해결할 수 있는 문제
F. 중요함 (major bug) - 기능상 중요한 문제
G. 충돌 - 응용 풀로그램 또는 OS 의 충돌
H. 장애 - 개발 혹은 시험 작업을 더 이상 진행하기 어려움
3. 예상 작업량
A. 조정 (tweak) - 곧 처리됨
B. 작은 수정 (minor fix) - 많은 시간이 걸리지는 않음
C. 새로 작성 (major rework) - 일 양이 매우 많음
D. 재설계 (redesign) - 재설계가 필요함
4. 해결 상태
A. 개설
B. 수정됨 - 시험 완료됐으며 이슈 상태는 해결됐다고 표시함
C. 문제 제기 - 이전에 해결했지만 당시 처리 결과가 만족스럽지 않거나 정확하게 처리되지 않아 다시 발생한 상태
D. 재현할 수 없음 - 이슈를 재현할 수 없으며 코드를 살펴봐도 파악할 수 없는 상태임. 추가적인 정보가 들어오면 다시 할당하도록 함
E. 수정할 수 없음 - 이번 버전에서는 수정할 수 없는 문제임
F. 중복 - 기본의 이슈와 중복된 것으로 중복된 이슈 번호가 필요함 ('#이슈번호'로 표시)
G. 이슈 아님
H. 보류(suspended) - 중요하지 않은 문제로 수정을 보류함
I. 수정 계획 없음
결함 추적 시스템 도입시 주의 사항 (심우곤)
한가지 주의하실 점은 버그 추적 시스템만 도입한다고 소프트웨어 품질이 향상되지 않는다는 것입니다. 버그 추적 시스템으로 구축된 소프트웨어 시스템의 버그들을 해결하는 것보다는, 시스템 구축 전에 결함들을 도출하여 관리하는 프로세스와 시스템이 갖춰질 때야 진정으로 문제가 해결할 수 있을 것입니다.
Mantis 관련 홈페이지
Mantis 공식 홈페이지 : http://mantisbt.org/
Mantis 매뉴얼 : http://manual.mantisbt.org/
Mantis 프로그램 다운로드 : http://mantisbt.org/download.php
Mantis 포럼 : http://forums.mantisbt.org/
Tip
Mantis 설치방법 <= 추천
: http://blog.naver.com/reaby/60014144425
Mantis 언어 설정 바꾸기
: config_inc.php 파일안에 아래 내용 추가
$g_default_language = 'korean';
Mantis 한글 UTF-8 사용하기
: http://blog.naver.com/daroobil/16532048
Mantis 한국어 번역 파일 ? 원래 패키지에 있는 파일을 더욱 사용하기 편하게 변경
: http://www.blogmeme.com/blog/index.php?blog_id=2&article_id=978
Mantis 상태 체크 해보기
: Mantis가 설치된 폴더에 ../mantis/admin/check.php 실행
Mantis DB의 사용자 정보 테이블 이름
: mantis_user_table
버그 시스템에 대한 소개 ? 심우곤
: http://www.jlab.net/news/20030810/news.htm
참고 자료
- 조엘 온 소프트웨어
- 소프트웨어 프로젝트 생존전략
- 코드 컴플릿 2/E
- 규서스님(http://blog.naver.com/kyuseo) : Mantis 운영 다이어그램
