사전 조건과 사용자 행동

기능 이름 대신 한 사람의 일을 씁니다

동아리 신청 화면에 상태 확인 버튼을 추가해 달라는 요청을 받았습니다. 버튼이라는 해결책만 기록하면 어디에서 누구에게 어떤 상태를 보여 줄지 개발자가 추측하게 됩니다. 앞 조사에서 Q01은 결과 경로를 모르는 신청자의 재문의이며 E003은 두 경로를 열고 문의한 관찰, E006은 신청 양식에 결과표 안내가 없다는 관찰입니다. 이 레슨은 그 근거를 사용자가 끝내려는 일과 연결하고 시작 조건·행동·결과가 있는 시나리오로 바꿉니다.

이번 모듈은 Python 3로 문서 미션을 검사하고 마지막 레슨은 JavaScript 브라우저 채점으로 규칙을 확인합니다. 미션 starter를 별도 연습 폴더에 풀면 m04 solution의 근거와 access-policy.json이 그대로 들어 있습니다. 새 spec.json만 편집합니다. 화면은 텍스트 초안이며 실제 계정이나 운영 서버를 사용하지 않습니다. 가명 ID를 쓰고 새로운 화면 정책은 proposed로 표시합니다. 문서 단계의 output은 비워 두며 실제 실행한 코드만 출력 기록을 남깁니다.

문제와 목표의 연결을 좁힙니다

사용자 목표는 “상태 버튼을 누른다”보다 “내 신청이 접수되었는지와 승인 결과를 확인하여 다음 일정을 판단한다”가 적절합니다. 행동 수단과 업무 목적을 구별하면 메뉴나 링크 위치를 바꾸어도 목표를 유지할 수 있습니다. 다만 현재 조사로 확인하지 않은 일정 지연 시간을 효과 수치로 적지는 않습니다. 관찰된 탐색과 문의를 문제 근거로 삼고 실제로 빨라졌는지는 후속 사용성 테스트에서 확인할 질문으로 남깁니다.

E005에서는 다른 신청자가 결과표를 바로 찾았습니다. 이 반례를 지우면 모든 사람이 상태 확인에 실패했다는 과장으로 이어집니다. 이번 시나리오는 결과 경로를 모르는 신청자를 대상으로 합니다. 모든 회원에게 알림을 보내는 기능이나 운영자의 심사 속도를 높이는 기능은 아직 결정하지 않습니다. 시나리오 첫 줄에 problemId=Q01을 붙이면 기능 추가 요청이 원래 문제를 해결하는지 다시 물을 수 있습니다.

사전 조건은 행동 전에 확인할 상태입니다

핵심 조회 시나리오는 “유효한 세션의 U01에게 EV01의 A001 신청이 있고 서버 소유권 확인이 허용된다”에서 시작합니다. 이것은 버튼을 누른 결과가 아니라 행동 전에 준비할 자료입니다. 신청 상태는 PENDING으로 지정합니다. PENDING은 접수 뒤 승인 대기라는 계약이며 승인 완료를 뜻하지 않습니다. 세션 유효성·소유권·행사·현재 신청 상태를 적으면 같은 화면을 열어도 다른 결과가 나오는 이유를 설명할 수 있습니다.

m04 permissions의 self-read를 참조하여 본인 조회 정책과 연결합니다. ownerUserId를 화면에 직접 입력시키는 전제는 쓰지 않습니다. 서버가 확인한 주체와 저장된 소유자를 대조한다는 제안을 유지합니다. 비로그인 사용자가 우연히 A001 번호를 알았다는 조건만으로 조회를 허용하면 이전 정책과 충돌합니다. 로그인 화면으로 이동하는 시나리오를 별도로 만들고 만료 안내와 권한 거부 안내가 달라지는 이유를 남깁니다.

행동 하나를 관찰 가능한 결과에 연결합니다

핵심 행동은 “접수 결과 화면의 신청 내역 확인을 선택한다”입니다. 결과는 “본인 A001의 EV01과 승인 대기 문구를 표시하고 다음 확인 경로가 유지된다”로 씁니다. “사용자가 만족한다”는 결과만 두면 테스트 중 무엇을 확인할지 모릅니다. 사용자가 문구를 이해했는지는 별도의 관찰 과업이고 여기서는 우선 어떤 정보를 어느 화면에 보여 줄지 계약을 작성합니다. 화면 상태 ID를 붙여 다음 레슨의 초안과 연결합니다.

생성 시나리오도 작성합니다. 유효한 세션과 EV01 선택을 준비하고 신청 제출을 실행합니다. 저장 성공이 확인되면 applicationId와 승인 대기 상태 및 내역 링크를 제시합니다. 저장 확인 전부터 성공 문구를 띄우는 초안은 이 결과에 맞지 않습니다. 접수 성공과 운영자 승인은 다른 사건이므로 생성 결과에 APPROVED를 넣지 않습니다. 운영자의 승인 기능은 앞 계약에서 미구현 후속 제안으로 남겨 두었습니다.

생성 카드가 참조하는 self-read는 접수 후 본인 결과를 읽는 권한 사례입니다. 기존 m04에는 신청 생성 행동의 권한 표가 없으므로 조회 허용을 생성 허용으로 확대하지 않습니다. 생성 요청의 세션 확인·행사별 신청 자격은 새 검토 질문으로 남기며 실제 서버 인수 검증 전에는 구현 완료라고 쓰지 않습니다.

실패 갈림길은 정상 흐름을 복사하지 않습니다

입력 누락은 행사 선택을 다시 요구하는 길입니다. 권한 거부는 현재 계정으로 대상을 볼 수 없으므로 본인 내역으로 돌아가는 길입니다. 응답 유실은 저장 여부가 미확인이므로 먼저 내역을 확인하는 길입니다. 세 갈림길을 모두 “다시 제출”로 쓰면 입력이 맞는 사람에게 불필요한 수정을 요구하고 이미 접수된 신청을 새로 만들 수 있습니다. 각 예외에서 무엇을 마지막으로 확인했는지와 무엇이 아직 미확인인지 적습니다.

중복 제출 사례는 동일 키·동일 본문을 순차 재전송했을 때 기존 신청 ID가 반환되고 행이 늘지 않는다는 m03 계약에 연결합니다. 새 키로 같은 행사를 두 번 신청하는 정책까지 확인한 것으로 확대하지 않습니다. 동일 키에 다른 본문을 쓰는 경우에는 계약된 충돌 처리가 필요하다는 후속 검토를 남깁니다. 단순한 더블 클릭 방지 화면과 서버의 재전송 처리 책임을 같은 문장으로 완료 처리하지 않습니다.

작성 순서는 근거에서 화면으로 갑니다

먼저 problemId와 근거·반례 ID를 적고, 다음에 대상과 사전 조건을 작성합니다. 행동과 결과를 한 쌍으로 만든 뒤 화면 ID와 권한 사례 ID를 붙입니다. 예를 들어 SC-normal은 UI-normal과 self-read에 연결됩니다. basis=proposed는 이 흐름이 설계 제안이라는 표시입니다. 기존 조사 사실과 모의 API 결과가 있다고 해서 새 화면에서 사용자 행동을 관찰한 사실이 생기지는 않습니다. 문서의 출처 표시로 이 차이를 지킵니다.

흔한 실수는 사전 조건에 “저장 버튼을 누름”을 넣고 행동에도 같은 문장을 쓰는 것입니다. 그러면 버튼을 누르기 전에 신청이 있었는지 알 수 없습니다. 또 “정상 처리”라는 결과는 접수와 조회를 구별하지 못합니다. 동료에게 시나리오를 주고 필요한 계정·행사·신청 상태를 준비하게 해 보세요. 어떤 자료를 준비할지 다시 질문한다면 사전 조건을 보완하고, 결과를 두 가지로 해석한다면 표시 정보와 이동 목적지를 좁힙니다.

리뷰 가능한 문서로 제출합니다

제출물은 정상 조회·신청 생성·예외 흐름을 포함한 시나리오 카드입니다. 카드에는 고유 ID, 문제 ID, 정책 참조, 사전 조건, 행동, 결과, 화면 ID를 기록합니다. 운영자 시나리오를 추가하려면 담당 행사 조건을 명시하고 기존 본인 조회 범위를 넓히지 않습니다. 조사 참여자 P01과 시스템 가명 계정 U01은 서로 다른 목록의 ID이므로 연결 사실이 없는 상태에서 같은 사람이라고 단정하지 않습니다. 사용자 유형과 테스트 계정을 구별합니다.

더 읽기의 명세 장에서는 입력·출력 약속을 코드 예시로 확장할 수 있습니다. 여기서는 그 예제를 옮기지 않고 동아리 업무의 시작 조건과 확인 경로를 먼저 완성합니다. 좋은 시나리오는 동료가 같은 조건을 준비해 같은 기대 결과를 설명할 수 있으며, 아직 결정하지 않은 정책을 미확인 칸에서 찾을 수 있는 문서입니다. 이후 화면 초안과 인수 기준이 바뀔 때도 이 카드의 ID를 유지하여 변경 이유를 추적합니다.