개념
레슨 2에서 배운 리스크가 "얼마나 깊게 볼 것인가"를 정한다면, 이 레슨은 **"변경 규모가 얼마나 넓게 볼 것인가에 영향을 준다"**는 걸 다룬다. 둘은 함께 작동한다.
변경 규모 세 단계
| 규모 | 예시 | 기본 커버리지 접근 |
|---|---|---|
| 소규모 | 버그 수정 1건 | 확인 테스트(모듈 1) + 그 주변 좁은 범위 회귀 |
| 중규모 | 기존 기능 개선 | 해당 기능 전체 테스트 + 연관 기능 회귀 |
| 대규모 | 신규 모듈, 대대적 리팩토링 | 테스트 레벨 전체(모듈 1)를 동원, 폭넓은 회귀, 여러 설계 기법(모듈 3) 조합 |
"장바구니 수량 표시 오타 수정" 같은 소규모 변경에 신규 모듈 수준의 전체 회귀 테스트를 돌리면 시간 낭비다. 반대로 "결제 모듈 신규 개발" 같은 대규모 변경에 확인 테스트 수준만 하면 리스크가 방치된다. 규모에 비례하지 않는 테스트는 그 자체로 비효율이자 위험이다.
규모 × 리스크 매트릭스
레슨 2의 리스크와 이 레슨의 규모를 함께 놓으면 더 정교하게 판단할 수 있다.
| 리스크 낮음 | 리스크 높음 | |
|---|---|---|
| 규모 작음 | 최소한의 확인만 | 작지만 신중하게 — 좁고 깊게 |
| 규모 큼 | 넓지만 얕게 — 전체 스모크 위주 | 넓고 깊게 — 가장 많은 시간 배정 |
예를 들어 "결제 로직 한 줄 수정"은 규모는 작지만 리스크는 높다 — 이 경우 "좁지만 깊게" 본다(관련된 결제 시나리오는 꼼꼼히, 그 외 영역은 안 봐도 됨). 반대로 "다국어 지원 국가를 5개 늘리는" 변경은 규모는 크지만 리스크는 상대적으로 낮을 수 있다 — "넓지만 얕게"(각 언어별로 기본 동작만 확인) 접근이 적절하다.
실무에서 왜 필요한가
"이번 변경, 얼마나 테스트해야 하나요?"라는 질문에 팀마다 정해진 답이 없으면 매번 같은 논쟁이 반복된다. 규모와 리스크를 기준으로 미리 원칙을 세워두면 ("소규모+저리스크는 확인 테스트만", "대규모+고리스크는 전체 레벨 동원") 이 논쟁이 훨씬 빨리 끝난다. 특히 핫픽스처럼 시간이 촉박한 상황에서, 이 원칙이 없으면 "일단 다 돌려보자"거나 반대로 "시간 없으니 확인만 하자"는 극단으로 치우치기 쉽다.
실습 과제
과제 1 — 규모 분류하기 (8분)
다음 세 변경을 소/중/대규모로 분류한다.
- 상품 목록 페이지의 정렬 옵션에 "낮은 가격순"을 추가
- 버튼 텍스트 오타 수정
- 회원 등급 체계를 전면 개편(기존 3단계 → 신규 5단계)
과제 2 — 규모×리스크로 계획 짜기 (12분)
과제 1의 세 변경 각각에 리스크 수준(낮음/중간/높음)을 임의로 가정해 붙이고, 위 2×2 매트릭스를 참고해 어떤 커버리지 접근("좁고 깊게" 등)을 취할지 한 줄씩 적는다.
자가 체크리스트
- 변경 규모 세 단계(소/중/대)와 각각의 기본 커버리지 접근을 설명할 수 있다
- 규모와 리스크를 함께 고려해 "좁고 깊게" 대 "넓고 얕게"를 판단할 수 있다
- 규모에 비례하지 않는 테스트가 왜 비효율이자 위험인지 설명할 수 있다
- 주어진 변경에 대해 규모와 리스크를 근거로 커버리지 계획을 세울 수 있다
흔한 실수
- 모든 변경에 같은 프로세스를 적용한다. 한 줄짜리 수정과 신규 모듈에 똑같은 체크리스트를 돌리면, 작은 변경은 과잉 테스트로 시간을 낭비하고 큰 변경은 프로세스를 다 못 채운 채 급하게 끝나기 쉽다.
- 규모만 보고 리스크를 무시한다. "작은 변경이니 가볍게"라는 판단이 결제·보안처럼 고리스크 영역에서는 위험하다. 규모와 리스크를 항상 함께 본다.
- "이번엔 특별히 빨리 해야 하니 다 생략"이라고 규모 판단 없이 뭉뚱그린다. 급할수록 오히려 "무엇을 줄이고 무엇을 남길지"를 규모·리스크 기준으로 명확히 정해야 한다.
참고 자료
- ISTQB Foundation Level Syllabus — Test Estimation Techniques — 변경 규모에 따른 테스트 산정 접근법
- Rex Black, Managing the Testing Process — 리스크와 규모를 함께 고려한 테스트 계획 수립 실무서