테스트 케이스 리뷰

통과 개수보다 기대값의 근거를 읽습니다

테스트 표에 24개가 있어도 같은 정상 입력을 반복하면 위험을 충분히 확인하지 못합니다. 리뷰는 사례 수를 승인하는 회의가 아니라 사전 조건·행동·기대값·근거의 연결을 읽는 일입니다. 신입에게 자주 요구하는 수정은 문장을 더 길게 쓰는 것이 아니라 실행자가 같은 상태를 만들고 같은 관찰 결과로 비교할 수 있도록 빠진 조건을 채우는 것입니다.

이 모듈의 미션은 앞 모듈 spec을 보존한 채 사례와 교육용 계약, 검토표를 더합니다. 구현 앱을 실행하지 않았으므로 사례 상태는 planned이고 실제 결과나 결함 ID를 만들어 넣지 않습니다. 문서 형식 검사 PASS와 제품 테스트 통과를 구분해 제출합니다. 테스트 설계가 끝났다는 설명에는 아직 앱 실행, API 코드 확인, 실제 시간 만료 검증이 남아 있다는 범위를 덧붙입니다.

한 행을 다섯 질문으로 읽습니다

첫째는 어떤 요구사항과 인수 기준을 검증하는가입니다. REQ-07의 본인 수정 사례인데 기대값에 타인 거절을 쓰면 연결이 어긋납니다. 둘째는 시작 상태를 다시 만들 수 있는가입니다. 로그인이라고만 쓰지 않고 A 세션·대상·기존 닉네임을 적습니다. 셋째는 한 번의 행동이 분명한가입니다. 가입과 수정이 섞였으면 실패 위치를 구분하도록 사례를 나눕니다.

넷째는 무엇을 어디서 관찰해 비교하는가입니다. 성공이라고 쓰기보다 안내와 재조회 값, 회원 수 변화를 씁니다. 다섯째는 그 기대값이 어디서 왔는가입니다. 기존 인수 기준 또는 추가 계약의 항목을 source와 contractRef로 연결합니다. 현재 제품 출력이나 작성한 함수가 그렇게 동작한다는 설명만으로는 결함을 가려낼 독립적인 기준이 되지 못합니다. 합의가 없는 규칙은 보류로 남깁니다.

리뷰에는 입력뿐 아니라 입력이 유효하도록 고정한 조건도 읽습니다. 길이 8의 가입 사례에 중복 이메일을 사용하면 결과가 거절이어도 경계 정책이 틀렸다고 말하기 어렵습니다. 반대로 중복 이메일 사례에서 비밀번호 길이를 7로 두면 중복 검사를 건너뛴 제품이 다른 오류로 거절해 통과할 수 있습니다. 각 사례가 겨냥하는 조건과 나머지 유효 조건을 나란히 표시합니다.

중복과 겹침을 구분합니다

길이 8과 9는 모두 허용 결과지만 확인하는 경계 위치가 다릅니다. 같은 결과라는 이유로 중복 삭제하지 않습니다. 길이 20의 사례를 이메일 이름만 바꾸어 여러 번 추가한 것은 별도 위험을 확인하는 근거가 약합니다. 입력·사전 조건·기대값과 의도를 함께 비교해서 중복 후보를 찾습니다. 자동 검사기는 완전히 같은 내용의 사례를 거부할 수 있지만 의미가 같은 다른 문장은 사람 리뷰가 필요합니다.

하나의 사례에 권한과 세션 만료가 함께 등장할 수도 있습니다. 이때 어느 규칙의 거절을 먼저 기대하는지 계약을 확인하고 주 유형을 선택합니다. 유형별 개수만 세는 방식은 권한 검사가 실제로 실행되는지 설명하지 못합니다. 타인 접근은 유효한 세션으로, 만료 접근은 본인 대상으로 분리해 각각의 이유를 확인하는 사례를 확보합니다. 교차 조건은 그 다음에 우선순위 검증으로 추가합니다.

전이 시퀀스가 길어지면 한 줄만 고쳐 여러 조건을 검증한 것처럼 보일 수 있습니다. 각 사건의 중간 상태를 기록하고 다음 행동이 가능한 전제를 확인합니다. LOGIN_OK 없이 본인 수정 허용을 기대하는 시퀀스는 시작 상태와 모순됩니다. 리뷰에서 첫 행동 전 상태와 마지막 데이터 효과를 모두 읽어야 순서에 의존하는 누락을 찾을 수 있습니다.

보류 조건을 숨기지 않습니다

이메일 대소문자와 닉네임 길이 단위는 앞 모듈 질문에서 보류했습니다. 현재 문자열 함수의 동작을 보고 기대값을 확정하면 팀이 합의하지 않은 규칙을 테스트로 강요할 수 있습니다. review.json의 pending에 Q-01과 Q-05를 연결하고 기대값에 미치는 영향과 다음 확인을 씁니다. 이 항목은 합의 전 실행 대상에서 제외한 이유가 되며, 질문이 해결되면 사례와 계약을 함께 갱신합니다.

교육용 계약 v2는 길이 계산과 접근 순서, 상태 전이 모델을 확정한 학습 범위입니다. 기존 spec의 source를 v2로 일괄 바꾸지 않습니다. 새 사례의 contractRef로 추가 근거를 표시하고 기존 인수 기준의 연결은 유지합니다. 변경 이력을 분리하면 후속 작성자가 이전 합의를 바꾸었는지 추가 설계 가정을 썼는지 알 수 있습니다. 설계 리뷰에서도 자료 출처의 혼합을 지적합니다.

HTTP 상태 코드와 실제 만료 시간은 미확정 범위입니다. review의 excluded에는 단순히 시간 부족이라고 쓰기보다 아직 계약이 없어 비교 기준을 만들 수 없으며 후속 API·앱 검증에서 확인한다고 적습니다. 제외 범위가 잘 보이면 테스트 표를 읽는 사람이 문서 검사 결과를 제품 전체 품질로 확대하지 않습니다. QA의 보고는 확인한 범위와 미확인 위험을 함께 전달할 때 판단에 도움이 됩니다.

검사 실패와 리뷰 지적을 따로 처리합니다

check.sh는 먼저 기존 spec 검사기를 실행하고 이어 사례 검사기를 실행합니다. 사례 최소 개수, 고유 ID, 유효한 요구사항·인수 기준 참조, 필수 필드, 경계 길이, 결정표 여덟 행, 전이 범위와 review의 보류 질문 연결을 확인합니다. 입력과 기대 분류가 계약의 계산 모델과 일치하는지도 비교합니다. 다만 한국어 문장의 의미, 실제 안내 문구와 저장 결과의 타당성은 사람이 계약과 대조합니다.

FAIL TC-09: 요구사항/기준 연결이라고 나오면 숫자만 바꾸지 않고 해당 사례의 의도가 연결 대상과 맞는지 확인합니다. FAIL 경계 누락은 7·8·9·63·64·65가 있는지 읽습니다. 읽기 오류는 문서 구조를 고쳐야 하며 checker 자체를 바꾸어 우회하지 않습니다. 한 오류를 고친 뒤 다시 실행하고, 정상 solution이 통과하며 결손 starter가 실패하는지 비교하면 검사 경로가 실제로 동작하는지도 알 수 있습니다.

형식 검사가 끝나면 동료에게 한 경계 사례, 한 권한 거절, 한 만료 시퀀스를 골라 따라 읽게 합니다. 그 사람이 질문 없이 합성 상태를 준비하고 기대값을 설명할 수 있는지 확인합니다. review에는 검토 대상과 발견한 누락, 수정 내용, 남은 범위를 기록합니다. 앱을 실행하지 않은 상태에서 passed나 결함 해결이라는 문장을 쓰지 않으며 다음 모듈에 planned 사례를 넘깁니다.

최종 제출물은 cases/cases.json의 24개 이상 사례, contract.json의 추가 약속, review.json의 검토 근거입니다. 경계값은 입력 축, 결정표는 조건 조합, 전이 시퀀스는 사건 순서를 담당합니다. 각 기법이 확인하는 위험을 연결해 설명하고 제외한 규칙의 다음 조치를 말해 봅니다. 테스트를 사고의 도구로 사용하는 일반 원리는 더 읽기의 서재 장에서 이어 읽고, 여기서는 자신이 쓴 표를 재현 가능하게 마무리합니다.