테스트 대상에 비해서 테스트 자원이 부족한 경우, 우선순위를 나눠서 테스트 자원을 효율적으로 분배하기 위한 전략으로 리스크를 정의하고 분석하고, 그에 대한 회피 전략을 세우고 수행하는 과정 (Risk-Based Testing)
모든 결함을 발견하는 것은 불가능하고 시간·비용·인력은 항상 부족하다는 보편적 법칙(Universal Rule)이 출발점. 따라서 [[소프트웨어 테스트 프로세스#테스트 원리 7가지|테스트 원리 #2 (완벽한 테스트는 불가능)]] 하에서 “어디에 자원을 집중할 것인가”를 결정하는 것이 테스팅의 최선책.
Effective vs Efficient 테스팅
리스크 기반 테스팅의 도입 근거가 되는 두 축.
| 축 | 의미 | 테스터 역할 |
|---|---|---|
| Effective (효과) | 계획하였거나 원했던(decided or desired) 테스트 결과를 도출 | 어떤 결과를 도출할지 결정 |
| Efficient (효율) | 원했던 테스트 결과를 생산적으로 도출 | 가용 리소스(시간·자금·인력)를 배치 |
→ 효과와 효율을 동시에 높이는 수단: 테스트 기법·커버리지 + 도메인 지식·경험, 테스트 자동화 + 테스트 프로세스 개선.
프로젝트 리스크 개념
일정·비용·범위·품질과 같은 프로젝트 목적들 중 적어도 하나의 목적에 나쁜 영향을 끼칠지도 모르는 이벤트 혹은 상태 (PMBOK)
발생할 수 있으나 아직 발생하지 않은, 발생한다면 프로젝트 결과에 부정적 영향을 끼칠 수 있는 잠재적 문제.
리스크 2종
| 구분 | 정의 | 관련 리스크 |
|---|---|---|
| 제품 / 품질 리스크 (Product / Quality) | 직접적 효과가 제품 품질에 영향을 미치는 경우. 테스트 대상과 직접 관련 | 제품의 모듈·코드·개발자 능력 등 |
| 프로젝트 / 계획 리스크 (Project / Planning) | 직접적 효과가 프로젝트 성공에 영향을 미치는 경우. 테스트/프로젝트 관리 관련 | 이해관계자·조직 같은 외부환경 |
리스크 관리 프로세스
리스크 식별 → 리스크 분석 → 리스크 계획1. 리스크 식별 (Risk Identification)
제품 품질 관점에서 테스트 대상이 될 항목 식별, 프로젝트/제품의 리스크 요소 식별.
식별 방법:
- 기능적 / 기술적 아이템으로 분리하여 식별
- 요구사항 분석서에서 상위 레벨 테스트가 필요한 항목, 아키텍처에서 하위 레벨 테스트가 필요한 항목 도출
- 브레인스토밍 (Brainstorming)
2. 리스크 분석 (Risk Analysis)
중요하고 복잡하며 잠재적 결함이 많은 부분을 분석하여 장애 발생가능성과 장애로 인한 영향을 식별하고 우선순위 결정.
리스크 공식
리스크(risk) = 장애 발생가능성(likelihood) × 장애로 인한 영향력(impact)Reynolds(1996) 변형:
리스크 = 사용 빈도(Frequency of use) × 결함 가능성(Chance of defect)고/저 리스크 예시
| 구분 | 상황 |
|---|---|
| 높음 | 사용 빈도 높음 + 결함 가능성 높음 + 장애 손실 큼 |
| 높음 | 손실은 크지 않지만 결함 가능성 / 사용 빈도가 매우 높음 |
| 낮음 | 큰 손실이 예상되지만 거의 장애가 발생할 가능성 없음 |
리스크 레벨 척도
이해관계자 참여로 아이템별 리스크 레벨 결정.
| 레벨 | 9 | 5 | 3 | 1 | 0 |
|---|---|---|---|---|---|
| 의미 | Critical | High | Moderate | Low | None |
정성적(High / Medium / Low) 또는 정량적(5, 4, 3, …)으로 표현 가능.
3. 리스크 계획 (Risk Planning)
리스크 정보를 근거로 완화(mitigate) 정책과 대처 방안 수립 — “리스크를 줄이는 테스트”를 생성.
리스크 매트릭스 4분면
장애 발생 가능성 × 장애 영향의 2×2 매트릭스로 테스트 영역을 구분. 각 영역에 서로 다른 강도의 테스트 기법을 배정한다.
| 영역 | 위치 | 집중 기법 |
|---|---|---|
| ITA (Intensive Test Area) | 발생 높음 · 영향 높음 | 개발 테스팅 집중, 문장 커버리지 100%, 동료 검토 |
| STA (Severe Test Area) | 발생 낮음 · 영향 높음 | 공식적 테스트 설계, 경계값 분석, 완전한 코드 인스펙션, 문장 커버리지 100% |
| STTA (Strong Test Area) | 발생 높음 · 영향 낮음 | 인수 테스팅 집중, 문장 커버리지 100% |
| FTA (Fundamental Test Area) | 발생 낮음 · 영향 낮음 | 기회 되면 자유롭게 테스팅 |
→ 리스크 레벨이 수행될 테스팅의 강도(intensity)를 결정한다는 원리.