테스트 크기에 따른 커버리지 계획

개념

레슨 2에서 배운 리스크가 "얼마나 깊게 볼 것인가"를 정한다면, 이 레슨은 "변경 규모가 얼마나 넓게 볼 것인가에 영향을 준다" 는 걸 다룬다. 둘은 함께 작동한다.

깊이와 넓이를 나눠서 생각하는 게 이 레슨의 출발점이다. 같은 "테스트를 많이 한다"는 말도 두 방향이 있다. 하나는 한 기능을 파고드는 깊이 — 경계값을 더 촘촘히, 예외 경로를 더 많이 보는 것이다. 다른 하나는 건드리지도 않은 기능까지 훑는 넓이 — 이번에 손대지 않은 로그인, 검색, 마이페이지까지 다시 돌려보는 것이다. 리스크는 깊이를 정하고, 변경 규모는 넓이를 정한다.

규모는 "코드 줄 수"가 아니다

가장 먼저 깨야 할 오해가 있다. 변경 규모를 diff의 줄 수로 재는 습관이다.

규모 = 바뀐 코드의 양이 아니라, 그 변경이 닿는 기능의 수다.

500줄을 고쳤어도 그 500줄이 관리자 화면 한 곳에만 쓰이면 영향 범위는 좁다. 반대로 공통 날짜 포맷 함수의 한 줄을 고치면 그 함수를 쓰는 화면 전부가 영향권이다. 줄 수는 개발 난이도를 재고, 영향 범위는 테스트 범위를 잰다. QA가 봐야 하는 건 뒤쪽이다. 모듈 9 레슨 8("PR diff에서 리스크 읽어내기")에서 "변경 크기와 리스크는 비례하지 않는다"고 배운 것이 계획 단계에서는 이 형태로 나타난다.

변경 유형 다섯 가지와 테스트 범위

실무에서 마주치는 변경을 다섯 가지로 나눠두면 판단이 빨라진다. 앞의 셋은 익숙한 소·중·대규모이고, 뒤의 둘이 사고가 자주 나는 자리다.

마지막 줄이 이 표의 핵심이다. 애플리케이션 코드가 한 줄도 안 바뀌었는데 영향 범위는 가장 넓은 유형 이 존재한다. package.json의 버전 숫자 하나, 서버 설정 파일의 값 하나, DB 인덱스 하나가 시스템 전체의 동작을 바꿀 수 있다. 그런데 PR을 열어보면 diff가 두 줄뿐이라 리뷰도 테스트도 가볍게 지나간다. 이 불일치가 실무 사고의 단골 원인이다.

인프라·라이브러리 변경에서 특히 확인해야 할 것들이다.

규모 × 리스크 매트릭스

레슨 2의 리스크와 이 레슨의 규모를 함께 놓으면 더 정교하게 판단할 수 있다.

예를 들어 "결제 로직 한 줄 수정"은 규모는 작지만 리스크는 높다 — 이 경우 "좁지만 깊게" 본다(관련된 결제 시나리오는 꼼꼼히, 그 외 영역은 안 봐도 됨). 반대로 "다국어 지원 국가를 5개 늘리는" 변경은 규모는 크지만 리스크는 상대적으로 낮을 수 있다 — "넓지만 얕게"(각 언어별로 기본 동작만 확인) 접근이 적절하다.

네 칸 중 실무에서 가장 자주 틀리는 칸은 오른쪽 위 다. 규모가 작으면 반사적으로 "가볍게"라고 판단해버리기 때문이다. 이 칸을 놓치지 않으려면 규모를 먼저 보지 말고 영향 범위를 먼저 확인하는 순서 로 습관을 바꿔야 한다. 그 순서가 다음에 볼 영향 분석이다.

영향 분석 — 변경이 어디까지 닿는지 추적하기

영향 분석(impact analysis)은 거창한 기법이 아니라 "이 변경이 쓰이는 곳을 끝까지 따라가 보는" 절차 다. QA가 개발자 없이 혼자서도 상당 부분 할 수 있다.

2단계가 핵심인데, 방법은 생각보다 단순하다. 바뀐 함수나 컴포넌트의 이름을 그대로 저장소 전체에서 검색 하면 된다. GitHub 검색창이나 에디터의 전체 검색으로 formatPrice 를 찾으면 그 함수를 쓰는 파일이 전부 나온다. 결과가 3개면 좁은 변경이고, 40개면 그 자체로 "이건 공통 코드다"라는 신호다. 모듈 9 레슨 7에서 배운 Git·PR 구조와 레슨 8의 diff 읽기가 여기서 계획 문서로 이어진다.

diff에서 영향 범위를 읽는 신호 를 정리하면 이렇다.

마지막 줄은 코드 변경이 아니라 사람에 대한 신호다. 기존 테스트가 실패해서 지웠다면, 그 실패가 바로 이번 변경의 부작용일 수 있다.

개발자에게 물어보는 것도 영향 분석이다. 코드를 다 읽을 수 없을 때 가장 효율적인 질문은 "이 변경이 영향 주는 다른 기능이 있나요?"가 아니라 더 구체적인 형태다 — "이 함수 쓰는 데가 여기 말고 또 있나요?", "API 응답 형태가 바뀌면 앱도 같이 배포해야 하나요?", "이 설정, 스테이징이랑 운영이 값이 다른가요?" 답이 "아마 없을 거예요"면 그건 확인이 아니라 추측이므로, 범위에 넣어두는 편이 안전하다.

스모크·새니티·회귀 — 셋은 다른 것이다

세 용어를 섞어 쓰는 팀이 많은데, 목적도 시점도 범위도 다르다.

스모크의 실패는 다른 둘과 성격이 다르다. 스모크가 깨지면 결함 하나를 보고하고 넘어가는 게 아니라 그날의 테스트 자체를 멈춘다. 로그인이 안 되는 빌드에서 결제 테스트를 진행하는 건 시간 낭비이기 때문이다. 이 "중단 권한"이 스모크 테스트를 별도로 정의해두는 실질적인 이유다.

새니티는 회귀의 축소판처럼 보이지만 방향이 반대다. 회귀는 "안 건드린 곳"을 보고, 새니티는 "건드린 곳" 을 본다. 모듈 1에서 배운 확인 테스트 (confirmation test)를 그 주변까지 조금 넓힌 것이 새니티라고 이해하면 쉽다.

변경 규모별로 셋을 어떻게 조합하는지가 이 레슨의 실무 결론이다.

인프라 변경 줄을 보자. 고친 기능이 없으니 새니티는 대상이 없는데, 스모크와 회귀는 최대 범위다. "수정한 게 없으니 테스트할 것도 없다"는 판단이 정확히 거꾸로 라는 게 이 줄이 말하는 바다.

"문구만 바꿨는데" 터지는 사고들

작은 변경이 큰 사고가 되는 경로에는 반복되는 패턴이 있다. 미리 알아두면 diff를 볼 때 신호로 잡힌다.

여기서 얻을 결론은 하나다. 작은 변경을 크게 테스트하라는 말이 아니라, 크기가 아니라 영향 범위로 판단하라는 말이다. 위 여덟 줄은 전부 diff가 10줄 미만인 변경들이다.

사례 연구 1 — "오타 수정"이 결제를 멈춘 날

금요일 오후, 개발자가 PR을 하나 올린다. 제목은 "결제 버튼 문구 오타 수정". diff는 두 줄이다. 결제하기 → 결제 하기. QA는 규모가 작다고 판단하고 결제 화면에서 버튼 문구만 확인한 뒤 통과시킨다.

월요일, 앱에서 결제가 안 된다는 문의가 쏟아진다. 원인은 이랬다. 앱의 자동화 테스트와 일부 화면 전환 로직이 버튼 텍스트로 요소를 찾고 있었다. 문구가 바뀌자 앱은 그 버튼을 못 찾았고, 특정 기종에서 결제 화면이 멈췄다.

영향 분석을 했다면 어디서 잡혔을까. 2단계에서 결제하기 라는 문자열을 저장소 전체에서 검색했다면, 웹 화면 코드 외에 앱 저장소와 자동화 스크립트 에서 같은 문자열이 나왔을 것이다. 검색 결과가 한 곳이 아니라는 사실 하나가 "이건 웹만의 문구가 아니다"라는 신호였다.

교훈은 두 가지다. 첫째, 사용자에게 보이는 문자열도 인터페이스 다. 둘째, "문구 변경"이라는 제목을 그대로 규모 판단에 쓰면 안 된다. 제목은 개발자가 자기 관점에서 붙인 것이고, QA는 그 변경이 닿는 곳 을 따로 확인해야 한다.

사례 연구 2 — 숨은 영향을 미리 찾아낸 경우

같은 팀에서 몇 달 뒤. 이번 PR은 "주문 목록 API 응답에 discountAmount 필드 추가"다. 필드를 더하기만 했으니 기존 동작에는 영향이 없어 보인다.

QA가 영향 분석 3단계(데이터 경로 추적)를 돌린다. 이 API를 쓰는 곳을 검색하니 웹 주문 목록 외에 모바일 앱과 정산 배치 가 나왔다. 앱 개발자에게 물으니 구버전 앱이 응답을 엄격하게 파싱해서 모르는 필드가 오면 파싱에 실패 한다는 답이 돌아온다. 배포 전에 발견됐고, 앱 강제 업데이트 대상 버전을 확인해 서버에서 버전별 응답을 분기하는 것으로 정리됐다.

여기서 QA가 한 일은 코드를 깊이 읽은 게 아니다. "이 API를 누가 쓰나"를 검색 한 번으로 확인하고, 답을 아는 사람에게 물어본 것 이 전부다. 영향 분석의 대부분은 이 수준에서 끝난다. 그리고 이 사례처럼 배포 전에 잡히면 비용은 질문 한 번이고, 배포 후에 잡히면 앱 강제 업데이트다.

커버리지 계획을 한 장으로 적기

지금까지의 판단을 릴리즈마다 다시 논쟁하지 않으려면 짧은 문서 하나로 남긴다. 레슨 1의 테스트 계획서 안에 들어가는 실행 단위 문서다.

"제외한 것"과 "남은 리스크" 두 줄이 이 표의 값어치 다. 무엇을 했는지는 누구나 적지만, 무엇을 일부러 안 했는지를 근거와 함께 적어두면 나중에 문제가 생겨도 "판단"이 되고 안 적어두면 "누락"이 된다. 레슨 5의 Go/No-Go 회의에서 그대로 쓰이는 자료이기도 하다.

이 표가 "어디까지 넓게 볼 것인가" 를 정한다면, 레슨 7 은 "각 영역에서 어디까지 깊게 볼 것인가" 를 정한다 — UI 동작부터 정답·권한·접근성·데이터 정합성·비기능·보안까지 7개 계층으로 훑는 체계다. 둘을 함께 쓰면 범위와 깊이가 모두 근거를 갖는다.

실무에서 왜 필요한가

"이번 변경, 얼마나 테스트해야 하나요?"라는 질문에 팀마다 정해진 답이 없으면 매번 같은 논쟁이 반복된다. 규모와 리스크를 기준으로 미리 원칙을 세워두면 ("소규모+저리스크는 확인 테스트만", "대규모+고리스크는 전체 레벨 동원") 이 논쟁이 훨씬 빨리 끝난다. 특히 핫픽스처럼 시간이 촉박한 상황에서, 이 원칙이 없으면 "일단 다 돌려보자"거나 반대로 "시간 없으니 확인만 하자"는 극단으로 치우치기 쉽다.

첫째, 배포 빈도가 높을수록 이 판단이 매일 필요해진다. 한 달에 한 번 배포하던 시절에는 매번 전면 회귀를 돌려도 됐다. 하루에 여러 번 배포하는 팀에서는 불가능하다. 변경마다 범위를 다르게 잡는 능력이 없으면 QA가 배포의 병목이 되고, 그러면 팀은 QA를 우회하기 시작한다.

둘째, 범위를 좁힌 근거를 남기면 QA의 판단이 방어된다. 사고가 났을 때 "왜 못 잡았냐"는 질문은 반드시 나온다. 이때 "영향 범위를 이렇게 판단했고, 이 근거로 이 영역을 제외했다"고 답할 수 있는 것과 "시간이 없어서 못 봤다"고 답하는 것은 완전히 다르다. 전자는 판단의 개선으로 이어지고, 후자는 개인의 책임으로 끝난다. 모듈 3 마지막 레슨에서 배운 설명 가능성 이 릴리즈 범위 차원에서 반복되는 것이다.

셋째, 개발자와 대화하는 언어가 생긴다. "이거 회귀 돌려야 해요"는 협상이 안 되지만, "이 변경이 공통 컴포넌트라 30개 화면에 닿아서 스모크 전면 + 결제 회귀가 필요합니다. 컴포넌트를 새로 만들고 이 화면만 쓰게 하면 범위가 1개로 줄어듭니다"는 협상이 된다. 후자는 개발 방식이 테스트 비용을 바꾼다 는 사실을 눈에 보이게 만든다.

넷째, 산정과 종료 조건의 입력값이 된다. 다음 레슨(레슨 4)에서 일정을 산정할 때, 근거가 되는 것은 "이번에 몇 건을 돌리는가"이고 그 건수는 이 레슨의 범위 판단에서 나온다. 범위를 못 정하면 산정도 못 하고, 산정을 못 하면 종료 조건도 정할 수 없다.

실습 과제

과제 1 — 변경 유형 분류하기 (8분)

다음 다섯 변경을 본문의 다섯 유형(핫픽스 / 마이너 / 메이저 / 신규 모듈 / 인프라·라이브러리)으로 분류하고, 각각 영향 범위를 한 줄씩 적는다.

1. 상품 목록 페이지의 정렬 옵션에 "낮은 가격순"을 추가
2. 버튼 텍스트 오타 수정
3. 회원 등급 체계를 전면 개편(기존 3단계 → 신규 5단계)
4. 이미지 업로드 라이브러리를 2.3.1 → 2.4.0으로 올림
5. 세션 만료 시간을 60분에서 30분으로 변경

과제 2 — 영향 분석 해보기 (12분)

"장바구니 담기 버튼을 공통 컴포넌트로 교체했다"는 PR이 올라왔다고 하자. 본문의 영향 분석 5단계를 순서대로 적용해, 각 단계에서 무엇을 확인할지와 누구에게 무엇을 물을지 를 적는다. 마지막에 회귀 범위를 목록으로 확정한다.

과제 3 — 스모크·새니티·회귀 구분하기 (8분)

아래 다섯 활동이 셋 중 무엇인지 분류하고, 그렇게 판단한 이유를 한 줄씩 적는다.

1. 새 빌드가 올라오자마자 로그인 → 상품 조회 → 결제까지 한 번 훑는다
2. 어제 보고한 결함이 수정됐다고 해서 그 화면을 다시 확인한다
3. 릴리즈 전날, 이번에 손대지 않은 회원가입까지 포함해 200건을 실행한다
4. 결제 모듈을 고쳤다기에 결제 관련 화면 15건을 확인한다
5. 배포 직후 운영 환경에서 핵심 흐름 5건을 확인한다

과제 4 — 규모×리스크로 계획 짜기 (12분)

과제 1의 다섯 변경 각각에 리스크 수준(낮음/중간/높음)을 가정해 붙이고, 본문의 2×2 매트릭스와 조합 표를 참고해 커버리지 접근 한 줄 + 스모크/새니티/회귀 조합을 적는다. 마지막으로 본문의 "커버리지 계획 한 장" 표 형식으로 5번 변경에 대한 계획서를 완성한다. "제외한 것"과 "남은 리스크" 줄을 반드시 채운다.

자가 체크리스트

• 변경 규모가 코드 줄 수가 아니라 영향 범위라는 것을 설명할 수 있다
• 다섯 가지 변경 유형과 각각의 기본 테스트 범위를 말할 수 있다
• 코드가 거의 안 바뀌었는데 영향 범위가 가장 넓은 유형(인프라·라이브러리)을 설명할 수 있다
• 규모와 리스크를 함께 고려해 "좁고 깊게" 대 "넓고 얕게"를 판단할 수 있다
• 영향 분석 5단계를 순서대로 적용해 회귀 범위를 도출할 수 있다
• PR diff의 파일 경로만 보고도 공통 코드·계약 변경·설정 변경을 구분할 수 있다
• 스모크·새니티·회귀의 목적·범위·시점 차이를 설명할 수 있다
• 스모크 실패가 왜 "테스트 중단" 신호인지 설명할 수 있다
• 변경 유형별로 셋을 어떻게 조합할지 정할 수 있다
• 작은 변경이 큰 사고로 이어지는 패턴을 세 가지 이상 들 수 있다
• 커버리지 계획에 "제외한 것"과 "남은 리스크"를 근거와 함께 적을 수 있다
• 규모에 비례하지 않는 테스트가 왜 비효율이자 위험인지 설명할 수 있다

흔한 실수

• 모든 변경에 같은 프로세스를 적용한다. 한 줄짜리 수정과 신규 모듈에 똑같은 체크리스트를 돌리면, 작은 변경은 과잉 테스트로 시간을 낭비하고 큰 변경은 프로세스를 다 못 채운 채 급하게 끝나기 쉽다.
• 규모만 보고 리스크를 무시한다. "작은 변경이니 가볍게"라는 판단이 결제·보안처럼 고리스크 영역에서는 위험하다. 규모와 리스크를 항상 함께 본다.
• diff의 줄 수로 규모를 판단한다. 두 줄짜리 라이브러리 업그레이드가 500줄짜리 관리자 화면 수정보다 영향 범위가 훨씬 넓다. 줄 수가 아니라 닿는 기능의 수 로 판단한다.
• PR 제목을 그대로 믿는다. "오타 수정"은 개발자 관점의 요약이다. 파일 경로와 사용처를 직접 확인하기 전에는 규모를 확정하지 않는다.
• "코드를 안 고쳤으니 테스트할 게 없다"고 판단한다. 설정값·의존성 버전· 인프라 변경은 코드 변경이 없는 대신 영향 범위가 전면이다.
• 스모크와 회귀를 같은 말로 쓴다. 용어가 뭉개지면 "회귀 돌렸어요"가 15건인지 200건인지 알 수 없어 릴리즈 판단의 근거가 되지 못한다.
• 스모크 실패를 결함 하나로 처리하고 테스트를 계속한다. 스모크가 깨진 빌드에서 이어지는 테스트 결과는 대부분 신뢰할 수 없다. 멈추고 반려한다.
• 영향 분석을 개발자에게만 맡긴다. "영향 없어요"라는 답은 개발자가 아는 범위 안에서만 참이다. 사용처 검색 한 번은 QA가 직접 한다.
• 범위에서 뺀 것을 기록하지 않는다. 기록되지 않은 제외는 나중에 누락으로 읽힌다. 안 한 것과 그 근거를 남기는 것이 한 것을 적는 것만큼 중요하다.
• "이번엔 특별히 빨리 해야 하니 다 생략"이라고 규모 판단 없이 뭉뚱그린다. 급할수록 오히려 "무엇을 줄이고 무엇을 남길지"를 규모·리스크 기준으로 명확히 정해야 한다.

참고 자료

• ISTQB Foundation Level Syllabus — Test Estimation Techniques — 변경 규모에 따른 테스트 산정 접근법
• ISTQB Glossary — smoke testing, sanity testing, regression testing, confirmation testing, impact analysis의 공식 정의
• Rex Black, Managing the Testing Process — 리스크와 규모를 함께 고려한 테스트 계획 수립 실무서
• Jez Humble & David Farley, Continuous Delivery — 배포 빈도가 높은 환경에서 회귀 범위를 자동화로 감당하는 방법
• Semantic Versioning — 라이브러리 버전 표기 규칙. 마이너 업그레이드가 왜 "안전하다"는 보장이 아닌지 이해하는 데 필요하다