릴리스 판정 메모·시나리오 결과표 양식

릴리스 판정 메모는 한 장짜리 문서입니다. 맨 위 칸이 대상입니다 — 검증한 빌드와 제품 영역, 검증 기간, 실행한 환경 조합을 적습니다. 둘째 칸이 합의한 범위입니다. 착수 전에 서면으로 정한 핵심 흐름 수와 시나리오 수, 재테스트 횟수를 그대로 옮기고 그 옆에 제외하기로 한 항목을 나란히 둡니다. 셋째 칸이 시나리오별 결과, 넷째 칸이 확인하지 못한 영역, 다섯째 칸이 잔여 리스크, 마지막 칸이 판정과 서명란입니다. 칸 순서는 바꾸지 않습니다. 무엇을 어디까지 봤는지 모르는 채로 판정부터 읽으면 그 판정이 어디까지 유효한지 알 수 없기 때문입니다. 대상 칸의 환경 조합은 브라우저와 운영체제, 단말과 앱 버전처럼 결과가 갈리는 축만 적습니다. 여기 없는 조합에서 나온 현상은 이번 검수의 결과가 아니라 다음 범위의 후보입니다.

시나리오 결과표는 여덟 열입니다. 시나리오 번호, 속한 핵심 흐름, 사전 조건, 실행 절차, 기대 결과, 상태, 연결된 결함 번호, 실행자와 실행 일시입니다. 상태 열에는 네 값만 들어갑니다. PASS는 기대 결과와 일치한 것, FAIL은 어긋난 것, BLOCKED는 앞 단계가 막혀 실행 자체가 불가능했던 것, NOT RUN은 범위 안에 있었으나 실행하지 못한 것입니다. 뒤의 두 값을 FAIL로 묶으면 제품 결함 수가 실제보다 부풀고 PASS 쪽에 섞으면 검증 폭이 실제보다 넓게 읽힙니다. 네 값을 갈라 두면 결과표 한 장이 곧 다음 회차의 실행 목록이 됩니다. 사전 조건과 실행 절차 열은 다른 사람이 같은 결과를 다시 만들어 낼 수 있을 만큼만 적습니다. 계정과 데이터, 진입 화면을 사전 조건에 두고 절차는 번호를 붙인 짧은 문장으로 끊습니다. 결함 번호 열은 결함 대장의 항목과 일대일로 이어져야 합니다. FAIL 행에서 결함 번호를 따라가면 심각도와 재현 조건, 담당과 조치 상태가 나오고 결함 대장에서 거꾸로 오면 그 결함이 어느 흐름에서 걸렸는지가 나옵니다.

넷째 칸에는 범위 밖이라 보지 않은 것과 범위 안이었지만 못 본 것을 나눠 적고 못 본 쪽에는 사유를 한 줄씩 붙입니다. 다섯째 칸의 잔여 리스크는 결함 목록이 아니라 판단 재료입니다. 고치지 않고 내보내기로 한 결함, 재현 조건을 좁히지 못한 현상, 운영 중에 지켜봐야 할 지점을 심각도와 함께 적습니다. 이 두 칸이 비면 통과율만 남습니다. 통과율만으로는 통과하지 못한 몫이 어디에 있는지 알 수 없습니다. 사유는 짧게 씁니다. 환경을 준비하지 못함, 선행 결함으로 막힘, 합의 범위 밖. 세 갈래로 갈라 두면 다음 회차에 무엇을 먼저 풀어야 할지 이 문서만 보고 정합니다.

판정 칸에는 READY·READY WITH CONDITIONS·HOLD 가운데 하나가 들어갑니다. READY WITH CONDITIONS면 무엇이 충족되어야 출시인지, HOLD면 무엇이 갖춰지면 다시 판단하는지를 같은 칸에 함께 적습니다. 출시 회의에서는 이 문서를 읽고 날짜를 확정하거나 미룹니다. 미루면 넷째 칸이 다음 회차의 범위가 됩니다. 시간이 지나 감사나 사고 조사에서 다시 꺼낼 때도 요구사항과 시나리오, 결함과 조치, 승인 기록이 한 줄로 이어집니다. 양식으로 넘길 때 판정 칸과 서명란은 비워 둡니다. 서명은 검증 결과와 제외 범위, 전제와 잔여 리스크를 검토한 사람이 실제 검수 뒤에 넣습니다. 판정을 누가 서명했는지가 남아야 승인이 의견 대결이 아니라 근거 확인으로 끝납니다.