결함(Fault)의 정의
- 결함은 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것을 의미한다.
- 사용자가 예상한 결과와 실행 결과 간의 차이나 업무 내용과의 불일치 등으로 인해 변경이 필요한 부분도 모두 결함에 해당된다.
결함 관리 프로세스
- 결함관리 프로세스는 애플리케이션 테스트에서 발견된 결함을 처리하는 것으로, 처리 순서는 다음과 같다.
- 결함 관리 계획: 전체 프로세스에 대한 결함 관리 일정, 인력, 업무 프로세스 등을 확보하여 계획을 수립하는 단계이다.
- 결함 기록: 테스터는 발견된 결함을 결합 관리 DB에 등록한다.
- 결함 검토: 테스터, 프로그램 리더, 품질 관리(QA) 담당자 등은 등록된 결함을 검토하고 결함을 수정할 개발자에게 전달한다.
- 결함 수정: 개발자는 전달받은 결함을 수정한다.
- 결함 재확인: 테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행한다.
- 결함 상태 추적 및 모니터링 활동: 결함 관리 DB를 이용하여 프로젝트별 결함 유형, 발생률 등을 한눈에 볼 수 있는 대시보드 또는 게시판 형태의 서비스를 제공한다.
- 최종 결함 분석 및 보고서 작성: 발견된 결함에 대한 정보와 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료한다.
결함 상태 추적
- 테스트에서 발견된 결함은 지속적으로 상태 변화를 추적하고 관리해야 한다.
- 발견된 결함에 대해 결함 관리 측정 지표의 속성 값들을 분석하여 향후 결함이 발견될 모듈 또는 컴포넌트를 추정할 수 있다.
- 결함관리 측정 지표
- 결함 분포: 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함수 측정
- 결함 추세: 테스트 진행 시간에 따른 결함 수의 추이 분석
- 결함 에이징: 특정 결함 상태로 지속되는 시간 측정
결함 추적 순서
- 결함 추적은 결함이 발견된 때부터 결함이 해결될 때까지 전 과정을 추적하는 것으로 순서는 다음과 같다.
- 결함 등록(Open): 테스터와 품질 관리(QA) 담당자에 의해 발견된 결함 등록된 상태
- 결함 검토(Reviewed): 등록된 결함을 테스터, 품질 관리(QA) 담당자, 프로그램 리더, 담당 모듈 개발자에 의해 검토된 상태
- 결함 할당(Assigned): 결함을 수정하기 위해 개발자와 문제 해결 담당자에게 결함이 할당된 상태
- 결함 수정(Resolved): 개발자가 결합 수정을 완료한 상태
- 결함 조치 보류(Deterred): 결함의 수정이 불가능해 연기된 상태로, 우선순위, 일정 등에 따라 재오픈을 준비중인 상태
- 결함 종료(Closed): 결함이 해결되어 테스터와 품질 관리(QA) 담당자가 종료를 승인한 상태
- 결함 해제(Clarified): 테스터, 프로그램 리더, 품질 관리(QA) 담당자가 종료 승인한 결함을 검토하여 결함이 아니라고 판명한 상태
결함 분류
- 테스트에서 발견되는 결함을 유형별로 분류하면 다음과 같다.
- 시스템 결함: 시스템 다운 애플리케이션의 작동 정지, 종료, 응답 시간 지연 데이터베이스 에러 등 주로 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함
- 기능 결함: 사용자의 요구사항 미반영/불일치 부정확한 비즈니스 프로세스, 스크립트 오류, 타 시스템 연동 시 오류 등 애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함
- GUI 결함: UI 비일관성, 데이터 타입의 표시 오류, 부정확한 커서/메시지 오류 등 사용자 화면 설계에서 발생된 결함
- 문서 결함: 사용자의 요구사항과 기능 요구사항의 불일치로 인한 불완전한 상태의 문서, 사용자의 온라인/오프라인 매뉴얼의 불일치 등 기획자 사용자 개발자 간의 의사소통 및 기록이 원활하지 않아 발생된 결함
테스트 단계별 유입 결함
- 기획 시 유입되는 결함: 사용자 요구사항의 표준 미준수로 인한 테스트 불가능, 요구사항 불명확/불완전/불일치 결함 등
- 설계 시 유입되는 결함: 설계 표준 미준수로 인한 테스트 불가능 기능 설계 불명확/불완전/불일치 결함 등
- 코딩 시 유입되는 결함: 코딩 표준 미준수로 인한 기능의 불일치/불완전, 데이터 결함, 인터페이스 결함 등
- 테스트 부족으로 유입되는 결함: 테스트 수행 시 테스트 완료 기준의 미준수, 테스트팀과 개발팀의 의사소통 부족, 개발자의 코딩 실수로 인한 결함 등
결함 심각도
- 결함 심각도는 애플리케이션에 발생한 결함이 전체 시스템에 미치는 치명도를 나타내는 척도이다.
- 결함 심각도를 우선순위에 따라 분류하면 다음과 같다.
- High: 핵심 요구사항 미구현 장시간 시스템 응답 지연 시스템 다운 등과 같이 더 이상 프로세스를 진행할 수 없도록 만드는 결함
- Medium: 부정확한 기능이나 데이터베이스 에러 등과 같이 시스템 흐름에 영향을 미치는 결함
- Low: 부정확한 GUI 및 메시지 에러시 메시지 출력 화면상의 문법/철자 오류 등과 같이 시스템 흐름에는 영향을 미치지 않는 결함
결함 우선순위
- 결함의 우선순위는 발견된 결함 처리에 대한 신속성을 나타내는 척도로 결함의 중요도와 심각도에 따라 설정되고 수정 여부가 결정된다.
- 일반적으로 결함의 심각도가 높으면 우선순위도 높지만 애플리케이션의 특성에 따라 우선순위가 결정될 수도 있기 때문에 심각도가 높다고 반드시 우선순위가 높은 것은 아니다.
- 결함 우선순위는 결정적(Critical), 높음(High), 보통(Medium), 낮음(Low) 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류된다.
결함관리 도구
- 결함 관리 도구는 소프트웨어에 발생한 결함을 체계적으로 관리할 수 있도록 도와주는 도구로, 다음과 같은 것들이 있다.
- Mantis: 결함 및 이슈 관리 도구로 소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적도 가능하다.
- Trac: 결함 추적은 물론 결함을 통합하여 관리할 수 있는 도구
- Redmine: 프로젝트 관리 및 결함 추적이 가능한 도구
- Bugzilla: 결함 신고확인 처리 등 결함을 지속적으로 관리할 수 있는 도구로 결함의 심각도와 우선 순위를 지정할 수도 있다.
출처: 2024 시나공 정보처리기사 필기 기본서
alpaka의 자격증 공부장