변경 리뷰와 검증 기록

변경 줄에서 검증 질문을 만듭니다

가입 길이 규칙을 바꾸는 변경에 timeout 조정과 실패 무시 코드가 함께 들어오면 파일 수보다 목적과 동작을 읽어야 합니다. QA 리뷰는 코드를 보기 좋게 만드는 평가를 넘어 무엇을 확인했고 어떤 위험이 남았는지를 전달합니다. 이번 레슨은 변경 전후 자료에서 인수 기준·실패 전파·증거 공개에 영향을 주는 줄을 찾습니다.

리뷰 대상은 제품 코드, 테스트 코드, 실행 스크립트, 보고서입니다. 제품 입력 제한이 바뀌면 경계값과 오류 안내를 봅니다. 테스트 기대값이 바뀌면 요구 합의를 봅니다. 실행 스크립트가 바뀌면 실패가 전달되는지 봅니다. 보고서가 바뀌면 새 주장을 뒷받침하는 실행이 있었는지 확인합니다. 서로 다른 파일도 같은 목적의 변경일 수 있습니다.

단순 줄 비교는 어디가 달라졌는지 보여 주는 도구입니다. 추가 줄이 많다는 사실로 품질을 판단하지 않습니다. 비교 자료에는 원래 문맥과 호출 경로가 필요합니다. 저장 검증 함수만 읽어서는 UI가 오류를 올바르게 표시하는지 알 수 없고 workflow만 읽어서는 실제 CI 환경의 브라우저 준비를 증명할 수 없습니다.

작은 실패 무시 변경을 조사합니다

예시 변경은 await verifyProfile()을 try로 감싸고 catch에서 빈 처리를 합니다. 이전 코드는 검증이 실패하면 호출자에 오류를 전달하지만 수정 코드는 그 실패를 삼킵니다. 의도가 증거 수집이라면 catch에서 증거를 남긴 뒤 원래 오류를 다시 전달해야 합니다. 이번 리뷰에서는 이 줄을 승인 전에 수정할 대상으로 적습니다.

실제값을 기대값에 복사하는 변경도 확인합니다. assert.equal(actual.nickname, actual.nickname)은 항상 자기 값을 비교하여 프로필 저장 계약을 검사하지 못합니다. 합의한 새 닉네임을 기대값으로 유지해야 이전 값 표시 결함을 잡습니다. 테스트 통과 숫자가 늘었다고 검증력이 좋아졌다고 판단하면 이런 결함을 놓칩니다.

cleanup을 성공 경로 끝으로 이동한 변경은 실패 때 소유 계정을 남길 수 있습니다. 테스트 실패가 발생한 시점에서 정리 경로가 실행되는지 예외 흐름을 따라갑니다. 전체 회원 삭제로 정리 문제를 해결하면 다른 실행과 기준 데이터가 손상됩니다. 자기 실행이 만든 정확한 ID만 정리하는 앞 모듈의 계약을 리뷰 기준으로 사용합니다.

요구와 회귀를 연결합니다

변경 리뷰 표에는 바뀐 동작, 요구사항 ID, 기존 검사 ID, 새로 실행할 입력, 관찰값, 결과 링크를 둡니다. 실제 ID는 이어받은 spec과 cases에서 읽습니다. 문서에 없는 새 번호를 만들어 관련 있는 것처럼 연결하지 않습니다. 합의가 없는 변경은 질문 상태로 남기고 테스트 기대값을 먼저 바꾸지 않습니다.

비밀번호 최소 길이가 합의된 변경이라면 새 경계 아래·경계·위 입력을 선택하고 기존 상한·중복 가입·로그인 연계를 검토합니다. 이번 모듈에서는 영향 질문을 작성하며 회귀 최적화와 불안정성의 반복 분석은 다음 모듈에서 다룹니다. 모든 입력을 UI로 옮기지 않고 API와 UI가 관찰하는 결과를 구별합니다.

locator 이름 변경은 제품 UI와 검사가 함께 바뀌어야 하는지 확인합니다. 버튼 표시 계약이 유지되는데 테스트만 새 임의 이름을 선택하면 검사 결함입니다. 제품이 사용자 문구를 합의해 바꾸었다면 API 저장 규칙이 바뀐 것은 아니므로 그 층의 영향도 따로 판단합니다. 변경 파일 이름만으로 회귀 범위를 정하지 않습니다.

수행한 결과와 계획을 나눕니다

검증 기록에는 실행 명령, 입력 버전, 종료 코드, 검사 범위, 실패·건너뜀·외부 대기를 담습니다. 핵심 검사와 실제 UI를 별도 항목으로 적습니다. 브라우저를 시작하지 못한 경우는 UI PENDING이며 계획한 아홉 사례를 통과 수에 더하지 않습니다. 다른 사람이 결과를 재현할 수 있도록 실습 루트와 준비 조건도 남깁니다.

합성 replay에서 제품 분류가 확인되었다는 결과는 실제 제품 결함 수정 결과가 아닙니다. synthetic-replay 표시는 분류·실패 전파·정리 정책을 평가한 범위입니다. 실제 앱은 Java/API 검사와 UI 실행의 관찰로 따로 설명합니다. reports/triage.json을 복사해 실제 HTTP 실측 보고서라고 제목을 바꾸지 않습니다.

수정 후 재검증에는 이전 실패 조건을 유지합니다. 계정 이메일·대기 시간·요구 기대값을 한꺼번에 바꾸면 어떤 수정이 결과를 바꿨는지 설명하기 어렵습니다. 입력 변경이 필요한 경우 이유와 전후 차이를 남깁니다. 초록색 화면만 첨부하는 것보다 동일한 실패 fixture의 전후 종료 코드를 함께 보여 주는 편이 검토에 도움이 됩니다.

공개 자료 변경을 리뷰합니다

upload 경로가 artifacts 전체로 바뀌면 private trace가 포함되는지 확인합니다. 앞 모듈의 원본 trace는 공개 PNG 마스크의 영향을 받지 않습니다. 보고서에 비밀이 없더라도 압축 자료와 DOM에는 합성 개인정보가 남을 수 있습니다. 자동 저장 대상은 허용한 요약 JSON으로 좁히고 원본 접근 권한을 유지합니다.

이미지 공개에는 사람의 확인 기록이 필요합니다. PNG 파일에서 합성 비밀번호 문자열을 검색했지만 없었다는 결과는 픽셀의 개인정보 부재를 증명하지 않습니다. 사람이 마스킹 영역과 그 밖의 표시를 확인한 범위·시각·자료 ID를 적습니다. 검토하지 않은 이미지는 공개 후보로 자동 업로드하지 않습니다.

오류 메시지를 새 보고서 필드로 추가하는 변경도 점검합니다. 예외 원문에 토큰이나 계정 정보가 들어갈 수 있으므로 공개 보고에는 허용한 근거 코드와 요청 ID를 씁니다. 자세한 진단은 제한된 원본에서 수행합니다. 확인이 끝난 비밀값을 해설에 다시 붙여 쓰면 마스킹 정책을 우회하므로 리뷰 문장도 같은 범위를 지킵니다.

차단·질문·후속을 구체적으로 씁니다

리뷰 의견은 파일과 동작, 관찰 근거, 요청할 수정으로 씁니다. 예를 들어 실패를 삼키는 catch가 원래 단언 오류를 전파하지 않아 합성 API 실패에서 종료 코드 0이 되므로 수정 후 7을 유지하는지 확인해 달라고 적습니다. 코드가 나쁘다는 평가는 담당자가 어떤 변경을 해야 하는지 알려 주지 못합니다.

현재 검증에 필요한 차단 의견과 범위를 넓히는 후속 의견을 구분합니다. 실패 전파 누락은 지금 결과의 신뢰를 깨뜨리는 차단 이유입니다. 다른 브라우저 확대 검사는 현재 합의 범위 밖이라면 후속으로 담당·확인 조건을 남길 수 있습니다. 제외한 범위를 숨기거나 모든 후속을 현재 통과 조건으로 바꾸지 않습니다.

질문에는 아직 없는 근거를 명시합니다. oracle이 확인되지 않았으면 기대 닉네임을 합의한 요구 ID와 연결해 달라고 요청합니다. 제품 UI 이름이 바뀌었으면 문구 합의와 접근 가능한 이름을 확인합니다. 질문의 답이 오기 전에 기대값을 변경하여 테스트만 통과시키지 않습니다. 조사 부족은 UNKNOWN과 다음 조치로 남깁니다.

검토 가능한 제출물로 마무리합니다

이번 문서 실습은 실패 무시 diff와 미션 산출물을 읽어 리뷰 기록을 제출합니다. 세 개 이상의 발견에 변경 줄, 요구 또는 실행 계약, 재검증 명령, 기대 관찰을 씁니다. 사람은 주장과 근거 연결을 확인합니다. 문서가 존재한다는 자동 검사만으로 내용의 타당성을 판정하지 않습니다.

미션은 m07 solution을 보존하여 ci/classify.cjs의 TODO를 완성하는 확장입니다. ci/check-triage.sh는 세 실패와 수정 fixture, UNKNOWN 세 경계를 검증합니다. check-ci-core.sh는 보존과 이전 회귀까지 실행합니다. 전체 check.sh의 실제 브라우저 결과가 없으면 외부 대기로 명시하고 검증된 core 결과를 함께 제출합니다.

최종 리뷰 기록에는 테스트한 것, 계획한 것, 제외한 것, 판단을 바꿀 조건이 각각 드러나야 합니다. 예를 들어 실제 브라우저가 기동하여 아홉 사례를 실행하면 UI 대기 상태를 갱신한다고 씁니다. 협업과 diff의 일반 기능은 더 읽기로 이어가고 여기서는 변경을 승인할 근거와 아직 필요한 실행을 명료하게 전달합니다.