제외 범위와 잔여 위험

선택되지 않은 검사도 품질 의견의 일부입니다

릴리스 검토에서 선택한 검사 열 개가 통과했다고 말해도 어떤 기능을 확인하지 않았는지 빠져 있으면 판단 근거가 부족합니다. 잔여 위험은 검사를 수행한 뒤에도 남아 있는 불확실성과 사용자 피해 가능성입니다. 실행하지 않은 검사, 제한된 환경, 임시 격리와 알려진 결함이 그 출발점입니다. 이번 레슨은 짧은 제출 문서로 그 범위를 다른 담당자에게 전달하는 연습입니다.

시간 제한은 검사를 줄인 이유가 될 수 있지만 사용자 위험을 줄였다는 증거는 아닙니다. 가입 길이와 세션 만료 변경에서 권한 거절을 건너뛰었다면 안내 문구 검사 통과로 대신할 수 없습니다. 우선순위가 높은 위험에 대체 확인이 없으면 품질 의견은 보류가 될 수 있습니다. QA는 관찰 사실과 권고를 제공하고 최종 출시 책임의 합의 위치를 명확히 합니다.

잔여 위험 문서는 보고서를 길게 만드는 작업이 아닙니다. 무엇을 확인하지 않았는지, 어떤 사용자에게 어떤 영향이 가능한지, 대신 확인한 사실이 있는지, 누가 언제 무엇을 해야 종료되는지를 적습니다. 확인하지 못했다는 표현만 있으면 다음 행동이 없습니다. 위험이 낮다는 표현만 있으면 그 판단의 근거가 없습니다. 각각을 구체적 관찰과 연결합니다.

실행 상태를 같은 용어로 씁니다

PASS는 이번 실행의 기대 결과와 관찰값이 일치했다는 상태입니다. FAIL은 검사가 실행되어 불일치를 발견했다는 상태이고 SKIPPED는 실행 절차에서 호출하지 않았다는 상태입니다. DEFERRED는 계획 단계에서 후속으로 미룬 결정입니다. 격리한 검사는 일반 회귀에서 빠져 있어도 실패 원인과 대체 확인이 남아야 합니다. 서로 다른 상태를 성공으로 합산하지 않습니다.

미션 RG 사례는 변경 앱을 아직 실행하지 않은 계획이므로 planned입니다. check-docs.py가 문서 ID와 필수 필드를 검사했다고 RG-08의 실제 만료 접근이 거절되었다고 기록하지 않습니다. 가상 시계 지연 검사와 실제 권한 API 검사는 검증 대상이 다릅니다. 보고서 문장을 쓸 때마다 어떤 입력을 어떤 도구에 넣어 관찰했는지 자문하면 과장된 통과 주장을 줄일 수 있습니다.

앞 모듈의 실제 브라우저 전체 검증은 외부 실행 대기입니다. 이번 미션은 그 상태를 유지하고 m08-check.sh를 보존합니다. 새 check.sh는 서버를 실행하거나 종료하지 않고 합성 분류와 단위 검사, 지연 재현과 문서 구조를 확인합니다. 이전 외부 검증이 남았다는 사실을 새 검사 통과로 덮지 않습니다. 각 결과의 관찰 범위를 따로 전달합니다.

불안정 검사 격리는 임시 결정입니다

불안정한 UI 검사를 주 회귀에서 잠시 분리하는 결정에는 사유, 담당, 기한, 해제 조건이 필요합니다. 다시 실행해 보겠다는 문장만으로는 언제 완료인지 판단할 수 없습니다. 지연 조건별 실제 UI 최초 시도 열 번과 소유 데이터 정리를 확인하고 실패 로그를 유지한다처럼 관찰 가능한 종료 조건을 씁니다. 횟수는 교육용 조건이며 일반적인 안정성 보증 수치는 아닙니다.

자동 재시도는 진단을 위해 추가 시도를 수집하는 데 사용할 수 있지만 첫 실패를 성공으로 바꾸는 근거가 아닙니다. 격리한 검사도 별도 실행에서 실패를 드러낼 수 있어야 합니다. 주 회귀가 초록색이더라도 격리 목록의 사용자 영향을 보고합니다. 담당자와 해제 조건이 없는 격리는 시간이 지나며 아무도 보지 않는 제외 목록이 되기 쉽습니다.

권한과 저장 무변경 같은 필수 위험을 격리한다면 대체 확인을 구체적으로 지정하고 출시 전 완료 여부를 확인합니다. 아직 실행하지 않은 수동 확인을 대체 검증 완료라고 쓰지 않습니다. 미션의 alternative는 합성 상태 검사와 실제 브라우저 확인 미실행을 함께 밝혀 범위를 제한합니다. 우선순위를 낮추는 결정은 단순히 검사 시간이 길다는 사실만으로 내리지 않습니다.

제외표는 ID와 영향으로 연결합니다

residual.json 한 행에는 test, status, impact, alternative, owner, due, releaseCondition, reason을 넣습니다. test에는 보류한 검사 ID를 쓰고 impact에는 해당 화면이나 데이터에서 가능한 피해를 씁니다. reason은 환경 준비 대기처럼 실행을 미룬 이유이고 impact는 재로그인 뒤 표시 지연처럼 사용자가 겪을 수 있는 결과입니다. 이유와 영향을 혼동하면 검토할 위험이 보이지 않습니다.

선택표에서 P0로 지정한 테스트가 동시에 제외표에 있으면 충돌입니다. 정말로 보류해야 한다면 선택 상태를 갱신하고 대체 검사와 출시 조건을 리뷰해야 합니다. 이번 검사기는 선택과 보류가 충돌하면 오류를 내며 사례 ID도 연결합니다. 사람 검토에서는 수동 확인이 같은 계약을 충분히 관찰하는지 추가로 봅니다. 필드가 채워졌다는 사실은 근거의 타당성을 증명하지 않습니다.

기한은 ISO 날짜로 쓰고 담당은 실제 인계 받을 역할 또는 사람으로 구체화합니다. 수업에서는 UI 담당 같은 역할을 사용할 수 있습니다. 담당만 있고 기한이 없거나 날짜만 있고 해제 조건이 없으면 후속을 추적하기 어렵습니다. 기한이 지났을 때 자동으로 위험이 사라지는 것은 아닙니다. 검토 일정과 종료 조건 확인을 별도의 후속 행동으로 관리합니다.

검증된 사실과 가설을 분리합니다

관찰 사실은 seed 2의 baseline에서 SAVE_NOT_READY가 발생하고 같은 seed의 fixed에서 통과한 결과입니다. 원인 설명은 고정 한 tick 대기가 지연 2의 준비 시점에 미치지 못했다는 코드와 관찰의 연결입니다. 실제 브라우저 부하에서도 같은 원인이라는 문장은 추가 검증이 필요한 가설입니다. 모형에서 확인한 인과를 실제 시스템 전체로 확장하지 않습니다.

품질 의견은 적용 버전, 변경 계약, 실행 범위, 실패와 수정, 제외 범위, 권고 순으로 쓸 수 있습니다. 예를 들어 지정 가상 지연 검사는 통과했지만 새 가입·세션 사례는 설계이며 실제 UI 증거 대기로 판단 보류라고 작성합니다. 조건부 진행 의견이라면 그 조건이 누구의 어떤 실행으로 해소되는지 적습니다. 막연히 문제 없어 보인다는 문장보다 검토 가능한 정보가 됩니다.

공개 보고서에는 합성 ID와 허용된 오류 코드만 연결합니다. 비밀번호, 쿠키, 개인 이메일, 임의 본문을 붙이지 않습니다. 이전 미션의 공개 로그 마스킹 결과를 그대로 재사용하고 원시 민감 증거를 새 보고서에 복사하지 않습니다. 코드와 문서가 안전한 입력을 쓴다는 이유로 실제 조직의 비밀값을 추가해도 된다고 해석하지 않습니다. 이 프로젝트의 범위는 제공된 합성 자료입니다.

제출 전에 자기 문서를 반박합니다

이 제외를 모르는 운영자가 출시하면 무엇을 놓칠까라는 질문으로 impact를 읽습니다. 사용자가 로그아웃한 뒤 만료 안내가 늦게 보이는 위험과 만료 뒤 저장이 허용되는 위험은 다릅니다. 두 상황을 같은 UI 오류라는 이름으로 압축하면 우선순위를 검토하기 어렵습니다. 남은 피해와 대체 확인의 관찰 대상이 같은지 비교하고 부족한 부분은 보류 이유에 추가합니다.

check-docs.py의 SELECT_CHANGES는 변경별 선택표가 없다는 뜻입니다. MISSING_BOUNDARY_OR_PERMISSION이면 새 경계·권한 사례 ID를 선택표에서 찾습니다. residual.json empty는 미검증 범위를 기록하지 않았다는 구조 오류입니다. 검사기를 통과시키기 위해 위험 없음만 반복하는 대신 실제 미실행 항목을 써야 합니다. 자동 검사는 문장을 읽고 타당성을 승인하는 도구가 아닙니다.

제출물은 변경 두 건에 대한 필수·후속·수동 확인 구분, 최초 실패와 수정 후 증거, 보류표, 잠정 품질 의견입니다. 실제 앱 실행을 하지 않았다면 그 사실이 첫 독자에게 보이도록 적습니다. 다음 모듈은 이 자료를 전체 테스트 계획과 릴리스 의견으로 묶습니다. 과정 기록을 설명하는 일반 틀은 더 읽기로 연결하고 여기서는 제외 결정의 책임과 해제 조건을 완성합니다.