관찰 가능한 인수 기준

완료라는 말에 확인 방법을 붙입니다

“사용하기 편하고 오류 없이 상태를 확인할 수 있다”는 목표를 받았습니다. 좋은 의도지만 개발자와 검토자가 같은 결과를 떠올리기 어렵습니다. 한 사람은 버튼이 보이면 완료라고 하고 다른 사람은 안내를 읽고 문의 없이 끝나야 완료라고 할 수 있습니다. 인수 기준은 어떤 조건에서 어떤 행동을 했을 때 무엇을 확인해야 받아들일지를 적는 약속입니다. 이번 레슨에서는 화면 초안의 상태를 조건·행동·결과와 증거로 연결합니다.

한 기준은 한 판단을 가능하게 합니다

AC-normal은 유효 세션 U01, 선택 행사 EV01, 저장 성공 응답이라는 조건에서 제출 결과를 확인할 때 “신청 접수 · 승인 대기”와 신청 내역 행동이 표시되어야 한다는 기준입니다. 저장 건수 증가 1은 m03의 생성 사례에서 기대하는 증거입니다. 화면 문구와 데이터 변화는 다른 관측이므로 각각 확인 방법을 씁니다. 화면이 성공처럼 보였다는 사실만으로 DB에 한 건이 생겼다고 결론내리지 않습니다.

given은 준비할 조건, when은 실행할 행동, then은 관찰할 결과를 뜻하는 필드 이름입니다. 영문 서식 자체보다 조건과 결과가 빠지지 않는지가 중요합니다. “정상적으로 제출하면 잘 표시된다”는 표현에는 준비할 행사, 사용자, 결과 문구가 빠져 있습니다. 검토자가 제공한 계정과 자료를 준비하고 표시 문구를 대조할 수 있게 작성합니다. 실제 서비스의 계정을 쓰지 않아도 이번 모의 계약과 텍스트 초안에 대한 기준을 작성할 수 있습니다.

오류 처리도 성공적인 인수 대상입니다

행사 누락 제출에서 선택 안내가 표시되고 입력 위치가 제시되며 저장 행이 늘지 않으면 해당 오류 처리 기준은 통과입니다. 입력이 잘못되었다는 뜻과 테스트가 실패했다는 뜻을 구분합니다. AC-permission-denied도 권한 없는 U02가 U01 신청을 요청했을 때 보호 데이터 없이 거부 안내와 본인 내역 이동을 제공하면 통과입니다. 정상 접수 테스트만으로는 거부 경로가 준비되었는지 알 수 없습니다.

로딩은 응답 전 안내와 다음 행동 유지, 빈 상태는 성공한 조회의 목록 0건과 행사 목록 이동을 확인합니다. 두 사례에서 신규 생성 행은 0이지만 그 뜻이 같다고 묶지 않습니다. 조회는 기록을 생성하지 않는 시나리오이고 빈 목록은 조회 결과의 내용입니다. 목록이 빈지 알 수 없는 네트워크 오류에 빈 상태 기준을 적용하면 실패 원인을 지웁니다. 각 기준의 given이 어떤 서버 결과를 전제로 하는지 읽습니다.

관찰 위치를 나누어 증거를 씁니다

화면 문구는 화면 리뷰, 응답 필드와 재전송 ID는 모의 API 재현, 행 증가량은 저장 자료 대조로 확인합니다. 이번 미션 verification=mock-replay는 앞 모듈의 모의 계약에 연결한 기준이고 design-review는 텍스트 화면과 제안을 검토하는 기준입니다. 새 화면이 실제 구현되었다는 뜻이 아닙니다. evidence에는 어느 자료를 대조할 것인지 적고 “확인 완료”처럼 확인 방법이 없는 문장을 넣지 않습니다.

응답 유실 기준의 rowDelta는 null로 남깁니다. null은 여기서 저장 증거가 미확인이라는 문서 약속입니다. 값 0으로 바꾸면 미저장을 확인했다는 다른 주장이 됩니다. 후속 조회와 요청 기록을 통해 접수 여부를 확인할 인수 과업을 별도로 둡니다. 동일 키·동일 본문 재전송 기준은 같은 applicationId 반환과 신규 행 0을 함께 봅니다. 두 번째 요청 응답이 있었다는 이유만으로 중복 생성이 방지됐다고 말하지 않습니다.

기준과 화면의 연결을 검사합니다

criteria의 scenarioId와 screenId는 기존 카드의 고유 ID를 참조합니다. then과 nextAction은 해당 화면의 message와 nextAction에 맞춥니다. 화면을 고치고 인수 기준을 남겨 두면 개발자는 옛 문구로 테스트할 수 있습니다. 자동 검사는 이 문자열 일치와 ID 존재를 찾아주지만 문구가 사용자의 다음 행동을 잘 설명하는지는 판단하지 못합니다. 통과 후 동료가 조건의 충분성, 업무 목표와의 연결, 불확실성 표현을 읽습니다.

같은 기준을 정상·오류 상태 전체에 복사하면 검사 수는 늘어도 확인 범위가 넓어지지 않습니다. AC-store-failure는 미저장 확인과 선택·키 보존, AC-session-expired는 보호 응답 제거와 로그인 후 최신 조회, AC-duplicate는 기존 접수 반환을 중심으로 작성합니다. 공통된 단어가 있어도 각 기준의 실패를 설명할 사건은 달라야 합니다. criterion ID를 버그 보고서에 남기면 무엇이 약속과 달랐는지 대조할 수 있습니다.

모호한 단어를 측정 가능한 질문으로 고칩니다

“빠르게”는 측정 시작과 종료, 측정 조건, 목표 수치를 결정하기 전에는 판정할 수 없습니다. 이번 조사에는 응답 시간 근거가 없으므로 임의 성능 수치를 완료 기준으로 만들지 않습니다. “쉽게”는 사용자가 안내 없이 내역 경로를 찾아 상태를 설명하는 과업으로 바꿀 수 있지만 실제 이해 여부는 m07에서 관찰합니다. 화면에 링크가 있다는 기능 기준과 사용자가 링크를 찾았다는 사용성 근거를 다른 칸에 둡니다.

외부 시스템을 기다리는 동안 영원히 로딩해도 되는지 같은 미결정 질문은 검토 목록에 적습니다. 근거 없는 제한 시간을 정답으로 고정하는 대신 어떤 기기·연결 조건에서 담당자가 합의할지 정합니다. 미결정 기준을 완료로 표시하지 않으면 다음 모듈에서 우선순위와 범위를 조율할 자료가 됩니다. 반대로 모든 미결정을 사소한 구현 문제로 넘기면 복귀 행동이 없이 출시될 수 있으므로 사용자 영향도 함께 적습니다.

검사 오류를 문서의 어느 칸과 연결할지 읽습니다

미션 패키지 루트에서 python3 check.py --submission spec.json을 실행합니다. FAIL scenarios: screenId 참조 오류는 화면 ID의 철자 또는 화면 누락을 보라는 뜻입니다. FAIL criteria: 화면 문구·행동과 불일치는 then·nextAction과 화면 카드를 대조하라는 뜻입니다. FAIL json의 line과 column은 JSON 구문 위치이므로 따옴표·쉼표·앞줄 끝도 확인합니다. 검사기를 수정해서 빨간 줄을 숨기지 않고 제출 문서를 약속에 맞춥니다.

starter에서는 이전 근거는 통과하고 아직 쓰지 않은 화면과 기준이 실패합니다. solution에서는 구조 검사 실패가 0이지만 실제 제품이 출시 가능한 상태라는 결론은 나오지 않습니다. Python 검사기는 문자열·참조·표본 규칙을 확인합니다. 화면 포커스가 실제로 이동하는지, 서버가 다른 사람의 신청을 거부하는지, 응답 유실 뒤 접수 확인이 가능한지는 구현 이후 검증할 일이므로 review.next에 남깁니다.

리뷰에서 통과와 미확인을 함께 보고합니다

완료 보고에는 기준 ID, 조건, 기대 결과, 확인 자료, 판정, 남은 질문을 씁니다. 디자인 리뷰에서 안내와 경로가 맞았다는 결과를 실제 사용자 이해로 확대하지 않습니다. 모의 API의 순차 중복 사례가 맞았다는 결과를 동시 요청 전체에 대한 보장으로 확대하지 않습니다. 검토자는 문제가 발견되면 문장·자료·코드 중 무엇을 고칠지 지정하고 변경 이유를 남깁니다. 이렇게 하면 테스트 실패가 책임 공방보다 약속 보완의 자료가 됩니다.

더 읽기의 반례와 테스트 장은 경계와 잘못된 입력을 코드 테스트로 다룹니다. 이 레슨의 중심은 업무 화면·저장 증거·권한 정책 사이의 연결입니다. 텍스트 초안의 각 상태에 인수 기준이 하나 이상 연결되었는지 확인하고, 다른 사람이 조건을 준비할 수 있는지 읽어 봅니다. 다음 레슨에서 마감과 정원이라는 새로운 업무 규칙을 정한 뒤 같은 원칙으로 구체적인 경계 입력과 기대 결과를 작성합니다.

python3 check.py --submission spec.json