인수 테스트·UAT — 사용자 참여·ATDD·공공 SI 검수·RFP 인수 기준

학습 목표

이 모듈 한 줄 요약 — "'이제 받겠다' 는 말이 실제로 나오는 자리". 만든 쪽이 아니라 쓸 사람과 돈을 내는 쪽이 "됐다" 고 말하는 마지막 관문이다. 같은 시험을 같은 환경에서 돌려도, 누가 판정하고 무엇을 근거로 남겼느냐에 따라 결과가 달라진다. 그 판정의 자리를 설계하는 법을 다룬다.

모듈 2에서 요구사항을 읽고 인수 기준(Acceptance Criteria)을 쓰는 법을, 모듈 4에서 테스트 계획과 종료 조건을 배웠다. 이 모듈은 그 두 갈래가 만나는 지점 — "이제 받겠다"는 말이 실제로 나오는 자리 — 를 다룬다. 인수 테스트는 기법 목록이 아니다. 같은 케이스를 같은 환경에서 돌려도, 누가 판정하고 무엇을 근거로 남겼느냐에 따라 인수는 되기도 하고 분쟁이 되기도 한다. 그래서 이 모듈의 주제는 도구가 아니라 합의 절차와 증거 다.

네 갈래로 간다. 첫째, UAT 설계 다. 시스템 테스트와 UAT 의 진짜 차이는 범위가 아니라 판정 주체다 — 통과·실패를 실사용자와 발주 측이 선언한다. 그 사람들을 어떻게 고르고, 어떻게 준비시키고, 알파·베타를 어떤 기준으로 열고 닫는지가 UAT 성패의 대부분을 결정한다. 둘째, ATDD 와 예제 기반 명세 다. 인수 기준을 회의 끝에 받아 적는 대신 대화 중에 예제로 만들어 내는 방식이고, Gherkin 문법을 쓰는 일과는 별개의 기술이다. 셋째, 국내 공공 SI 검수 다. 감리와 QA 의 역할 구분, 검수조서에 들어가는 것, 하자보수 기간 동안 품질 증거를 어떻게 살려 두는지를 본다. 넷째, RFP·과업지시서를 인수 케이스로 옮기는 절차 다. "원활하게 동작해야 한다" 같은 문장을 판정 가능한 기준으로 바꾸고, 요구사항 추적표로 계약 범위를 지키는 일이다.

이 모듈을 관통하는 문장은 emphasis 그대로다. 인수는 기술이 아니라 합의와 증거로 끝난다. 테스트를 아무리 잘해도 합의된 기준이 없으면 끝나지 않고, 증거가 남지 않으면 끝난 것이 다시 열린다.

완료 후 할 수 있는 것

• UAT 와 시스템 테스트를 판정 주체·목적·환경·결함 처리 방식 기준으로 구분해 설명하고, 둘을 섞어 쓰는 계획서를 진단할 수 있다
• 업무 역할·숙련도·리스크를 기준으로 UAT 참여자를 선정하고, 시나리오·데이터·교육을 포함한 참여자 준비 패키지를 만들 수 있다
• 알파와 베타의 목적 차이를 설명하고, 모집·기간·피드백 수집 경로·중단(kill) 기준을 포함한 베타 운영 계획을 쓸 수 있다
• 인수 기준을 언제 누구와 합의할지 일정에 고정하고, UAT 중 발견된 항목을 결함과 요구 변경으로 갈라 처리 경로를 지정할 수 있다
• ATDD 의 대화 → 예제 → 자동화 흐름을 설명하고, 예제 기반 명세 워크숍(발견·정제·자동화) 세 단계를 진행할 수 있다
• 좋은 Given-When-Then 과 나쁜 Given-When-Then 을 판정하고, 예제 표(Scenario Outline)로 규칙을 압축해 살아 있는 문서로 만들 수 있다
• 국내 공공 SI 의 검수 흐름과 정보시스템 감리의 위치를 설명하고, 감리 지적사항에 대한 시정 조치 증거를 QA 산출물로 준비할 수 있다
• 검수조서·검사조서에 무엇이 들어가는지 확인하고, 하자보수 기간 중 품질 증거(형상·로그·재현 절차)를 유지하는 규칙을 세울 수 있다
• RFP·과업지시서의 요구사항 문장을 검증 가능한 인수 케이스로 변환하고, 모호한 표현을 측정 조건이 붙은 기준으로 바꿀 수 있다
• RFP 항목 ↔ 인수 케이스 ↔ 증거를 잇는 요구사항 추적표를 만들고, 계약 범위 밖 요구가 들어올 때의 처리 절차를 운용할 수 있다

채용시장에서의 위치

국내 QA 채용에서 인수 테스트 경험은 두 개의 서로 다른 시장 에서 서로 다른 얼굴로 요구된다.

하나는 SI·공공 사업 쪽이다. 공고에 "검수 대응", "감리 대응", "산출물 작성", "과업 이행 증적" 같은 문구가 붙는다. 여기서 찾는 사람은 테스트를 잘하는 사람이 아니라 끝낼 수 있는 사람 이다. 발주처가 요구하는 문서 형식을 알고, 감리 지적사항에 증거로 답하고, 검수 일정 역산으로 테스트 일정을 짤 수 있으면 사업 하나를 책임질 수 있다는 신호가 된다. 이 역량은 경력 5년 차 이후 PL·QA 리드 공고에서 특히 비중이 크고, 모듈 31(시험성적서)·모듈 44(QA 조직·컨설팅)와 묶여 평가된다.

다른 하나는 제품·플랫폼 조직이다. 여기서는 같은 역량이 "인수 기준 정의", "PO 와 요구사항 정제", "ATDD/BDD 경험", "베타 운영" 같은 말로 나타난다. 자동화 도구(Cucumber·SpecFlow·Behave·Playwright) 사용 경험을 묻지만, 면접에서 갈리는 지점은 문법이 아니라 "그 시나리오를 누구와 어떻게 만들었는가" 다. 개발자가 혼자 쓴 Gherkin 파일 300개는 경력이 아니라 유지보수 부채로 읽힌다.

자격증 축에서는 ISTQB CTFL 의 인수 테스트 레벨 정의와 CTFL-AT(Agile Tester)의 ATDD·예제 기반 명세 다루기가 직접 겹치고, CTAL-TA(Test Analyst)는 인수 기준을 테스트 조건으로 분해하는 쪽에서 겹친다. 공공 사업 쪽에서는 정보처리기사·정보시스템감리사 같은 자격이 문서·심사 맥락에서 언급된다. 다만 어느 시장이든 결정적인 것은 자격이 아니라 "이 기준으로 인수가 끝났다"고 말할 수 있는 실제 사례 다. 이 모듈의 실습 과제는 그 사례를 재구성해 두는 용도로 설계했다.