개발 단계에서 발생하는 모든 결함을 관리하기 위한 활동
테스트 실행 중 검출된 결함의 보고 → 조치 → 재확인을 체계화한 활동. A-SPICE에서는 SUP.9 Problem Resolution Management로 프로세스화되어 있다.
핵심 활동
- 결함 생명주기 동안의 결함 보고 및 조치 활동 관리
- 결함 발견율·조치율·수정률 및 결함 추이(Bug Trend) 모니터링
- 결함의 심각도·우선순위에 따라 조치되고 있는지 확인·조정
결함 관리 3가지 기법
| 기법 | 정의 | 관점 |
|---|---|---|
| 결함 감소 (Reduction) | 주입된 결함을 가능한 많이 발견·제거 | 탐지 |
| 결함 봉쇄 (Containment) | 결함이 남아있어도 실패(failure)로 이어지지 않게 차단 | 영향 차단 |
| 결함 예방 (Prevention) | 결함을 예측하고 원인을 파악하여 방지·해결 | 근본 원인 제거 |
결함 예방 활동이 제대로 이루어지면 감소·봉쇄에 들이는 노력과 비용을 줄일 수 있다.
→ 탐지 중심의 소프트웨어 테스팅 뿐 아니라 정적 기법·코딩 표준·테스트 주도 개발이 예방 기법에 해당.
소프트웨어 결함의 특징
- 일반적으로 SW 개발 과정의 오류, 특히 구현 단계 오류로 인해 발생
- 개발 단계 후반부에서의 결함 수정은 비용이 많이 소요 (라이프사이클 후반으로 갈수록 기하급수적으로 증가)
- SW 개발은 인력 집약적 작업 → 결함 대부분은 개발자의 휴먼 에러
- → 휴먼 에러 예방을 통해 구현 단계 결함의 잔존 방지 필요
- → 결함 관리 단계에서 충분한 데이터 수집 필수
결함 예방을 위한 데이터 수집
| 수집 항목 | 내용 |
|---|---|
| 결함 유형 | 결함 발견자(테스터) 입장에서의 결함 모습 |
| 결함 원인 | 결함 제거자(개발자) 입장에서의 결함 원인 |
| 결함 유입 단계 | 결함이 포함된 단계 (요구·설계·구현·테스트 등) |
| 발견 단계 | 테스트 / 리뷰 / 기타 |
| 환경 정보 | OS, 테스트 환경, 테스트 ID |
→ 테스트 단계마다 결함 유형·원인이 달라질 수 있으므로 단계별로 기록.
결함 생명주기
결함이 발견되어 마감될 때까지의 8개 상태.
| 상태 | 의미 |
|---|---|
| Open | 발견된 결함을 분석하여 결함으로 보고된 상태 |
| Review | Open된 결함에 대한 처리 방안을 검토하는 단계 |
| Assigned | 결함 수정을 위해 담당 개발자가 결정되고 개발자에게 수정이 요구된 상태 |
| Resolved | 개발자가 자신에게 할당된 수정 요구를 처리한 상태 |
| Verified | 개발자가 처리한 결과가 합당하고 정확한지 검증하는 단계 |
| Closed | 정확한 수정이 이루어졌다고 판단되는 오류를 마감하는 상태 |
| Reopen | 결함이 명확하게 수정되지 않아 다시 수정을 요구하는 상태 |
| Deferred | Open된 결함을 즉각적으로 수정하지 않고 다음 릴리즈로 연기된 상태 |
결함 추적 역할 분담
- 개발자 → SW 개발 후 테스터에게 전달
- 테스터 → 테스트 계획·분석·설계에 따라 테스트 케이스 생성·실행
- 테스트 케이스 실행 중 결함 검출 → 개발자에게 전달·수정 요청
- 개발자가 수정 후 다시 테스터에게 전달 → Verified → Closed
결함 유형 taxonomy
ISO/IEC 25010 품질 특성에 대응하는 4대 영향 분류 × 15개 유형 예시.
| 결함 영향 | 결함 유형 | 정의 |
|---|---|---|
| 기능성 부적합 | 구성 요소 누락 | 필요 구성요소가 누락되는 결함 |
| 기능성 부적합 | 불필요한 기능 개발 | 불필요한 기능을 수행하는 결함 |
| 기능성 부적합 | 사용자 데이터의 비정상적 접근 | 사용자 데이터의 비정상적 접근을 일으키는 결함 |
| 기능성 부적합 | 현지 규제 미준수 | 현지 규제를 준수하지 못하는 결함 |
| 기능성 부적합 | 내부 데이터의 비정상적 접근 | 내부 데이터의 비정상적 접근을 일으키는 결함 |
| 신뢰성 부적합 | 결과값 오류 | 시스템이 옳지 않은 결과를 출력하게 하는 결함 |
| 신뢰성 부적합 | 오류 무시 | 시스템이 발생한 오류를 무시하게 하는 결함 |
| 신뢰성 부적합 | 오류 미인지 | 시스템이 오류를 인지하지 못하게 하는 결함 |
| 신뢰성 부적합 | 정상 동작을 오류로 인지 | 시스템이 정상 동작을 오류로 인지하게 하는 결함 |
| 신뢰성 부적합 | 동작 수행 미완료 | 시스템이 동작 수행을 완료하지 못하게 하는 결함 |
| 사용성 부적합 | 지역화 오류 | 언어·국가권 설정이 올바르지 않은 결함 |
| 효율성 부적합 | 메모리 누수 | 불필요한 메모리를 점유하게 하는 결함 |
| 효율성 부적합 | 자원의 비이상적 점유 | 불필요한 자원을 점유하게 하는 결함 |
| 효율성 부적합 | 속도 저하 | 시스템 처리 속도 또는 성능을 저하시키는 결함 |
| 효율성 부적합 | 동기화 오류 | 정해진 시간/횟수 내에 연결하지 못하는 결함 |
결함 처리 유형
보고된 결함의 처리 결과는 4가지로 분류된다.
| 유형 | 의미 |
|---|---|
| Fixed | 요청된 결함을 수정 완료 |
| Duplicated | 기존의 다른 결함과 중복 |
| Won’t fix | 수정이 필요할 정도로 중요·긴급하지 않아 수정하지 않음 |
| Invalid | 테스트 케이스에 문제가 있는 경우 |
테스트 결함 보고서 양식
핵심 필드:
- 식별 정보: 결함 식별자, 테스터, 테스트 날짜, 테스트 대상, 제목
- 결함 특성: 발생 가능성, 심각성·긴급성, 결함 상세 정보
- 처리 결과: 처리자, 처리 날짜, 처리 유형(Fixed / Duplicated / Won’t Fix / Invalid), 처리 설명
- 검증 결과: 검증자, 검증 날짜, 검증 결과, 검증 설명
도구 기반 결함 관리의 필요성
결함은 발견 시 제거 → 재확인 절차가 필요하고, 이 과정을 잘 기록해야 확실히 제거된다.
Excel 결함관리대장의 한계
- 동시 작업이 어려워 업데이트가 원활하지 않음
- 결함이 어느 버전에 반영되었는지 파악 불가
- 이력 추적 곤란
Web 기반 이슈 추적 시스템
Redmine, JIRA 등 Web 기반 도구는 다음을 가능하게 한다:
- 동시 작업 지원
- 게시판에 글 올리듯 결함 등록
- 결함이 어느 단계에, 누가 진행하는지 파악 가능
- 결함 진행 상태의 이력 파악 가능
→ 결함 관리가 잘 되면 그 다음 단계는 결함 예방.
이슈 관리 개요
이슈 = 기한 내에 처리해야 하고 관심을 갖고 살펴봐야 하는 대상 (새 기능·결함·지원 등). 이슈 처리 workflow와 단계별 담당자 지정을 지원.
일감 상태 4단계
| 일감 상태 | 설명 | 담당자 할당 |
|---|---|---|
| 신규 | 발견된 결함을 신규로 등록 | 결함을 발견한 사람 |
| 진행 | 담당 개발자가 결함을 수정하고 있는 상태 | 담당 개발자 |
| 해결 | 담당 개발자가 결함 조치를 완료한 상태 | 담당 개발자 |
| 완료 | 결함 발견자가 조치되었음을 최종 확인한 상태 | 결함을 발견한 사람 |
→ 앞선 결함 생명주기 8상태의 간소화 운영 버전. Open/Assigned/Resolved/Verified/Closed가 신규/진행/해결/완료에 대응.
이슈 관리 도구
Redmine
- 웹 기반 오픈소스 이슈 추적 도구
- Ruby on Rails 프레임워크 기반
- 최신 Major 버전: 3.4.6 (2018.11)
- 기본 제공 이슈 종류: 할일(Feature), 결함(Bug), 지원(Support). 사용자 정의 이슈 추가 가능 (변경 요청, 고객 항의 등)
주요 기능
- 이슈 추적
- Role-Based Access Control (개발자·PM·QA 등 역할별 권한 제어)
- Gantt Chart 및 달력
- 위키(Wiki)
- 주요 SCM(Software Configuration Management) 도구와의 연동
- LDAP 인증, REST API
설치
Ruby 기반으로 설치가 복잡 → Bitnami 패키지 이용 가능 (Redmine·Jenkins 등 여러 웹 기반 오픈소스 설치를 원스톱 제공).
JIRA
Atlassian의 상용 이슈 관리 시스템. 이슈 상태 workflow 커스터마이징 가능. 자동차 업계에서 Redmine과 함께 대표적으로 채택.
버전 관리 도구와의 연동
소프트웨어 형상 관리와 이슈 추적의 연동 포인트. Redmine 프로젝트에 저장소를 지정하고, Commit Message에 이슈 번호를 기재하면 프로젝트에서 이슈-커밋 연결이 자동 추적된다.
→ Commit Message 작성 규칙은 형상 관리 참조.
A-SPICE SUP.9 Problem Resolution Management
The purpose of the Problem Resolution Management Process is to ensure that problems are identified, recorded, analyzed, and their resolution is managed and controlled.
→ 문제를 식별·기록·분석하고 해결 방법을 관리·통제하는 활동. SUP (Supporting Process) 그룹 소속.
Base Practices — 3.1 vs 4.0
4.0에서 9개 BP가 7개로 정돈됨. “전략 개발”(3.1 BP1)과 “결함 추세 분석”(3.1 BP9)이 제거되고, 4.0은 식별·분석·권한·알림·착수·추적·보고의 실행 사이클에 집중.
| # | A-SPICE 3.1 | A-SPICE 4.0 |
|---|---|---|
| BP 1 | Develop a problem resolution management strategy | Identify and record the problem |
| BP 2 | Identify and record the problem | Determine the cause and the impact of the problem |
| BP 3 | Record the status of problems | Authorize urgent resolution action |
| BP 4 | Diagnose the cause and determine the impact of the problem | Raise alert notifications |
| BP 5 | Authorize urgent resolution action | Initiate problem resolution |
| BP 6 | Raise alert notifications | Track problems to closure |
| BP 7 | Initiate problem resolution | Report the status of problem resolution activities |
| BP 8 | Track problems to closure | |
| BP 9 | Analyze problem trends |
→ A-SPICE SUP 프로세스 그룹의 핵심. ISO 26262 기능 안전 결함 처리와 Cybersecurity 취약점 처리도 SUP.9 연계 (SEC.4.BP3).