시스템 검수, Validation

고객이 사인하는 항목은 뭔가

Validation 항목이다. 현업이 업무 시나리오로 원하는 결과가 나오는지 본다.

고객이 사인하는 칸에 단위 시험 케이스 300개를 올려 두면 검수는 안 끝난다. 현업은 그 300개를 읽을 시간도, 읽을 이유도 없다.

사인 항목은 업무 시나리오다. 월말 정산을 이 화면에서 이 권한으로 돌리면 이 숫자가 나온다는 문장.

그 문장의 목록이 검증(Validation)이다. 목록 수는 화면 수보다 적다.

적어야 한다. 시나리오가 40개인 시스템이 시험 케이스 800개를 가지는 것은 정상이다.

800개에 사인을 받는 것은 정상이 아니다. 800개는 엔지니어 검토분이다.

엔지니어가 닫는 항목은 뭔가

Verification이다. 명세·설계·코드가 서로 맞는지, 시험을 돌렸는지다.

엔지니어 검토는 스펙 대로인가를 본다. 요구 ID와 시험 케이스가 이어지는지, 비기능 수치가 측정됐는지, 결함 조치가 닫혔는지.

QA vs QC로 말하면 QC가 산출물을 재고, QA가 그 재는 방식이 빠지지 않았는지 본다. 이 검토를 고객 검수 자리에 들고 가면, 자리는 기술 설명회가 된다.

설명회는 사인이 아니다. 사인은 시나리오 합격이다.

두 회의를 같은 시간에 열지 않는다. 엔지니어 검토를 먼저 닫고, 그다음 주에 고객 시나리오를 연다.

순서가 바뀌면 현업 앞에서 단위 결함을 고치게 된다.

비기능이 검수에서 터지는 이유

기능 목록에는 있는데 수치와 측정 방법이 없다. 느리다, 불편다는 사후 감정이다.

검수 분쟁의 상당수는 기능 없음이 아니라 품질이다. 조회가 된다.

다만 3초가 아니라 12초다. 로그인이 된다.

다만 동시 접속에서 풀린다. 착수 때 비기능을 문장으로만 적어 두면, 검수 때 측정 방법이 없어 감정으로 싸운다.

응답시간, 동시 사용자, 장애 허용, 권한 오류 메시지를 숫자와 측정 도구로 남긴다. 숫자가 없는 비기능은 요구가 아니라 희망이다.

희망을 검수 항목에 올리면 양쪽 다 못 이긴다.

검수 조서에 빼먹기 쉬운 세 줄

제외 범위, 잔존 결함 처리, 운영 이관 조건. 이 세 줄이 없으면 사인은 끝이 아니다.

합격 항목만 있는 조서는 반쪽이다. 이번 오픈에서 빼기로 한 범위, 남은 결함을 며칠 안에 어떤 절차로 닫을지, 운영 인계가 되기 위한 조건.

세 줄이 없으면 사인 다음날 빠진 기능이 다시 검수 항목이 된다. 변경관리로 이미 운영 이관하기로 한 요구가 조서에 안 적히면, 현업은 그 요구를 아직 범위로 본다.

조서 첨부에 이관 목록을 넣는다. 넣는 순간 그 목록은 다음 사업의 입구가 되고, 이번 사인의 출구가 된다.

검수를 착수 주에 설계하는 법

시나리오 초안을 요구 검증 마일스톤에 붙인다. 오픈 주에 시험 설계를 시작하지 않는다.

오픈 2주 전 검수 시나리오를 만들기 시작하면 이미 늦다. 시나리오 초안은 요구 검증이 끝나는 주에 현업과 같이 적는다.

그 초안이 개발 중 데모의 대본이 된다. 데모마다 시나리오가 바뀌면, 바뀐 줄을 변경으로 남긴다.

남기지 않으면 검수 날의 시나리오는 착수 때와 다른 문서가 된다. 다른 문서로 사인을 받으려 하면 그거 요청한 적 없다는 말이 다시 나온다.

같은 문서의 버전만 올린다.