일정·리소스 산정과 테스트 종료 조건

개념

테스트 계획에서 QA가 가장 답하기 곤란해하는 두 질문이 있다. "얼마나 걸려요?" 와 "다 끝난 거예요?" 다. 앞의 질문은 시작 전에, 뒤의 질문은 끝날 무렵에 온다. 그리고 둘 다 감으로 답하면 반드시 사고가 난다 — 앞은 일정이 터지고, 뒤는 "충분한가"를 두고 매번 같은 논쟁이 반복된다.

이 레슨은 두 질문에 근거를 가지고 답하는 방법을 다룬다. 정확한 답을 내는 방법이 아니다 — 산정은 원래 빗나가고 "충분함"은 원래 증명되지 않는다. 대신 근거를 미리 적어두면 빗나갔을 때도 대화가 가능해진다.

일정과 리소스는 대략이라도 근거를 남긴다

정교한 산정 공식이 없어도, 아래 세 가지 근거를 조합하면 현실적인 추정이 된다.

• 과거 유사 작업과 비교: "지난번 비슷한 규모의 기능은 테스트에 3일 걸렸다"
• 전문가 판단: 그 영역을 잘 아는 사람의 직관적 추정
• 작업을 잘게 쪼개서 더하기: 레벨별(모듈 1)·기법별(모듈 3)로 나눠 각각 예상 시간을 매기고 합산

세 방법을 하나만 쓰기보다 교차 검증하면 더 신뢰할 수 있는 추정이 나온다. 레슨 2(리스크)와 레슨 3(규모)에서 정한 우선순위가 여기서 그대로 쓰인다 — 리소스가 부족하면 낮은 우선순위부터 줄인다.

공수를 산정하는 세 가지 실제 기법

위의 세 근거를 실무에서 쓰는 형태로 구체화하면 아래 세 기법이 된다. 이번 릴리즈가 "포인트 적립·사용 기능 추가" 라고 가정하고 각각을 적용해보자.

1) 유사 프로젝트 비교 — 과거 릴리즈 실적에서 끌어온다

가장 먼저 손이 가야 하는 방법이다. 이미 일어난 일보다 좋은 근거는 없다.

포인트 기능이 화면 4개·API 5개 규모라면 쿠폰 기능과 가장 비슷하니 기준선은 6일이다. 4일이 아니라 6일이라는 점이 중요하다 — 비교의 대상은 과거의 계획이 아니라 과거의 실적 이어야 한다.

마지막 줄이 현실에서 가장 큰 함정이다. 기억은 실제 소요를 짧게 왜곡한다. 지금 진행 중인 릴리즈의 실제 소요 시간을 적어두는 것이 다음 산정의 정확도를 결정한다. 산정 능력은 재능이 아니라 기록의 누적 이다.

2) 테스트 케이스 수 기반 환산

모듈 3에서 배운 설계 기법으로 케이스를 먼저 뽑고, 개수에 단가를 곱한다. 계획 시점에 케이스가 다 나와 있지 않아도 기능당 예상 케이스 수로 근사할 수 있다.

여기서 나온 2.2인일은 1회 실행 기준 순수 실행 시간 이다. 설계 시간, 환경 준비, 결함 리포팅, 재테스트가 전부 빠져 있다. 이 숫자를 그대로 일정에 넣으면 100% 터진다 — 뒤에서 다룰 재작업 계수를 곱해야 비로소 쓸 수 있다.

세 번째 줄이 자주 무너진다. "포인트 만료 배치"처럼 조건을 만드는 데만 30분 걸리는 케이스는 5분짜리 케이스 여섯 개보다 훨씬 비싸다. 그래서 위 표에서도 만료·소멸 배치만 케이스당 12분으로 다르게 잡았다.

3) 3점 산정 — 낙관·비관·최빈으로 기대값 내기

하나의 숫자를 말하는 대신 세 개의 숫자를 말한다.

• 낙관치(O): 모든 게 잘 풀렸을 때. 빌드가 한 번에 올라오고, 막히는 결함이 없을 때
• 최빈치(M): 평소대로 갔을 때. 가장 그럴듯한 값
• 비관치(P): 꼬였을 때. 환경이 하루 죽거나, 핵심 결함이 늦게 나올 때

세 값을 아래 식으로 하나의 기대값으로 합친다(PERT 방식).

기대값 E = (O + 4M + P) / 6
표준편차 σ = (P − O) / 6

포인트 기능에 적용하면 이렇게 된다.

최빈치만 더하면 6일인데 기대값은 6.8일이다. 비관 쪽 꼬리가 낙관 쪽보다 길기 때문 이다. 테스트에서는 항상 그렇다 — 예상보다 빨리 끝나는 폭은 제한적이지만(할 일이 정해져 있다), 늦어지는 폭은 사실상 무제한이다(결함이 몇 개 나올지 아무도 모른다).

3점 산정의 진짜 가치는 숫자가 아니라 대화 방식 에 있다. "6일 걸립니다"는 반박이 나오지만, "잘 풀리면 4일, 평소면 6일, 꼬이면 12일이고 기대값은 7일입니다"는 반박 대신 질문이 나온다 — "뭐가 꼬이면 12일이 되나요?" 그 질문이 나오는 순간, 리스크 논의가 시작된 것이다.

세 기법은 하나를 고르는 게 아니라 교차 검증하는 것이다

세 기법을 같은 릴리즈에 다 적용하면 이런 그림이 나온다.

세 숫자가 비슷하게 모이면 신뢰도가 올라간다. 하나가 크게 튀면 그 자체가 신호다 — "TC 환산으로는 2일인데 과거 실적은 6일"이라면 실행 외의 무언가가 4일을 먹었다는 뜻이다. 답은 대개 다음 절에 있다.

산정이 항상 빗나가는 이유 — 테스트는 1회 실행으로 끝나지 않는다

초보 QA의 산정이 무너지는 지점은 거의 항상 같다. 테스트 케이스를 한 번씩 실행하는 시간만 계산한다. 실제 릴리즈에서 벌어지는 일은 이렇다.

1차 실행 → 결함 12건 발견 → 리포팅 → 개발 수정 대기
        → 수정 빌드 배포 → 재테스트(수정된 12건)
        → 확인 테스트 주변 회귀 → 2건 재발 → 다시 리포팅
        → 수정 빌드 → 재테스트 …

같은 케이스를 두 번, 세 번 실행하게 되는 것이 정상 이다. 모듈 1에서 배운 확인 테스트(재테스트)와 회귀 테스트가 여기에 그대로 시간으로 나타난다.

아래 세 줄이 특히 중요하다. 대기 시간은 QA가 일을 못 해서 생기는 게 아니라, 여러 사람이 얽힌 프로세스라서 생긴다. 그래서 개인의 숙련도로 줄어들지 않고, 산정에서 빼면 반드시 일정이 밀린다.

버퍼는 "여유"가 아니라 "예측 가능한 재작업"이다

여기서 QA가 자주 겪는 좌절이 있다. "혹시 모르니 2일 더 주세요"라고 하면 "근거가 뭔데요?"가 돌아오고, 결국 버퍼가 깎인다. "여유"라는 단어를 쓰는 순간 그건 협상 가능한 항목이 된다.

그래서 버퍼를 여유가 아니라 거의 확실히 발생할 재작업 으로 계산해서 제시한다. 이렇게 하면 근거가 생긴다.

계산의 뼈대는 단순하다.

총 테스트 기간 = 1차 실행 시간
               + (예상 결함 수 × 건당 재작업 시간)
               + 빌드 사이클 대기 시간
               + 환경·데이터 준비 시간

예상 결함 수는 과거 결함 밀도에서 나온다. "우리 팀은 비슷한 규모 기능에서 보통 12~18건이 나왔다"는 기록이 있으면, 버퍼는 감이 아니라 산술이 된다. 레슨 2에서 만든 리스크 평가도 여기 쓰인다 — 리스크가 높은 영역은 결함이 더 많이 나올 것으로 보고 재작업 계수를 크게 잡는다.

한 줄로 요약하면: 버퍼를 깎으려는 사람과 싸우지 말고, 버퍼라고 부르지 않으면 된다. 그것은 재테스트 시간이고, 재테스트는 선택 사항이 아니다.

테스트 종료 조건 (Exit Criteria)

"테스트가 끝났다"를 언제 선언할지 미리 정해두지 않으면, 매번 "이 정도면 된 걸까요?"라는 주관적 논쟁이 반복된다. 모듈 1(레슨 5)에서 배웠듯 "버그가 0건"은 종료 조건이 될 수 없다 — 증명 불가능하기 때문이다. 대신 아래처럼 관찰 가능하고 합의 가능한 조건을 쓴다.

예시 종료 조건

• 계획된 테스트 케이스의 95% 이상 실행 완료
• 심각도 "높음" 이상 결함이 모두 수정·재확인됨
• 심각도 "중간" 이하 결함은 목록화되고 이해관계자가 리스크를 인지함
• 계획했던 커버리지 목표(예: 핵심 기능 100%, 부가 기능 스모크 수준)를 달성함
• 남은 리스크(테스트 못 한 영역)가 문서로 정리되어 있음

이 조건들은 전부 "충족됐는지 아닌지 판단 가능" 하다 — 모듈 2(레슨 2)에서 배운 "테스트 가능한 요구사항"의 조건을 종료 조건에도 그대로 적용한 것이다.

종료 조건을 측정 가능하게 쓰는 법

모듈 2(레슨 2)에서 배운 원칙 하나가 여기서 그대로 되살아난다. "검증할 수 없는 문장은 요구사항이 아니다." 종료 조건도 똑같다. 검증할 수 없는 종료 조건은 종료 조건이 아니라 희망 사항이다.

판정 가능한 문장인지 확인하는 방법은 간단하다. "제3자가 이 문장만 보고 충족 여부를 O/X로 표시할 수 있는가?" 를 물어본다.

좋은 예의 공통점은 세 가지다.

1. 숫자가 있다 — 95%, 0건, 1.5초처럼 비교 가능한 값
2. 대상 범위가 정해져 있다 — "핵심 시나리오", "리스크 매우 높음 12개"처럼 무엇에 대한 조건인지가 특정된다
3. 판정 시점에 확인할 수 있는 산출물이 있다 — 실행 결과, 결함 목록, 승인 기록

특히 두 번째가 자주 빠진다. "TC 95% 실행"만 있으면 못 돈 5%가 하필 결제 흐름일 수도 있다. 그래서 실무에서는 거의 항상 두 줄을 짝지어 쓴다.

• 계획된 테스트 케이스의 95% 이상 실행 완료
• 단, 리스크 "높음" 이상으로 분류된 시나리오는 100% 실행 완료

레슨 2의 리스크 등급과 레슨 3의 커버리지 계획이 없으면 두 번째 줄을 쓸 수 없다. 종료 조건이 측정 가능해지는 것은 앞선 레슨들의 결과물이 있기 때문이다.

종료 조건은 두 방향을 막는다

• 끝없는 테스트를 막는다: "이 정도면 충분하다"는 합의된 기준이 있으면, "혹시 모르니 더 보자"는 무한 루프에 빠지지 않는다.
• 성급한 중단을 막는다: 반대로 일정에 쫓겨 "일단 릴리즈부터 하자"고 할 때도, 종료 조건 미충족을 근거로 "아직 안 된다"고 명확히 말할 수 있다.

일정이 밀릴 때 무엇을 줄이는가 — 세 개의 레버

산정을 아무리 잘해도 일정은 밀린다. 개발이 3일 늦게 끝나면 테스트 기간이 그만큼 잘린다. 이때 QA가 조정할 수 있는 레버는 정확히 세 개 뿐이다.

세 개 중 하나는 반드시 움직인다. 아무것도 안 움직이면 실제로 일어나는 일은 "깊이가 조용히 줄어드는 것"이다. 아무도 결정하지 않았는데 결과적으로 테스트가 얕아진다. 그게 가장 나쁜 경우다 — 누구도 무엇을 잃었는지 모르기 때문 이다.

레슨 2에서 리스크 기반으로 우선순위를 이미 잡아뒀다면 이 대화는 훨씬 쉬워진다.

"테스트 시간이 없다"는 통보에 데이터로 답하기

실무에서 이 문장은 질문이 아니라 통보로 온다. "내일 배포해야 해서 오늘 안에 봐주세요." 여기서 감정으로 답하면("이건 말이 안 됩니다") 대화가 끝나고, 그냥 수용하면 리스크가 조용히 넘어간다. 둘 다 나쁘다.

QA의 답변은 거절도 수용도 아닌 제3의 형태 여야 한다.

"하루면 리스크 '매우 높음'으로 분류한 결제·포인트 차감 흐름의 핵심 시나리오 30건은 돌릴 수 있습니다. 대신 회귀 스위트 240건과 만료 배치는 못 봅니다. 만료 배치는 지난 릴리즈에서 결함이 2건 나왔던 영역입니다. 이 상태로 나가면 종료 조건 3번(회귀 Pass율)은 미충족으로 기록됩니다. 진행할지는 결정해주시면 그대로 따르겠습니다."

이 답변의 구조를 뜯어보면 네 조각이다.

모듈 2의 요구사항 리뷰에서 배운 "결정권은 넘기되 리스크는 명시한다"와 정확히 같은 구조다. 그리고 이 대화가 다음 레슨(Go/No-Go)의 예행연습이기도 하다.

감정 대신 데이터를 쓰라는 말의 실제 의미는 "화내지 말라"가 아니다. 화를 낼 필요가 없어지는 상태를 미리 만들어두라는 뜻이다. 리스크 등급, 과거 결함 이력, 케이스 수, 종료 조건이 문서로 있으면 그 자리에서 근거가 나온다. 없으면 아무리 침착해도 "제 느낌엔 위험합니다"밖에 말할 수 없다.

종료 조건을 못 채웠을 때 무엇을 하는가

가장 중요한 절이다. 실무에서 종료 조건은 자주 미충족 상태로 끝난다. 그럴 때 QA가 할 일은 두 가지 중 하나가 아니다 — 그냥 통과시키는 것도, 혼자 막아서는 것도 답이 아니다.

절차는 이렇다.

1. 미충족 항목을 조건 번호로 특정한다. "테스트가 덜 됐다"가 아니라 "종료 조건 2번과 4번이 미충족"이라고 적는다.
2. 미충족의 정도를 수치로 적는다. "TC 90% 실행(목표 95%)", "심각도 High 미해결 1건".
3. 각 미충족 항목의 잔존 리스크를 서술한다. 못 본 영역에서 결함이 나면 무슨 일이 벌어지는지. 여기서 레슨 2의 영향도 평가를 재사용한다.
4. 선택지를 제시한다. "하루 더 주면 2번은 충족 가능", "4번은 개발 수정이 필요해 QA만으로는 해소 불가" 같은 식으로.
5. 결정과 승인자를 기록에 남긴다. 조건부로 나가기로 했다면 누가 그 리스크를 받아들였는지 가 문서에 남아야 한다.

문서 형태로는 이런 표 한 장이면 충분하다.

이 표가 곧 다음 레슨(Go/No-Go)의 입력이다. QA는 이 표를 만들어 테이블에 올리는 사람이고, "그래도 나가자"를 결정하는 사람은 아니다. 반대로 이 표 없이 회의에 들어가면, QA의 의견은 근거 없는 반대로 취급된다.

5번(승인 기록)을 빠뜨리는 실수가 특히 잦다. 구두로 "괜찮다"고 한 결정은 사고가 난 뒤에 아무도 기억하지 못한다. 책임 회피가 목적이 아니라, 다음 릴리즈에서 같은 판단을 반복하지 않기 위한 기록 이다.

실무에서 왜 필요한가

종료 조건이 없으면 "테스트 다 끝났나요?"라는 질문에 답이 사람마다 다르다. QA는 "아직 몇 개 남았다"고 생각하는데 PM은 "이미 충분히 됐다"고 생각하는 상황이 실무에서 자주 벌어진다. 종료 조건을 미리 문서로 합의해두면 이 논쟁이 사실 확인으로 끝난다 — "종료 조건 3번(심각도 높음 결함 0건)이 아직 안 됐으니 완료가 아닙니다"처럼. 이건 다음 레슨(Go/No-Go)의 판단 근거로 그대로 이어진다.

첫째, 산정 근거가 QA의 협상력이다. "얼마나 걸려요?"에 숫자만 답하면 그 숫자는 깎인다. 근거를 붙여 답하면 깎으려는 쪽이 무엇을 포기해야 하는지 알게 된다. 산정은 일정을 맞히는 기술이 아니라 무엇을 잃는지 보이게 만드는 기술 이다.

둘째, 종료 조건은 QA를 "반대하는 사람"에서 "기준을 제시하는 사람"으로 바꾼다. 조건이 없으면 릴리즈 직전의 QA 의견은 개인의 불안으로 들린다. 조건이 있으면 같은 말이 계약 위반 통보처럼 들린다 — 둘의 무게는 완전히 다르다.

셋째, 면접에서 자주 나온다. "테스트를 언제 끝내야 한다고 판단하나요?", "일정이 부족할 때 어떻게 대응했나요?"는 경력 QA 면접의 단골 질문이다. "최선을 다해 봅니다" 같은 답은 감점이고, 종료 조건과 리스크 기반 축소라는 두 단어가 들어간 답은 계획 경험이 있다는 신호로 읽힌다.

실습 과제

과제 1 — 모호한 종료 조건을 측정 가능하게 고쳐 쓰기 (15분)

아래는 실제 계획서에서 흔히 보이는 종료 조건이다. 각각을 제3자가 O/X로 판정할 수 있는 문장으로 고쳐 쓴다. 필요하면 한 줄을 두 줄로 쪼개도 된다.

1. 주요 기능이 모두 정상 동작한다
2. 심각한 결함이 남아있지 않다
3. 회귀 테스트를 수행한다
4. 성능에 이상이 없다
5. 팀이 릴리즈해도 된다고 판단한다

과제 2 — 세 기법으로 공수 산정하기 (20분)

"장바구니에 상품 옵션 변경 기능 추가" 릴리즈를 산정한다. 주어진 정보는 아래와 같다.

• 화면 3개 수정, 신규 API 4개
• 과거 유사 릴리즈("배송지 관리 개선", 화면 3개·API 4개)는 계획 3일 / 실제 4일
• 예상 테스트 케이스: 신규 90건(평균 5분), 회귀 60건(평균 4분)
• 팀의 과거 결함 밀도: 유사 규모에서 평균 12건. 건당 재테스트+주변 회귀 40분
• 빌드는 하루 1회 저녁에 배포된다

세 기법(유사 비교 / TC 환산 / 3점 산정)을 각각 적용해 숫자를 내고, 세 숫자가 어긋나면 왜 어긋나는지 한 문장으로 설명한다. 마지막으로 버퍼를 "재작업"이라는 이름으로 계산해 최종 일정을 제시한다.

과제 3 — 종료 조건으로 판단하기 (10분)

다음 상황에서 과제 1에서 고쳐 쓴 종료 조건(또는 본문의 예시 종료 조건)을 기준으로 "테스트 종료를 선언할 수 있는가"를 판단한다.

계획된 테스트 케이스의 90%를 실행했고, 심각도 "높음" 결함이 1건 미해결 상태로 남아있다. 심각도 "중간" 결함 3건은 목록화되어 공유됐다.

단순히 "안 된다"로 끝내지 말고, 본문의 미충족 보고 표(종료 조건 / 목표 / 현재 / 충족 / 잔존 리스크) 형식으로 정리한 뒤, 마지막에 선택지 두 개를 제시한다.

과제 4 — "오늘 안에 끝내주세요"에 답하기 (10분)

과제 2의 릴리즈(산정 4~5일)에 대해 PM이 이렇게 말했다고 하자.

"내일 오전에 배포해야 합니다. 오늘 하루 안에 봐주세요."

본문의 네 조각 구조(할 수 있는 것 / 못 하는 것 / 위험 근거 / 결정권 넘기기)를 써서 답변을 작성한다. 답변에 숫자가 최소 세 개 들어가야 한다.

자가 체크리스트

• 일정·리소스를 추정하는 세 가지 근거(과거 비교, 전문가 판단, 작업 분해)를 설명할 수 있다
• 테스트 케이스 수 기반 환산으로 1차 실행 시간을 계산할 수 있다
• 3점 산정(낙관·최빈·비관)으로 기대값을 내고, 그 숫자로 불확실성을 설명할 수 있다
• 테스트가 1회 실행으로 끝나지 않는 이유(재테스트·주변 회귀)를 설명할 수 있다
• 빌드 대기·환경 문제·데이터 준비 같은 대기 시간을 산정에 포함시킨다
• 버퍼를 "여유"가 아니라 "예상 결함 수 × 건당 재작업 시간"으로 근거 있게 요청할 수 있다
• "버그 없음"이 왜 종료 조건이 될 수 없는지 설명할 수 있다
• 모호한 종료 조건을 판정 가능한 문장(수치·범위·산출물)으로 고쳐 쓸 수 있다
• "TC 95% 실행"에 "핵심 시나리오 100%"를 짝지어 써야 하는 이유를 안다
• 일정이 밀릴 때 범위·깊이·일정 세 레버 중 무엇을 움직일지 판단할 수 있다
• "테스트 시간이 없다"는 통보에 네 조각 구조(가능·불가능·근거·결정권)로 답할 수 있다
• 종료 조건 미충족 시 미충족 항목과 잔존 리스크를 표로 정리해 의사결정자에게 넘길 수 있다

흔한 실수

• 테스트 케이스를 한 번씩 실행하는 시간만 산정한다. 결함이 나오면 재테스트와 주변 회귀가 반드시 따라붙는다. 1차 실행 시간은 전체의 절반도 안 되는 경우가 많다.
• 대기 시간을 산정에서 뺀다. 빌드가 하루 1회 올라오면 결함 사이클 한 바퀴에 하루가 든다. QA가 아무리 빨라도 줄일 수 없는 시간이다.
• 버퍼를 "여유"라고 부른다. 여유는 협상 대상이 되어 제일 먼저 깎인다. "과거 결함 12건 × 재작업 40분 = 8시간"처럼 재작업으로 계산해서 제시한다.
• 실적을 기록하지 않는다. 기록이 없으면 다음 산정도 감이다. 계획 대비 실제를 릴리즈마다 한 줄씩 남기는 것만으로 산정 정확도가 올라간다.
• 종료 조건을 테스트가 다 끝난 뒤에 사후적으로 정한다. 종료 조건은 계획 단계에서 미리 합의해야 의미가 있다. 나중에 정하면 그때 상황에 맞춰 끼워 맞추게 된다.
• 종료 조건에 애매한 표현을 쓴다. "충분히 테스트됨" 같은 표현은 모듈 2(레슨 2)에서 배운 "테스트 불가능한 요구사항"과 같은 문제를 가진다.
• "회귀 테스트를 수행한다"처럼 수행 자체를 조건으로 쓴다. 전부 실패해도 충족되는 조건이다. 실행량과 합격 기준을 같이 적어야 한다.
• 실행률만 조건으로 쓰고 대상 범위를 안 정한다. 못 돈 5%가 결제 흐름일 수 있다. "핵심 시나리오는 100%"를 항상 짝지어 쓴다.
• 일정이 밀렸는데 아무 레버도 움직이지 않는다. 그러면 깊이가 조용히 줄어든다. 아무도 결정하지 않았는데 테스트만 얕아지는 것이 가장 나쁘다.
• "시간이 없다"는 통보에 감정으로 답하거나 그냥 수용한다. 둘 다 리스크를 기록에 남기지 못한다. 할 수 있는 것과 못 하는 것을 숫자로 나눠 말한다.
• 종료 조건이 충족되지 않았는데도 압박에 밀려 조용히 종료를 선언한다. 이럴 땐 조건 미충족을 명시적으로 기록하고, 남은 리스크를 이해관계자에게 알린 뒤 결정은 다음 레슨의 Go/No-Go 절차로 넘긴다.

참고 자료

• ISTQB Foundation Level Syllabus — Exit Criteria — 테스트 종료 기준의 공식 정의
• ISO/IEC/IEEE 29119-2 — 테스트 관리 프로세스에서 종료 기준을 다루는 부분 (모듈 8에서 상세히)
• ISTQB Glossary — entry criteria / exit criteria — 시작 조건과 종료 조건의 정확한 구분
• Rex Black, Managing the Testing Process — 테스트 공수 산정과 일정 협상을 테스트 매니저 관점에서 다룬 고전
• Steve McConnell, Software Estimation: Demystifying the Black Art — 3점 산정과 "산정은 왜 항상 낙관적인가"의 근거를 다룬다