SW결함 분석기법 - 결함처리 프로세스, 결함 리포팅, 결함 상태의 정의

 

 

SW결함 분석기법

·       결함처리 프로세스

·       결함 리포팅

·       결함 상태의 정의

 

 

결함처리 프로세스

프로세스	설명
Report Defect	테스트팀에서 발견된 결함은 결함 관리 시스템(Defect Management System)에 기록된다.
Yank Defect	개발팀에서는 자신의 모듈에서 발생한 Defect를 꺼내 가지고 온다.
Asign Defect	개발팀 리더는 Defect를 개발팀의 일정과 리소스, 그리고 담당에 따라서 개발자에게 배치한다.
Fix Defect	Defect를 할당받은 개발자는 담당 테스트 엔지니어와 함께 재현과 추적 등을 통해서 Defect를 수정한다.
Confirm Fix & Ad Test Case	Defect가 수정되었으면, Defect를 검증할 수 있는 단위 Test Case를 보강하여 Fix된 코드와 함께 소스 관리 시스템에 저장한다.
Change defect status to "Resolved"	Defect Management System에 해당 Defect를 해결됨(Resolved) 상태로 바꾸고, 테스트 엔지니어에게 다시 배당한다.
Confirm Test	테스트 엔지니어는 해결된 Defect를 다시 테스트하여 문제가 없는지 검증한다.
Close the Defect	문제가 없을 경우에는 해당 Defect를 Close한다. 만약 문제가 해결되지 않았으면 다시 Defect Management System을 통해서 해당 개발자에게 다시 Asign하고 4번 단계(Fix Defect)부터 다시 반복하여 해결한다.

 

 

 

♣결함 리포팅

테스트 중 발견된 결함은 다음과 같은 항목에 의해 저장하여 관리한다.

항목	설명
Number (번호)	·       결함의 고유 번호이다.
Title (제목)	·       결함의 내용을 간단하게 한줄로 기록한다.
Description (설명)	·       결함에 대한 자세한 내용을 서술한다. ·       구체적으로 어떤 결함인지, 그리고 결함을 재현하는 절차와 분석 내용들을 서술한다.
Module (모듈)	·       전체 시스템 중에서 결함이 발견된 컴포넌트나 모듈명을 명시한다.
Version & Fixed Version (발견 버전과 수정 버전)	·       Version은 결함이 발견된 버전, Fixed Version은 해당 결함이 해결된 버전이다. 결함은 버전에 따라서 다르게 발생할 수 있기 때문에 반드시 이 항목이 정의되어야 한다.
Servirty, Priority (시급도와 우선순위)	·       시간적으로 빨리 처리해야 하는 경우 시급도가 높은 것을 의미하고, 결함의 우선순위는 위중도(위험도)를 의미한다. 결함의 우선순위가 높을수록 중결함이 되고, 낮을수록 경결함이 된다. 시급도가 높은 결함중 우선순위가 높은 결함을 우선적으로 처리한다. 시급도와 우선순위는 각각 5단계 정도로 나눠서 정의하는 것이 바람직하며, 일반적인 결함은 중간 단계인 3단계 정도로 하며, 시급도와 우선순위가 가장 높은 결함의 경우에는 최우선적으로 처리해야 하기 때문에 긴급하게 개발팀과 테스트 자원을 투여해야 한다.
Status (결함 처리 상태)	·       현재 결함이 처리되고 있는 상태를 기록한다.
Fixed code (코드 수정 내용)	·       결함을 수정하였을 경우에는 수정 내용을 기록해야 한다. ·       결함 내용 수정은 소스 코드 수정인 경우가 많은데, 이때는 소스 코드 수정 내용을 기록한다. ·       별도로 소스 코드 내용을 기록하는 것보다는 소스코드 관리 시스템(SCM)에 수정코드를 반영한 버전(Revision Number)을 기록해 놓으면 된다.
Attachment (첨부 파일)	·       결함을 기록할때는 첨부 파일을 사용하는데, 이 첨부 파일은 결함 발생 당시의 로그나 데이터 (CPU 사용률, 네트워크 상황), 결함을 추적하는 데 사용된 코드나 샘플, 결함이 해결되었을 경우 패치 같은 것을 첨부한다.

 

 

 

결함 상태

결함은 아래에서 정의한 상태로 진행된다.

항목	설명
New	·       테스트 과정에서 새로운 결함이 발견되어 결함 관리 시스템에 등록된 상태입니다.
Opened	·       등록된 결함이 개발팀에게 넘어갔을 때의 상태를 Opened라고 합니다. ·       결함이 발생한 모듈을 개발한 개발팀에게 결함이 전달된 상태로, 아직 담당자는 정해지지 않은 상태입니다.
Asigned	·       결함을 수정할 개발자에게 결함이 할당된 상태입니다.
NMI (Need More Information)	·       "추가 정보가 필요함" 상태 ·       개발팀에서 결함의 내용을 검토했을 때, 결함의 원인과 정확한 증상들을 확인할 수 없을 때, 추가적인 로그나 재현절차를 테스트 팀에 다시 요구 하는 상태입니다. ·       개발팀은 자료가 부족한 결함에 대해서 NMI 상태로 바꾼 후에, 결함을 보고한 테스트 엔지니어에게 다시 배당합니다.
In Progres	·       개발자가 결함을 확인하고, 수정 작업 중인 단계입니다.
Postponed	·       결함 처리 과정에서 결함의 중요도가 낮거나 다른 결함 수정 일정 또는 개발일정에 따라서 우선순위 조정이 필요할 때, 결함의 처리를 미뤄놓은(지연시킨) 상태입니다.
Resolved	·       결함이 해결된 상태이다. 해결은 되었으나, 개발팀 차원에서 결함이 해결된 것이고, 아직 테스트팀으로 부터 결함에 대한 재 테스트를 통한 확인을 받지 못한 상태입니다. ·       결함이 Resolved 상태로 바뀌면 개발팀은 확인테스트를 요청하기 위해서 테스트 팀에 다시 해당 결함을 Asign합니다.
Closed	·       테스트팀에 의해 결함의 수정 내용이 확인되고 제품의 소스코드에 반영된 상태로, 결함 처리의 최종 단계입니다.
Attachment (첨부 파일)	·       결함을 기록할 때는 첨부 파일을 사용합니다 ·       첨부 파일에는 결함 발생 당시의 로그나 데이터(CPU 사용률, 네트워크 상황), 결함을 추적하는데 사용된 코드나 샘플, 결함이 해결되었을 경우 패치 같은 것을 첨부합니다.