[TMMi] 레벨.2 기준 테스트 결함 관리 절차서에 대해서 알아보자

테스트 프로세스(600) - 테스트 결함 관리 절차서 #6

표준 테스트 결함 관리 절차서에 대해서 알아보도록 하겠습니다.

테스트 프로세스의 문서 번호는 600번이며, 이 전 글을 참고하시기 바랍니다.

[TMMi : Level 2] 프레임워크 및 문서 양식 #1

🤔 결함이란? 사전에서는 완전하지 못하고 흠이 되는 부분이라고 합니다. 소프트웨어에서의 결함은 테스터가 테스트 케이스를 실행하는 과정에서 예상 결과와 모순되는 테스트 결과를 보이는 경우. 이때 결과의 변형을 소프트웨어의 결함이라고 합니다.

 

이러한 결함이나 변형은 이슈, 문제, 버그 또는 인시던트와 같은 다른 이름으로 참조됩니다.

개발자에게 결함을 리포트하는 동안 결함 보고서에는 다음과 같은 정보가 포함되어야 합니다.

• 결함 아이디 : 결함의 고유 식별 번호.
• 설명 : 결함이 발견 된 모듈에 대한 정보를 포함하여 결함에 대한 자세한 설명
• 영향 버전 : 결함이 발견 된 응용 프로그램의 버전
• 단계 : 개발자가 결함을 재현할 수 있는 스크린 샷과 시나리오
• 발견 날짜 : 결함이 등록된 날짜
• 참고 문헌 : 어디에서와 같은 문서에 대한 참조를 제공.(요구 사항, 디자인, 아키텍처 등)
• 리포터 : 결함을 제기 한 테스터의 이름
• 상태 : 결함의 상태
• 수정 한 사람 : 결함을 수정한 개발자 이름
• 마감일 : 수정 완료 일자
• 심각도 : 응용 프로그램에 대한 결함의 영향을 설명
• 우선 순위 : 결함 수정 긴급과 관련된 우선순위, 심각도 우선순위는 결함을 고정해야 하는 영향의 긴급도를 기준으로 높음/보통/낮음으로 작성

필자가 작성한 결함 심각도와 우선순위에 대해서 실무에 적용한 예시, 의견을 블로그에 담아 두었습니다.

관심 있으시면 한 번 읽어 보시길 바랍니다.

 

[STEEG - 실무 적용편] "결함 우선 순위"와 "심각도" 활용 : 품질 지표 정량화 하기

 

팀블로그에 결함 구분을 자세히 작성한 글도 참고해 보시기 바랍니다.

Defect와 Bug와 Error, Failure는 모두 같은 말인가요?

 

개정 이력

{고객사명}	SW 테스트 프로세스		작성자
	전사 표준 테스트 결함 관리 절차서		검토자
			승인자

 

<관련 부서 합의>

부서	이름	Comment	일자

<문서 제/개정 이력>

번호	제/개정 일자	제/개정 내용	문서 버전	개정자	승인자

 

1. 개요

1) 목적 

📌본 ㈜ABC(이하 ‘당사’라 함)의 결함 관리 가이드의 목적은 결함 생성부터 종료까지 전 과정을 체계적으로 관리하여, 불필요한 커뮤니케이션 낭비를 줄이고 개발의 효율성을 높이기 위함이다.

2) 적용범위

📌본 가이드는 당사의 SW 개발 프로젝트 및 유지보수 하는 모든 SW 제품에 적용한다.

3) 참고 문서

📌 전사 표준 테스트 프로세스
📌 NIPA SW테스트 가이드

[공개SW 테스트 가이드 종합] 공개SW 테스트 가이드 파일 제공 - 공개SW 포털

4) 문서 관리 담당자

📌 본 문서의 관리 담당자는 아래와 같음

역할	담당부서	담당자	내용
문서 책임자	OOO	OOO	본 문서 생성 및 수정 권한 부여
문서 검토자	OOO	OOO, OOO	작성 완료된 본 문서에 대하여 검토하고 의견 개진
문서 승인자	OOO	OOO	본 문서의 베이스라인을 승인하고 배포 허가

 

2. 상세 내용

1) 프로세스 흐름도

프로젝트 레벨 테스트 프로세스

테스트 현황/종료 보고

 

2) 세부 수행 절차

👀 절차 목록

ID	절차 명	정의
2.2.3.1	결함 관리 계획	✔ 해당 프로젝트 전반에 걸쳐 결함(이슈)을 보고, 분석, 마감하고 관리하는 계획을 본 절차서에 준하여 테스트 계획에 반영한다. ✔ 해당 프로젝트에서 결함 관리를 위한 각 담당자를 식별하여 할당하고 역할을 정의한다. 또한 결함 관리를 위한 도구를 식별하고 필요한 경우 도구 활용 방법에 대한 교육 계획을 수립한다.
2.2.3.2	잠재 결함 등록	✔ 테스트 실행 담당자가 결함으로 추정되는 사항(Incident)을 발견하면 결함 관리 계획에 준하여 결함 보고서를 작성하여 등록한다. ✔ 결함의 상태는 ‘OPEN’으로 지정한다.
2.2.3.3	결함 검토	✔ 등록된(OPEN) 잠재 결함을 결함 리뷰 담당자가 이해관계자와 검토하여 결함 여부를 확인한다. ✔ 결함 조치가 필요한 경우에는 해당 결함을 조치 담당자(개발자)에게 할당하고, 결함의 상태는 ‘Assigned’로 지정한다. ✔ 결함 조치를 하지 않을 경우에는 ‘CLOSED’ 상태로 변경하고 해당 사유에 맞게 하위 상태를 변경한다. 이때의 하위 상태로는 ‘Duplicate’, ‘Not a Bug’가 있다.
2.2.3.4	결함 수정	✔ 개발자가 결함 원인을 식별하여 어플리케이션 수정 후 재구축까지의 과정을 포함한다. 원칙적으로 산출물의 작성자가 수행하나 작성자가 존재하지 않는 경우에는 팀에서 적절한 인원을 선정하여 수행한다.   ✔ 개발자는 결함 조치를 완료 한 후 결함 상태 정보를 ‘Resolved’로 변경한다.
2.2.3.5	확인 테스트	✔ 수정 조치 된 결함을 재 테스트 및 리그레션 테스트를 통해 확인하는 활동을 의미한다.   ✔ 해당 결함을 등록한 테스터는 결함 수정 조치 확인을 한다.   ✔ 결함 수정이 안된 경우 ‘Reopen’상태로 변경하며, Side Effect로 인한 추가 결함 발견 시 신규 결함으로 등록한다.
2.2.3.6	결함 수정	✔ 테스터가 확인 테스팅 이후 추가 결함이 없을 경우, 상태를 ‘Closed(fixed)’ 로 변경한다.

 

3) 결함 수명 주기

결함 수명 주기

 

4) 결함 수명 주기 - 결함 상태 별 작업 

결함의 상태		상태 변경 주체	설명
Open / Reopen		테스터	테스터가 결함 등록한 상태 또는 결함 수정 확인 시 미수정된 상태
Assigned		개발PM	개발 PM이 결함을 리뷰하여 결함 조치 여부를 결정하고, 결함일 경우 결함 수정을 위해 개발자에게 할당하며, 결함이 아닌 경우 Resolved 처리함
Resolved		개발자	개발자의 결함 조치가 완료 되어 결함이 수정
Closed	Not bug	개발PM	결함 리뷰 결과 결함이 아님 (예: 제품사양, Spec out)
	Duplicate	개발PM	결함 리뷰 결과 중복 내용임
	Fixed	테스터	이 해결되어 마감된 상태

 

5) 결함 수명 주기 - 결함 관리 역할과 책임

책임자	책임
	테스트 수행	결함 등록	결함 리뷰	결함 상태 변경	개발자 할당	결함 조치	결함 종료
결함 리뷰 담당자			😊	😊	😊
개발자			😊	😊		😊
테스터	😊	😊	😊	😊			😊

💕 조직에 품질 관리 담당자(QA)가 있을 경우, 결함 종료에 대한 책임을 가질 수 있다.

 

3. 품질관리

1) 관련 교육

• 프로세스 재/개정 시 관련자에게 배포와 동시 교육 실시
• 신규 입사자 OJT 교육

2) 형상 관리

• 문서 명
  • 표준 테스트 결함관리 절차서
  • 표준 결함 보고서 작성 가이드
  • 표준 결함 보고서 템플릿
• 리파지토리
  • 관련 파일 서버 디렉터리 및 형상관리 방안 참고

3) 모니터링 및 제어

📌 모니터링 항목 : 결함 관리 절차 준수 여부 체크리스트

📌 모니터링 주기 : 분기 별 1회(조직의 정책을 따름)

📌 모니터링 담당자 : 품질보증 담당자

 

 

Related References

Definition of defect | Dictionary.com

Defect Management Process in Software Testing (Bug Report Template)

What is a Software Defect

TMMi

요약 : iso 표준, 국제 표준 iso, 국내 표준, 표준, istqb, kstqb, 웹 qa, 모바일 qa, 앱 qa, test web, tmmi, cmmi