인수 테스트(UAT)는 SI 업체가 내는 마지막 보고서가 아니라 스폰서의 결정입니다. 누구도 대신 판단할 수 없는 질문에 답합니다. 현업이 실제 업무 사례와 자기 권한, 자기 데이터로 납품된 시스템을 쓰며 일할 수 있습니까? SI 업체의 테스트는 시스템이 명세대로 동작한다는 사실을 입증합니다. 그 수준이면 오픈해도 되는지는 인수 테스트가 판단합니다. 그래서 시나리오는 현업에서 나오고, 기준과 심각도 등급은 첫 테스트 전에 정하며, 스폰서는 보고받은 내용이 아니라 직접 본 결과에 서명합니다.
허용 한도를 넘는 할인 요청이 좋은 예입니다. SI 업체는 승인 규칙이 작동하고, 상태가 바뀌고, 알림이 발송되는 과정을 보여 줍니다. 테스트 결과는 통과이고, 틀린 판정도 아닙니다. 인수 테스트에서는 다른 질문을 던집니다. 관리자 계정이 아니라 자기 프로필로 로그인한 영업 담당자가 기회(Opportunity) 레코드에서 요청을 제출할 수 있습니까? 결재권자가 자리를 비웠을 때 대결자가 그 요청을 볼 수 있습니까? 경영관리팀이 월말 리포트에서 할인 사유를 찾을 수 있습니까? SI 업체의 테스트가 모두 통과해도 이 질문은 하나하나 실패할 수 있습니다.
SI 업체가 이미 테스트했는데 인수 테스트는 왜 필요합니까?
두 테스트가 답하는 질문은 서로 다릅니다. SI 업체는 자기 납품물을 검증합니다. 규칙, 필드, 자동화 하나하나가 명세대로 동작하는지, 연동이 올바른 메시지를 주고받는지, 수정 패치가 잘 되던 기능을 깨뜨리지 않는지 확인합니다. 꼭 필요한 일이고, SI 업체가 맡을 일입니다. 다만 이 테스트는 명세에서 출발합니다. 명세가 어떤 사례를 빠뜨렸다면 테스트도 그 사례를 빠뜨린 채 통과합니다.
인수 테스트는 반대쪽 끝, 곧 실제 업무에서 출발합니다. 규칙이 동작하는지가 아니라 팀이 하루 업무를 해낼 수 있는지를 묻습니다. 한 단계에서 다음 단계로 넘어가는 흐름, 예외 상황, 사용자 집단마다 다르게 보이는 접근 권한, 의사결정이 기대는 리포트를 시험합니다. 업무가 시스템에 의존하기 전에 현업이 시스템을 자기 업무에 직접 맞대어 볼 기회는 이때뿐입니다.
더 단순한 이유도 있습니다. SI 업체는 납품하고 대가를 받습니다. 테스트 보고서는 쓸모 있고 대개 꼼꼼하지만, 이해관계가 걸린 당사자가 만든 문서입니다. SI 업체에게 인수 판정을 맡기면 자기 답안지를 스스로 채점하게 하는 셈입니다. 스폰서는 이 보고서를 인수 테스트에 들어가기 위한 조건으로 읽습니다.
시나리오는 누가 쓰고 누가 수행합니까?
둘 다 현업입니다. 팀마다 핵심 사용자가 자기 프로세스를 바탕으로 시나리오를 씁니다. 시나리오 하나가 업무 흐름 하나를 처음부터 끝까지 다룹니다. 첫 접촉에서 청구서까지, 사례(Case) 접수에서 종료까지 이어지며, 골치 아픈 사례도 넣습니다. 중복 고객, 승인 후 취소된 주문, 자리를 비운 결재권자, 기존 시스템에서 이관한 레코드 같은 사례입니다. 시나리오마다 실행 전에 적어 둔 기대 결과와 수행자 이름이 붙습니다.
핵심 사용자는 실제 사용자의 프로필과 Permission Set(권한 집합)으로, 대표성 있는 데이터를 적재한 sandbox(테스트 환경)에서 시나리오를 직접 수행합니다. 관리자 계정으로 수행한 시나리오로는 권한 설정을 전혀 검증할 수 없습니다. 테스트 레코드 몇 건으로 수행한 시나리오로는 이관 데이터의 품질을 전혀 검증할 수 없습니다. 인수 테스트는 데이터 마이그레이션 리허설 위에서 진행합니다.
SI 업체는 다른 역할을 맡습니다. 환경을 준비하고, 계정을 만들고, 데이터를 적재하고, 시스템에 막힌 테스터를 풀어 주고, 결함을 분석하고, 수정 패치를 납품합니다. 계약 범위를 벗어나는 부분이 있으면 시나리오를 검토해 알려 줍니다. 시나리오를 쓰지도, 수행하지도 않습니다. 흔한 함정은 선의에서 나온 제안입니다. “테스트 케이스가 이미 있으니 현업은 다시 돌리기만 하면 됩니다.” 이 케이스는 시스템을 만든 쪽이 썼습니다. 구조상 통과할 수밖에 없고, 빠진 사례는 프로덕션에서 드러납니다.
그러려면 핵심 사용자가 인수 테스트를 시작하기 전에 시간을 비우고 교육을 마쳐야 합니다. 화면을 처음 보는 테스터는 결함과 조작 실수를 구별하지 못합니다. 그래서 교육 계획은 인수 테스트 일정에 맞추고, 테스터의 시간은 착수 단계부터 소속 팀장에게 요청해 확보합니다.
첫 테스트 전에 무엇을 정해야 합니까?
기준과 심각도 등급은 첫 결함이 나오기 전에 정하고 서명합니다.
진입 기준부터 정합니다. 환경 동결, 데이터 적재, 올바른 권한을 준 계정 생성, SI 업체의 테스트 보고서 제출, 테스터 교육 완료입니다. 하나라도 빠지면 인수 테스트를 시작하지 않습니다. 아직 바뀌는 환경에서 시작한 인수 테스트는 전날 들어간 배포만 측정합니다.
심각도 등급에는 등급마다 정의 하나와 현업 프로세스에서 가져온 예시 하나를 붙입니다. 차단: 프로세스가 멈추고, 받아들일 만한 우회 방법이 없습니다. 중대: 우회 방법은 있지만 시간이 들거나, 위험을 만들거나, 한 사람에게만 기댑니다. 경미: 결과에는 영향이 없는 불편입니다. 외관: 레이블이나 화면 배치 문제입니다. 현업이 이 기준표로 심각도를 판정하고, SI 업체는 기술 의견을 내며, 이견은 티켓마다 협상하지 않고 스폰서에게 올립니다.
종료 기준은 이렇습니다. 핵심 시나리오 전부 통과, 열린 차단 결함 없음, 열린 중대 결함마다 문서로 남긴 우회 방법과 담당자와 기한, 현업이 받아들인 이월 경미 결함 목록입니다.
미리 정하는 이유는 테스트가 시작되면 심각도 하나하나가 협상 대상이 되기 때문입니다. 대금 지급이나 오픈 날짜가 차단 결함 수에 달려 있으면, 차단 결함마다 중대로 내려갈 이유가 생깁니다. 이해관계가 걸리기 전에 서명한 기준표가 이런 논쟁을 시작 전에 정리합니다. 이 기준표는 계약서와 같은 내용을 담아야 합니다. 인수 테스트의 내용과 효력은 SI 업체를 고르기 전에 정해 두어야 하며, 계약과 어긋나는 기준표는 첫 이견에서 무너집니다.
스폰서는 무엇에 서명하고, 무엇에는 말만 믿고 서명하지 않습니까?
스폰서는 인수 확인서에 서명하며, 이 문서에는 구체적인 내용이 들어갑니다. 테스트 범위와 납품 버전, 수행한 시나리오와 결과, 심각도와 담당자와 기한을 적은 미해결 결함, 조건 사항, 그리고 결정입니다. 결정은 승인, 조건부 승인, 거부 가운데 하나입니다. 조건부 승인도 그 자체로 완결된 결정입니다. 조건 사항마다 담당자와 기한이 있고, 기한을 넘겼을 때의 결과가 문서로 적혀 있습니다.
스폰서는 직접 본 결과에 서명합니다. 빠지면 회사가 오픈하지 않을 핵심 시나리오의 수행 현장에 참석하고, 성공률 대신 시나리오별 결과를 읽습니다. 성공률이 높아도 정말 중요한 실패 하나가 그 뒤에 숨어 있을 수 있습니다.
남의 말만 믿고는 서명하지 않습니다. SI 업체의 테스트만 보고 하는 “테스트는 모두 통과했습니다”, 목록도 현업 의견도 없이 하는 “남은 결함은 경미합니다”, 담당자도 기한도 없이 하는 “오픈 후에 고치겠습니다”가 그렇습니다. 진행 중에 줄였으면서 인수 확인서에는 적지 않은 범위 축소도 마찬가지입니다. 다음 차수에 넣겠다는 기능은 결정에 아무 영향을 주지 못합니다. 스폰서는 sandbox에서 실제로 돌아가는 기능에 서명합니다.
서명 전에는 이 서명이 계약상 무엇을 일으키는지 서면으로 묻습니다. 대금 지급 마일스톤, 하자 보증 기간의 시작, SI 업체 인력의 프로젝트 철수 같은 효과입니다. 대금을 풀고 보증 기간을 시작시키는 서명은 일정을 지키려고 내주지 않습니다.
인수 테스트를 통과하지 못하면 어떻게 합니까?
거부도 예정된 결과 가운데 하나이며, 인수 테스트가 제 역할을 했다는 뜻입니다. 남은 선택지 가운데 무엇을 고르든 결정해서 문서로 남깁니다. 오픈을 미룰 수 있습니다. 새 날짜는 SI 업체의 일정이 아니라 차단 결함 수정에 맞춥니다. 실패한 프로세스를 빼고 오픈 범위를 줄일 수도 있습니다. 이때 빠진 프로세스에는 별도 인수 테스트 일정을 잡습니다. 남은 차이가 우회 방법이 있는 중대 결함뿐이라면 조건부 승인도 가능합니다.
스폰서가 스스로 금하는 선택도 있습니다. 하자 보증이 차단 결함을 흡수하리라 믿고 그대로 오픈하는 일입니다. 프로덕션 수정은 사용자의 압박 속에서, sandbox라는 안전망 없이 이루어집니다. 그리고 오픈 후 첫 몇 주가 팀이 시스템을 어떻게 볼지 정합니다.
새 인수 테스트 주기에서는 수정 패치가 건드린 시나리오를 다시 수행한 뒤, 핵심 시나리오를 처음부터 끝까지 다시 수행합니다. 한 단계를 고친 패치가 다른 단계를 깨뜨리는 일이 있고, 그런 문제는 처음부터 끝까지 이어지는 시나리오에서만 드러납니다.