리스크 기반 테스트

리스크 기반 테스트(risk-based testing)는 모든 것을 테스트할 수는 없다는 사실을 받아들이고, 리스크를 기준으로 시간을 어디에 쓸지 결정하는 방식입니다. 각 기능이나 영역에 대해 장애 발생 가능성(복잡도, 변경량, 과거 결함, 새로운 기술)과 장애 시 영향도(금전, 안전, 데이터, 법적 리스크, 사용자 수)를 점수로 매깁니다. 고위험 영역은 더 일찍, 더 깊게, 더 다양한 방식으로 테스트하고, 저위험 영역은 가볍게 확인합니다.

예시

한 릴리스가 네 영역에 영향을 줍니다. 각각을 1~5점으로 평가합니다.

영역	가능성	영향도	리스크 (L x I)	테스트 깊이
결제 대행사 이전	5	5	25	기능, 네거티브, 통합, 성능, 탐색적 테스트 전부
특정 지역의 새 세금 규칙	4	4	16	경계값 및 결정 테이블 테스트, 합계 회귀 테스트
프로필 페이지 리디자인	3	2	6	주요 흐름과 시각적 확인
푸터 링크 수정	1	1	1	간단한 확인

마감이 이틀 앞당겨져도 무엇을 뺄지 이미 알고 있습니다. 결제 이전이 아니라 저위험 항목의 테스트 깊이를 줄이면 됩니다.

왜 중요한가

모든 테스트 계획에는 트레이드오프가 있습니다. 리스크 기반 테스트는 이를 명시적으로 만들고 합의하게 합니다. 또한 진행 상황을 명확하게 보고할 수 있게 해 줍니다. “테스트 케이스 83% 실행”보다 “고위험 영역은 모두 테스트 완료, 중위험 두 건은 부분 테스트, 다음과 같은 알려진 공백이 남아 있음”이 릴리스 결정에 훨씬 유용합니다.

흔한 실수

• 혼자서 점수 매기기. 영향도는 프로덕트 오너가, 발생 가능성은 개발자가 잘 압니다. 리스크는 함께 평가해야 합니다.
• 한 번만 점수 매기기. 코드가 반영되고 버그가 나타나면서 리스크는 변합니다. 결함이 계속 나오는 모듈은 순위를 올려야 합니다.
• 저위험 영역을 완전히 무시하기. 리스크가 낮다는 것은 가볍게 테스트한다는 뜻이지, 테스트하지 않는다는 뜻이 아닙니다. 이 기본 영역은 보통 자동화된 회귀 테스트가 커버합니다.
• 버그 심각도와 혼동하기. 심각도는 이미 발견된 결함을 평가하는 것입니다. 리스크는 테스트 전에 세우는 추정치로, 어디를 살펴볼지 결정하는 데 씁니다.