출시 전 QA 검수 서비스 이용 안내서

외부 검수를 붙일지 말지보다 먼저 정해지는 것은 시점입니다. 검수는 릴리스 후보 빌드가 나온 뒤에 시작합니다. 기능이 아직 붙고 있는 빌드를 넘기면 실행한 시나리오가 다음 빌드에서 무효가 되고 그 재실행 비용은 그대로 일정에 얹힙니다. 그래서 역산의 첫 칸은 코드 동결일입니다. 검수 시작일은 후보 빌드와 접근 준비 상태를 보고 합의합니다. 기본 검증은 5영업일이며 결함 수정과 합의된 수정분의 재테스트, 출시 승인 시간을 별도로 배치합니다. 남은 기간이 짧으면 핵심 흐름과 제외 범위, 수정 가능한 시간을 함께 정해 결과를 반영할 일정을 확보합니다. 계약과 접근 권한 발급에도 며칠이 듭니다. 사내망 계정, 테스트 환경, 결제나 외부 연동의 샌드박스 키는 요청한 날 나오지 않는 경우가 많습니다. 출시일이 잡히는 순간 검수 착수일을 같이 잡아 두면 이 구간이 일정 밖으로 밀려나지 않습니다. 반대로 출시일이 아직 없다면 검수를 서두를 이유도 없습니다. 범위를 넓게 잡아 회귀까지 다루는 편이 낫고 그것은 이 서비스가 아니라 기간형 계약이 맡는 일입니다. 출시가 한 번으로 끝나지 않는 제품에서도 판단이 같습니다. 스프린트마다 나가는 빌드를 단발 검수로 받으면 착수 절차가 매번 반복돼 값이 실행량보다 빨리 늘어납니다. 단발 검수가 맞는 자리는 일정이 정해진 큰 릴리스, 납품 직전의 독립 검수, 그리고 그동안 검증 없이 쌓아 온 제품을 한 번 세워 보는 시점입니다.

내부 QA 조직이 있는 팀도 개발과 분리된 관점에서 검증 근거를 추가하려고 외부 검수를 붙입니다. 내부와 외부의 결과 모두 합의된 기준과 재현 가능한 증빙이 필요합니다. 납품을 받는 조직은 개발사의 결과를 검수 요구사항과 대조하고 독립된 재확인이 필요한 범위를 정합니다. 내부 팀과의 분담은 착수 전에 문서로 가릅니다. 내부가 계속 맡을 영역과 넘기는 영역을 나누고 결함 심각도 잣대와 보고 양식은 하나로 통일합니다. 같은 결함을 두고 두 조직이 다른 등급을 매기면 출시 회의에서 근거가 아니라 등급이 논쟁거리가 됩니다. 내부가 기능 회귀를 계속 돌고 외부가 릴리스 후보만 보는 분담이 가장 흔합니다. 반대로 전담 담당자가 아예 없는 팀은 판정 잣대부터 함께 정하게 됩니다. 무엇이 출시를 막는 결함인지가 정해지지 않은 상태에서는 결과표가 나와도 회의가 같은 자리를 돕니다.

검수가 시작되려면 세 가지가 있어야 합니다. 첫째는 릴리스 후보 빌드와 그것이 도는 환경입니다. 접속 경로와 계정, 시험용 데이터, 초기화 방법까지 함께 넘깁니다. 둘째는 핵심 흐름 지정입니다. 이 제품에서 깨지면 출시를 미룰 흐름이 무엇인지 발주 쪽이 골라 줍니다. 가입과 결제, 주문 완료처럼 돈과 신뢰가 걸린 경로가 대체로 먼저 옵니다. 셋째는 판단 재료입니다. 요구사항 문서나 화면 설계가 있으면 그대로 받고 없으면 화면에서 거꾸로 요구사항을 복원하는 시간이 범위에 들어갑니다. 문서가 없다고 검수를 못 하지는 않지만 같은 값으로 볼 수 있는 폭이 줄어듭니다. 이전 릴리스의 결함 이력과 최근에 손댄 영역 목록도 받으면 우선순위가 달라집니다. 최근 변경분과 과거에 자주 깨진 자리는 실행 순서를 앞으로 당깁니다. 생성형 도구로 빠르게 만든 제품이라면 이 재료가 특히 중요합니다. 코드를 만든 쪽이 예외 경로를 설명하지 못하는 상태에서는 요구사항에 적히지 않은 조건부터 훑게 되고 그 작업이 실행 시간의 상당 부분을 차지합니다. 준비물이 늦게 도착하면 검증 기간이 아니라 대기 기간이 늘어납니다. 착수일 전에 접근 권한이 실제로 열리는지 한 번 확인해 두는 편이 일정을 지키는 가장 싼 방법입니다.

다섯 개 숫자가 값과 일정을 함께 가릅니다. 대상 빌드 개수, 제품 영역 개수, 핵심 흐름 개수, 합의된 시나리오 개수, 재테스트 횟수. 가장 좁은 구성은 빌드 하나와 제품 영역 한 곳에서 핵심 흐름 하나와 시나리오 열 개를 보고 재테스트를 두지 않는 형태입니다. 기본 구성은 5영업일 동안 빌드 하나와 제품 영역 한 곳에서 핵심 흐름 셋과 시나리오 서른 개를 실행하고 합의된 수정분을 한 차례 재테스트합니다. 넓은 구성은 제품 영역 두 곳과 핵심 흐름 다섯, 시나리오 쉰 개까지 올라갑니다. 이 다섯 숫자와 금액을 착수 전에 서면으로 확정하기 때문에 검증이 길어질수록 비용이 늘어나는 구조가 아닙니다. 제외 범위도 같은 문서에 적습니다. 보안 인증이나 컴플라이언스 적합성은 판정하지 않고 코드 품질을 평가하지도 않습니다. 검수라는 이름으로 기대되지만 실제로는 다른 일인 항목을 앞에서 잘라 두어야 종료 시점에 다툼이 생기지 않습니다. 성능과 부하, 장애 복구 검증도 여기서 갈립니다. 부하 모델을 만드는 준비가 실행보다 큰 별개의 일이라 같은 값 안에 넣지 않습니다.

검수가 끝나면 세 가지가 남습니다. 첫째는 테스트 케이스와 시나리오 자산입니다. 핵심 흐름 안에서 무엇을 어떤 조건으로 확인했는지가 문서로 남아 다음 릴리스에서 그대로 다시 돕니다. 둘째는 결함 대장입니다. 발견한 결함마다 심각도와 재현 조건, 걸린 흐름이 붙습니다. 셋째가 릴리스 판정 메모입니다. 시나리오별 결과와 확인하지 못한 영역, 남은 리스크를 한 장에 담고 READY·READY WITH CONDITIONS·HOLD 가운데 하나로 판정합니다. 판정에는 사람이 서명합니다. 검증 결과와 제외 범위, 전제와 잔여 리스크를 검토한 뒤 신민규 CTO가 릴리스 메모에 서명합니다. READY WITH CONDITIONS면 무엇이 충족되어야 출시인지를, HOLD면 무엇이 갖춰지면 다시 판단하는지를 같은 칸에 함께 적습니다. 확인하지 못한 영역은 반드시 판정과 같은 장에 둡니다. 검증하지 않은 자리를 적지 않으면 통과율이 실제보다 넓게 읽힙니다.

검수는 결과표를 받는 일이 아니라 판정을 받는 일입니다. 통과 건수와 실패 건수만 넘어오면 그 숫자를 읽어 출시를 결정하는 몫이 발주 조직으로 되돌아옵니다. 그래서 제안서에서 확인할 것이 셋입니다. 첫째, 판정 어휘가 문서에 미리 정의돼 있는가. READY·READY WITH CONDITIONS·HOLD처럼 값이 고정돼야 회의에서 해석이 갈리지 않습니다. 둘째, 확인하지 못한 영역이 결과와 같은 문서에 적히는가. 셋째, 누가 서명하는가. 서명자의 이력과 그 사람이 프로젝트를 실제로 읽는지를 물어보면 판정을 파는 곳과 실행만 파는 곳이 갈라집니다. 견적을 비교할 때는 범위 다섯 숫자가 적혀 있는지부터 봅니다. 기간과 인원만 있고 다섯 숫자가 비어 있다면 그 값은 아직 견적이 아니라 예상입니다. 되물어 숫자를 받고 나면 후보들 사이의 값 차이 대부분이 실력 차가 아니라 범위 차였다는 것이 드러납니다. 재테스트 포함 여부와 자산 인계 조건도 같은 자리에서 확인합니다. 실행한 시나리오와 결함 대장이 문서 파일과 원본 데이터로 함께 넘어오지 않으면 다음 릴리스에서 같은 값을 다시 씁니다.

검증 기간을 물으면 대개 이 다섯 숫자로 답합니다. 그러나 같은 다섯 숫자에서도 기간이 벌어지는 변수가 넷 있습니다. 첫째는 환경 조합의 수입니다. 브라우저와 운영체제, 단말과 앱 버전이 곱으로 늘어나면 시나리오 하나가 여러 번 실행됩니다. 금융이나 공공처럼 지원 조합이 넓게 잡힌 제품에서 기간이 가장 크게 벌어집니다. 둘째는 결함 밀도입니다. 결함이 많이 나오면 재현 조건을 좁히고 기록하는 시간이 실행 시간을 넘어섭니다. 셋째는 사전 조건을 만드는 비용입니다. 계정과 상품, 주문 같은 상태를 매번 손으로 만들어야 하는 제품은 같은 시나리오도 더 오래 걸립니다. 넷째는 수정 반영 속도입니다. 재테스트는 개발이 고쳐 다시 올린 뒤에야 시작합니다. 출시일이 촉박하다면 흐름 수를 줄이는 것보다 제품 영역을 하나로 좁히는 편이 낫습니다. 영역을 좁히면 사전 조건과 환경 조합이 함께 줄어 실행 밀도가 올라가고 좁혀서 보지 않기로 한 영역은 다음 릴리스 검수의 첫 후보로 남습니다.