개념
모듈 1(레슨 5)에서 확인했듯 모든 조합을, 모든 기능을 완전히 테스트하는 건 불가능하다. 리스크 기반 테스트(Risk-Based Testing, RBT)는 이 현실 위에서 어디에 제한된 시간을 쓸지 근거 있게 정하는 방법이다.
리스크 = 발생 가능성 × 영향도
리스크는 두 축으로 평가한다.
- 발생 가능성(Likelihood): 결함이 실제로 존재할 가능성이 얼마나 높은가. 신규로 짠 코드, 복잡한 로직, 최근에 자주 바뀐 영역일수록 높다.
- 영향도(Impact): 결함이 실제로 터졌을 때 피해가 얼마나 큰가. 자주 쓰이는 기능, 매출과 직결된 기능, 되돌리기 어려운 동작(결제, 삭제)일수록 높다.
두 축을 곱하면(또는 조합하면) 리스크 수준이 나온다. "발생 가능성은 낮지만 영향도가 극단적으로 큰" 경우(예: 결제 이중 청구)와 "발생 가능성은 높지만 영향도가 작은" 경우(예: 자주 안 쓰는 설정 화면의 사소한 UI 오류)는 다르게 다뤄야 한다.
리스크 매트릭스
3×3 매트릭스로 시각화하면 우선순위가 한눈에 보인다.
| 영향도: 낮음 | 영향도: 중간 | 영향도: 높음 | |
|---|---|---|---|
| 가능성: 높음 | 중간 | 높음 | 매우 높음 |
| 가능성: 중간 | 낮음 | 중간 | 높음 |
| 가능성: 낮음 | 매우 낮음 | 낮음 | 중간 |
예: 신규로 개발된 결제 모듈(가능성 높음 — 새 코드, 영향도 높음 — 매출 직결) → 매우 높음. 반면 안정적으로 운영되던 다국어 설정 화면(가능성 낮음, 영향도 낮음) → 매우 낮음.
리스크 수준에 따라 테스트 깊이를 다르게 한다
| 리스크 수준 | 테스트 접근 |
|---|---|
| 매우 높음 | 여러 기법을 조합, 여러 테스트 레벨(모듈 1), 탐색적 테스팅까지 동원 |
| 높음~중간 | 핵심 기법(동등분할·경계값 등) 위주로 견고하게 |
| 낮음~매우 낮음 | 스모크 테스트 수준(정말 기본 동작만 확인)으로 최소화 |
이게 "왜 어떤 기능은 꼼꼼히 보고 어떤 기능은 대충 보는가"에 대한 답이다 — 대충 보는 게 아니라, 리스크에 비례해 노력을 배분한 것이다.
리스크를 식별하는 방법
혼자 판단하지 않는다. 팀 브레인스토밍, 과거 결함 이력(이 영역에서 결함이 자주 났었는가), 코드 복잡도, 최근 변경 빈도, 그리고 이해관계자에게 "이 기능이 잘못되면 가장 걱정되는 게 뭔가요?"라고 직접 묻는 것도 좋은 리스크 식별 방법이다.
실무에서 왜 필요한가
시간은 항상 부족하다. RBT가 없으면 "익숙한 것부터", "쉬운 것부터", 혹은 그냥 "요구사항 문서에 적힌 순서대로" 테스트하게 되기 쉬운데, 이건 리스크와 아무 상관이 없다. 반대로 RBT를 명시적으로 적용하면, 릴리즈가 촉박해서 일부를 못 보고 넘어가야 할 때도 **"가장 리스크가 낮은 부분을 남겼다"**고 근거 있게 말할 수 있다. 이건 이후 레슨(종료 조건, Go/No-Go)의 판단 근거가 그대로 된다.
실습 과제
과제 1 — 리스크 매트릭스 채우기 (15분)
다음 4개 기능을 리스크 매트릭스(위 표)의 어느 칸에 놓을지 정하고 이유를 한 줄씩 적는다.
- 신규 출시하는 "1:1 실시간 채팅" 기능
- 3년째 안정적으로 운영 중인 "회사 소개" 정적 페이지
- 최근 결제 정책이 변경되어 로직을 새로 짠 "환불 처리"
- 가끔 쓰이는 "다크모드 전환" 설정
과제 2 — 노력 배분 정하기 (10분)
과제 1의 리스크 수준에 따라, 각 기능에 어느 정도의 테스트 깊이(위 표의 세 수준 중 하나)를 배정할지 정하고 근거를 적는다.
자가 체크리스트
- 리스크를 "발생 가능성 × 영향도"로 계산할 수 있다
- 3×3 리스크 매트릭스에 기능을 배치할 수 있다
- 리스크 수준에 따라 테스트 깊이를 다르게 배분하는 이유를 설명할 수 있다
- 리스크를 혼자 판단하지 않고 식별하는 방법(과거 이력, 복잡도, 이해관계자 질문)을 안다
흔한 실수
- 리스크 평가를 혼자, 즉흥적으로 한다. 팀 전체의 판단과 과거 데이터를 반영하지 않으면 개인적 편향이 섞이기 쉽다.
- 낮은 리스크 영역을 아예 테스트하지 않는다. RBT는 "안 본다"가 아니라 "얕게 본다"는 것이다. 스모크 테스트 수준이라도 최소한의 확인은 남긴다.
- 리스크 평가를 한 번 하고 끝낸다. 개발이 진행되며 새로운 정보(예: 예상보다 복잡한 것으로 드러난 로직)가 생기면 리스크 평가도 갱신해야 한다.
참고 자료
- ISTQB Foundation Level Syllabus — Risk-Based Testing — RBT의 공식 정의와 절차
- ISO/IEC/IEEE 29119-1 — 리스크 기반 접근의 표준 프레임워크 (모듈 8에서 상세히)