[2과목-4장-057] 결함 관리

1. 결함

: 오류 발생, 작동 실패 등과 같이 SW가 개발자가 설계한 것과 다르게 동작 or 다른 결과가 발생되는 것

- 예상 결과와 실행 결과 간 차이 or 업무 내용과의 불일치 등으로 인해 변경이 필요한 부분 모두 결함

 

2. 결함 관리 프로세스

1) 결함 관리 계획

2) 결함 기록: 결함 관리 DB에 등록

3) 결함 검토: 테스터, 프로그램 리더, QA 담당자 등은 등록된 결함을 검토, 결함을 수정할 개발자에게 전달

4) 결함 수정

5) 결함 재확인

6) 결함 상태 추적 및 모니터링 활동: 결함 관리 DB 이용 > 대시보드 or 게시판 형태의 서비스를 제공

7) 최종 결함 분석 및 보고서 작성

 

3. 결함 상태 추적

- 결함 관리 측정 지표의 속성 값들을 분석 > 향후 결함이 발견될 모듈, 컴포넌트 추정 가능

- 측정 지표

1) 결함 분포: 특정 속성에 해당하는 결함 수 측정

2) 결함 추세: 테스트 진행 시간에 따른 결함 수 추이 분석

3) 결함 에이징: 특정 결함 상태로 지속되는 시간 측정

 

4. 결함 추적 순서

1) 결함 등록(Open)

2) 결함 검토(Reviewed)

3) 결함 할당(Assigned)

4) 결함 수정(Resolved)

5) 결함 조치 보류(Deferrerd): 수정이 불가능해 연기된 상태. 재오픈을 준비 중인 상태

6) 결함 종료(Closed)

7) 결함 해제(Clarified): 종료 승인한 결함을 검토 > 결함이 아니라 판명한 상태

 

5. 결함 분류

1) 시스템 결함

시스템 다운, 애플리케이션 작동 정지, 종료, 응답 시간 지연, DB 에러 등 주로 애플리케이션 환경 or DB 처리에서 발생된 결함

2) 기능 결함

사용자 요구사항 미반영/불일치, 부정확 비즈니스 프로세스, 스크립트 오류, 연동 시 오류 등 애플리케이션 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함

3) GUI 결함

UI 비일관성, 데이터 타입 표시 오류, 부정확 커서/메시지 오류 등 사용자 화면 설계에서 발생된 결함

4) 문서 결함

사용자 요구사항과 기능 요구사항의 불일치로 인한 불완전 상태의 문서, 사용자의 온/오프라인 매뉴얼 불일치 등 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원활하지 않아 발생

 

* 테스트 단계별 유입 결함

1) 기획 시 유입

2) 설계 시 유입

3) 코딩 시 유입

4) 테스트 부족으로 유입

 

6. 결함 심각도

결함이 전체 시스템에 미치는 치명도를 나타내는 척도

- 우선순위에 따라 분류

1) High: 더 이상 프로세스를 진행할 수 없도록 만드는 결함

2) Medium: 시스템 흐름에 영향을 미치는 결함

3) Low: 시스템 흐름엔 영향 미치지 않는 결함

 

7. 결함 우선순위

발견된 결함 처리에 대한 신속성을 나타내는 척도. 결함의 중요도, 심각도에 따라 설정.

- 결함 심각도 높으면 우선순위도 높지만 애플리케이션 특성에 따라 우선순위 결정될 수도 있음

> 심각도 높다고 반드시 우선순위 높은 것 아님

- 결정적(Critical) / 높음(High) / 보통(Medium) / 낮음(Low)

- 즉시 해결 / 주의 요망 / 대기 / 개선 권고

 

8. 결함 관리 도구

- Mantis: 결함 및 이슈 관리 도구. SW 설계 시 단위별 작업 내용 기록 가능 > 결함 추적 가능

- Trac: 결함 추적, 결함 통합 관리 도구

- Redmine: 프로젝트 관리 및 결함 추적 가능

- Bugzilla: 결함 신고, 확인, 처리 등 지속적 관리 도구. 심각도, 우선순위 지정 가능