PR diff에서 리스크 읽어내기: 변경 범위로 테스트 우선순위 정하기

개념

변경된 코드가 곧 리스크 지도다

모듈 4(레슨 2)에서 배운 위험기반 테스트(Risk-Based Testing)를 떠올려보자 — 발생 가능성과 영향도가 큰 곳에 테스트 리소스를 집중하는 전략이었다. PR diff(레슨 7)를 읽으면, 이번 변경으로 새로 생긴 리스크가 어디에 있는지를 구체적으로 짚어낼 수 있다.

Diff를 읽을 때 던지는 질문들

1. 무엇이 바뀌었는가?

조건문의 경계값이 바뀌었는가, 새로운 분기가 추가됐는가, 함수의 입력·출력 형식이 바뀌었는가 — 레슨 1의 코드 읽기 능력이 여기서 쓰인다.

2. 이 변경이 영향을 주는 범위는 어디까지인가?

이 함수를 호출하는 다른 곳이 있는가? 변경된 함수가 여러 화면에서 공유되는 코드라면, 그 화면들 전부가 회귀 테스트 대상이 된다.

3. 테스트 코드도 함께 바뀌었는가?

PR에 테스트 코드 변경이 없는데 로직만 바뀌었다면, 그 변경을 검증하는 자동 테스트가 없다는 뜻일 수 있다 — 수동 테스트로 더 꼼꼼히 확인해야 할 신호다.

사례로 읽어보기

  function isEligibleForFreeShipping(cartTotal, memberLevel) {
    if (memberLevel === "VIP") {
      return true
    }
-   if (cartTotal >= 30000) {
+   if (cartTotal >= 50000) {
      return true
    }
    return false
  }

이 diff 하나만 보고도 다음을 읽어낼 수 있다.

• 무엇이 바뀌었나: 무료배송 기준 금액이 30,000원에서 50,000원으로 상향됐다
• 리스크는 어디에 있나: 경계값이 바뀌었으니, 정확히 50000, 49999, 50001에서의 동작(모듈 3의 경계값 분석과 연결)을 반드시 재확인해야 한다
• 영향 범위는 어디까지인가: 이 함수가 장바구니 페이지·주문 확인 페이지·이메일 안내 문구 등 여러 곳에서 쓰인다면, 그 모든 곳에 새 기준(50,000원)이 일관되게 반영됐는지 확인해야 한다(모듈 5 레슨 7의 데이터 따라가기)

변경 크기와 리스크는 비례하지 않는다

"한 줄만 바뀐 변경"이 가장 위험한 경우도 많다. 위 예시처럼 숫자 하나(30000 → 50000)만 바뀐 diff는 코드량은 작아도, 그 숫자가 쓰이는 모든 곳에 영향을 준다. 반대로 파일 수백 줄이 바뀐 diff라도, 그게 로그 문구 정리 같은 낮은 리스크 변경이면 회귀 테스트 부담이 크지 않을 수 있다. diff의 줄 수가 아니라, 그 변경이 무엇을 건드리는가로 리스크를 판단해야 한다.

실무에서 왜 필요한가

릴리스 직전에 "이번에 뭘 테스트해야 하죠?"라는 질문에 "전체 다 해야죠"라고 답하면 시간이 부족하다. PR diff를 읽고 리스크가 높은 변경(경계값 수정, 여러 곳에서 공유되는 함수 수정, 테스트 코드 없는 변경)을 짚어낼 수 있으면, 제한된 시간 안에서 가장 중요한 곳에 테스트를 집중할 수 있다 — 이건 모듈 4의 위험기반 테스트를 "코드 diff"라는 구체적인 근거 위에서 실천하는 것이다.

실습 과제

과제 1 — Diff에서 리스크 짚어내기 (15분)

다음 diff를 읽고, 어떤 리스크가 생겼는지, 어떤 경계값을 재확인해야 하는지, 영향 범위를 확인하려면 무엇을 물어봐야 할지 적는다.

  function calculatePoints(purchaseAmount) {
-   return Math.floor(purchaseAmount / 1000)
+   return Math.floor(purchaseAmount / 1000) * 2
  }

과제 2 — 테스트 우선순위 정하기 (10분)

한 PR에 다음 세 변경이 함께 포함되어 있다고 하자. 회귀 테스트 시간이 부족하다면 어느 순서로 테스트할지 우선순위를 정하고 이유를 적는다.

1. 로그 메시지의 오탈자 수정
2. 결제 금액 계산 함수의 반올림 로직 변경
3. 관리자 페이지 버튼 색상 변경

자가 체크리스트

• PR diff를 읽을 때 던져야 할 세 가지 질문을 설명할 수 있다
• 경계값이 바뀐 diff에서 어떤 테스트를 우선해야 하는지 판단할 수 있다
• 변경 줄 수와 실제 리스크가 비례하지 않는 이유를 예시로 설명할 수 있다
• diff를 읽고 위험기반 테스트(모듈 4)의 우선순위를 정할 수 있다

흔한 실수

• diff의 줄 수만 보고 리스크 크기를 판단한다. 한 줄짜리 숫자 변경이 수백 줄 리팩터링보다 위험할 수 있다.
• 변경된 함수가 다른 곳에서도 쓰이는지 확인하지 않는다. 공유 함수의 변경은 영향 범위가 생각보다 훨씬 넓을 수 있다.
• 테스트 코드가 diff에 포함됐는지 확인하지 않는다. 테스트 코드 없이 로직만 바뀐 변경은 수동 검증이 더 중요해진다.

참고 자료

• Google Engineering Practices — Code Review 가이드 — 변경 검토 시 무엇을 봐야 하는지에 대한 실무 가이드
• ISTQB — Risk-Based Testing 관련 자료(모듈 4 레슨 2 참고 자료와 동일)