검증 결과와 릴리스 의견

판단을 도울 수 있는 결과 보고

릴리스 회의에서 열 개 통과라고 말하면 듣는 사람은 서비스가 준비됐다고 오해할 수 있습니다. 이번에 열 개 통과한 대상은 가상 시계 모형이고 실제 UI와 변경 계약 검증은 대기입니다. 품질 의견에는 대상·관찰 사실·해석·권고를 분리해 담습니다. QA는 위험을 구체적으로 설명하고 의사결정자가 선택할 조건을 제시합니다. 팀의 책임 합의 없이 혼자 출시 승인을 대신하지 않습니다.

이번 교육용 의견의 결론은 HOLD입니다. 이것은 앱에 새로운 결함이 발견됐다는 단정이 아닙니다. 권한과 저장 무변경을 이번 대상에서 확인하지 못했으며 실제 UI 증거가 없기 때문에 출시 판단 자료가 부족하다는 뜻입니다. 제품 FAIL과 PENDING을 구분하면 개발자에게 존재가 확인되지 않은 결함을 고치라고 요구하는 실수를 줄일 수 있습니다. 차단 근거는 자료 부족과 예상 사용자 피해를 함께 설명합니다.

진행 권고를 하려면 합의된 핵심 위험의 검증 증거와 남은 제한의 처리 조건이 필요합니다. 성공 건수만 많아도 타인 프로필 노출 같은 위험을 확인하지 않았으면 근거가 부족합니다. 반대로 문구 오탈자 한 건이 실패했다고 모든 제품의 출시를 자동으로 막는 규칙도 적절하지 않습니다. 사용자 영향·범위·복구 가능성·대체 확인을 읽고 팀의 인수 기준과 위험 허용 조건에 맞춰 권고합니다.

서로 다른 상태를 같은 숫자로 합치지 않습니다

결과 집계는 무엇을 분모로 삼았는지 먼저 정합니다. 계획 12건 중 실행 9건이고 그중 성공 8건·실패 1건이라면 실행 성공률은 8/9입니다. 전체 계획 중 성공 비중은 8/12입니다. 두 수치는 다른 질문에 답합니다. 미실행 3건을 성공으로 포함하거나 재시도 성공만 남기면 위험이 줄어든 것처럼 보입니다. 보고서에는 계획·실행·성공·실패·미실행을 같이 적고 숫자 뒤에 검사 층과 계약을 붙입니다.

가상 모형의 buggy 3/10과 fixed 10/10은 결함 검출 비교이며 실제 인수 기준 8개의 완료율이 아닙니다. 두 버전을 합쳐 13/20 성공이라고 쓰면 비교 목적을 잃습니다. 문서 검사 8개 연결이 완료됐다는 수치도 앱 성공 8건이 아닙니다. 최종 보고서는 모형 관찰과 문서 연결 상태를 별도 문장으로 보여 주고 실제 앱·UI가 대기인 항목에는 대기 상태를 유지합니다.

예상과 다른 실제 응답은 FAIL로 적고 실행 환경이 없어 호출하지 못한 검사는 미실행으로 적습니다. 그 상태를 이번 트랙의 최종 추적표에서는 PENDING으로 관리합니다. 상태 이름을 팀마다 다르게 쓰더라도 정의를 붙여야 비교할 수 있습니다. 자동 검사 통과 때문에 PENDING을 없애지 않습니다. 문서 검사기는 미검증 사유가 쓰였는지 확인할 뿐 실제 제품 결과를 만들어 주지 않습니다.

차단 근거와 잔여 위험을 나눕니다

차단 근거 blocking에는 지금 결정하기 어려운 이유를 적습니다. 예시는 변경된 세션 계약에 대한 만료 뒤 권한 거절·저장 무변경 증거 부재입니다. risks에는 그 상태로 진행했을 때 어떤 사용자가 어떤 피해를 볼 가능성이 남는지 적습니다. 타인 프로필 접근이 허용될 수 있다는 위험 문장은 가능성을 말하는 것이며 실제 노출을 관찰했다는 문장과 다릅니다. 표현의 강도를 증거에 맞춥니다.

대체 확인은 원래 검사와 같은 관찰을 제공할 때만 제한된 근거가 됩니다. 합성 모형의 상태 격리 성공은 실제 브라우저 권한 거절을 대신하지 못합니다. 실제 API의 권한 거절과 저장 무변경을 확인했다면 서버 측 위험에 대한 증거가 될 수 있지만 UI의 오류 복구와 키보드 흐름은 여전히 별도입니다. 대체 확인의 대상·제외한 층·실행 시점을 함께 적으면 판단자가 남은 공백을 알 수 있습니다.

이미 알려진 DEF-01·DEF-02는 이전 버전의 관찰 자료입니다. 이번 모듈에서 다시 실행하지 않았으므로 현재 대상의 차단 결함으로 확정하거나 해결됐다고 쓰지 않습니다. facts에 이전 보고서를 상속했다는 사실을 적고 대상 버전 재확인 요구를 next에 둡니다. 같은 증거를 근거로 확정 사실과 추측을 동시에 말하지 않도록 버전과 계약을 표시합니다. 결함의 심각도와 처리 우선순위도 사용자 영향과 일정 판단을 구분합니다.

권고는 다음 행동까지 포함합니다

quality/release.json에는 decision·facts·blocking·risks·owner·next·due·approval을 씁니다. facts는 실제 실행한 모형 비교와 상속한 이전 보고서를 구분하는 문장입니다. owner는 출시 판단 책임자이고 next는 QA가 확보할 실제 앱·브라우저 자료와 재검토 행동입니다. due는 후속 추적 기한이며 승인 시점이 아닙니다. approval은 미승인이라고 적어 QA 의견이 최종 승인으로 오해되지 않게 합니다.

재검토 조건은 성공 출력 한 줄보다 구체적으로 씁니다. 예를 들어 CH-SESSION의 정상·만료 직전·정확한 만료·만료 후·타인 접근 검사를 대상 앱에서 실행하고 권한 거절의 저장 무변경을 확인해야 합니다. 요구사항→인수 기준→검사→실행 경로가 연결된 뒤 책임자가 보류 해제를 논의하도록 정합니다. 이번 과제에서 그 앱 실행을 했다면 별도 자료를 남겨야 하며 제공 모범 답안은 실행 대기를 유지합니다.

현업에서는 출시 범위를 줄이거나 기능을 비활성화하는 선택도 검토할 수 있습니다. 하지만 변경 없이 권한 위험이 사라진다고 가정하지 않습니다. 선택마다 누가 영향을 받고 어떤 확인이 추가로 필요한지 질문합니다. 이 과제의 실행 가능한 선택은 증거 확보 전 보류이며 기능 제한이 실제 적용됐다고 보고하지 않습니다. 제한 조치 제안과 적용 관찰을 구분해야 보고서가 다음 팀의 행동을 잘못 유도하지 않습니다.

자동 검사와 사람 리뷰의 경계를 읽습니다

RELEASE_UNSUPPORTED는 이번 증거 범위와 달리 진행 결론을 쓰거나 차단·위험 근거를 비운 경우의 오류입니다. 결론을 억지로 HOLD로 바꾸는 데서 멈추지 않고 미검증 위험을 읽습니다. PENDING_FIELD는 담당·기한 등 후속 필드가 비었다는 뜻입니다. 값이 있다는 이유로 적절한 담당과 기한이라는 검토가 끝나지 않습니다. 팀원이 실제로 수행할 수 있는 next인지 사람 리뷰가 필요합니다.

릴리스 보고서를 읽은 사람이 단 한 문장으로 결론과 조건을 되말할 수 있도록 씁니다. 예시는 가상 모형 회귀는 확인했으나 변경 앱의 권한·저장 및 실제 UI 증거가 없어 보류하며 QA 증거 확보 후 책임자가 재검토한다는 문장입니다. 이후에 보고서 경로와 세부 관찰을 붙입니다. 전체 프로젝트 파일 목록으로 결론을 숨기지 않고, 확인한 범위와 확인하지 못한 사용자 영향이 판단에 연결되게 합니다.

레슨 제출에서는 계획 집계의 분모와 모형 비교의 분모를 구분하는 표를 직접 작성합니다. 이어서 차단 위험 하나를 골라 관찰 사실과 가능성 문장을 각각 적습니다. 동료가 가능성 문장을 실제 결함 발생으로 오독한다면 표현과 증거 참조를 고칩니다. 다음 모듈이나 팀이 이어받을 때 무엇을 실행해야 보류를 해제할 수 있는지가 보이면 릴리스 의견은 의사결정을 지원하는 문서가 됩니다.