리스크 기반 테스트로 테스트 우선순위 설계하기

테스트 자원을 위험이 큰 곳에 배치하는 방법

품질 예산과 출시 일정이 제한된 상황에서는 모든 기능을 같은 우선순위와 깊이로 검증하기 어렵다. 리스크 기반 테스트(Risk-based Testing, RBT)는 비즈니스 리스크와 기술 리스크를 점수화해, 우선순위가 높은 영역에 테스트 자원을 집중하는 전략이다.

리스크 점수는 다음과 같이 산정한다.

리스크 점수 = 장애발생가능도 × 영향도

영향도에는 금전적 손실, 규제 위반, 고객 이탈, SLA 위반 등을 반영할 수 있다. 발생가능도와 영향도를 낮음부터 높음까지의 행렬로 배치해 High, Medium, Low 등급으로 구분하며, 특히 발생가능도와 영향도가 모두 높은 High-High 영역이 집중 검증 대상이 된다.

계획부터 결과 추적까지 이어지는 흐름

RBT는 테스트 직전에 우선순위를 정하는 작업에 그치지 않는다. 리스크를 발견하고, 대응 계획을 테스트 전략에 반영한 뒤, 실행 결과와 운영 피드백으로 다시 조정하는 순환 과정이다.

리스크 식별 단계에서는 비즈니스 목표, 아키텍처와 컴포넌트 목록, 과거 장애 이력, 규제 요구를 입력으로 삼는다. 발생 가능한 Risk Item을 도출하고 가정과 제약을 명세하며, 이해관계자 인터뷰를 통해 위험관리대장(Risk Register) 초안과 리스크 카탈로그를 만든다.

분석 단계에서는 각 Risk Item의 발생가능도와 영향도를 산정한다. 이를 매트릭스에 배치하고 정량 점수를 계산해 우선순위 목록, 위험·영향 매트릭스, High·Medium·Low 임계치를 정한다.

대응계획에서는 회피, 완화, 전가, 수용 전략을 선택하고 사전 통제와 모니터링 항목을 설정한다. 이 결과는 위험 대응 목록, 품질 게이팅 기준, 에스컬레이션 룰로 이어진다.

테스트 전략은 대응계획, 품질 목표, 자원과 일정을 바탕으로 수립한다. High-High 사분면을 중심으로 커버리지와 테스트 깊이를 정하고, 환경과 데이터 전략을 포함한 Master Test Plan(MTP) 및 리스크 기반 테스트 설계를 만든다.

실행은 H 레벨부터 시작한다. 탐색 테스트와 회귀 테스트의 비율을 조정하고, 발견한 결함에는 영향도를 태깅한다. 테스트 로그, 결함 보고, 커버리지 실적이 이후 판단의 근거가 된다.

마지막으로 실행 결과와 운영 피드백을 반영해 대응 상태를 모니터링하고 점수를 조정한다. 위험관리대장과 리포트를 갱신해 다음 스프린트나 릴리스의 의사결정 자료로 사용한다.

⤢✕

점수와 임계치를 테스트 계획에 연결하기

장애발생가능도가 0.8이고 영향도가 100(백만 원 환산)이라면 리스크 점수는 80이다. 이 기준에서 High는 60 이상, Medium은 30~59, Low는 30 미만으로 구분할 수 있다.

발생가능도와 영향도의 표준 스케일에는 1~5 또는 확률과 금액을 사용할 수 있다. 비즈니스 요인인 매출과 기술 요인인 복잡도를 함께 반영하려면 가중치를 적용한다. 영향도가 금액, 규제 벌점, SLA 위반 시간처럼 여러 지표로 구성될 경우에는 표준화 점수로 변환한 뒤 가중합을 적용한다.

중요 고객이나 핵심 기능은 추가 가중치(+α)를 적용해 과소평가되지 않도록 관리할 수 있다. 이 기준은 팀 간 우선순위 논의를 위한 공통 언어가 되며, MTP에는 리스크 매핑과 커버리지 목표를 명시한다.

위험 유형에 따라 달라지는 테스트 집중 지점

온라인 결제 모듈에서는 결제 실패율 상승과 환불 지연이 주요 위험이 될 수 있다. 영향도가 높고 발생가능도가 중~고인 경우, 승인·취소·부분환불의 경계값에 검증을 집중하고 장애 시 롤백과 멱등성 검증을 강화한다. 출시 전에는 High 사분면 100% 커버리지를 목표로 둔다.

모바일 앱의 대규모 릴리스에서는 상위 디바이스 호환성과 오프라인 동기화 충돌이 위험 항목이다. 상위 점유 20% 디바이스·OS 조합을 우선하고 네트워크 경계 테스트를 확대하며, 크래시 비율은 릴리스+7일 내 40% 감소를 목표로 삼을 수 있다.

데이터 파이프라인과 ETL에서는 스키마 변경에 따른 데이터 손실, SLA 지연이 중요한 위험이다. 스키마 드리프트 감지와 샘플링 검증의 우선순위를 높이고, 백필 시뮬레이션 테스트를 수행한다.

리스크 집중이 만드는 효과와 비용

리스크 기반 접근에서는 결함 발견 효율, 즉 결함/테스트케이스가 20~~40% 개선될 수 있다. 고중요 결함(Sev1/Sev2)의 사전 검출율은 30%↑, 테스트 리드타임은 동일 자원 가정에서 15~~35% 단축될 수 있다.

의사결정의 투명성과 재현성이 높아지고, 이해관계자의 판단 기준도 정렬된다. 변경에 대응하는 속도를 높이고 테스트 피로도를 낮추는 효과도 기대할 수 있다.

참고로 수치는 업계 사례 평균치이며, 도메인과 데이터 품질에 따라 변동 가능하다.

점수 체계가 놓치기 쉬운 운영 문제

리스크 기반 테스트를 운영하려면 표준 스케일과 가중치를 먼저 정의하고, 팀이 같은 기준으로 위험을 해석할 수 있어야 한다. 요구사항, 리스크, 테스트, 결함 간의 추적성을 관리도구와 연계해 자동화하고, 스프린트마다 재평가와 임계치 튜닝을 수행한다. 품질 게이팅 기준도 명문화해야 한다.

다만 데이터 수집과 점수화에는 비용이 든다. 그 비용은 테스트 낭비를 줄이는 효과와 맞바꾼다. 고위험 영역에 집중하면 저위험 영역의 잠재 결함을 찾지 못할 수 있지만, 릴리스 리스크를 낮출 수 있다. 정량화에 지나치게 의존하면 맥락을 잃을 위험도 있으므로 전문가 판단에 가중치를 함께 두는 방식이 보완책이 된다.

SQL로 리스크 우선순위 산정하기

전제조건: PostgreSQL 13+ 환경, 테이블 risk_items(likelihood REAL 0~1, impact NUMERIC, area TEXT, owner TEXT)

-- 리스크 점수와 우선순위 등급 산정 예시
WITH scored AS (
  SELECT
    risk_id,
    area,
    owner,
    likelihood,
    impact,
    (likelihood * impact) AS risk_score
  FROM risk_items
)
SELECT
  risk_id,
  area,
  owner,
  risk_score,
  CASE
    WHEN risk_score >= 60 THEN 'HIGH'
    WHEN risk_score >= 30 THEN 'MEDIUM'
    ELSE 'LOW'
  END AS priority_level
FROM scored
ORDER BY priority_level DESC, risk_score DESC;

산정된 HIGH 영역부터 테스트 케이스와 시나리오를 집중 설계·실행한다. 결함 보고에는 priority_level을 태깅해 영향도 기준의 리포팅을 일원화한다.