1단계
1단계 — 요구사항을 상태와 증거로 바꾸기
0회 조회
목차
1단계 — 요구사항을 상태와 증거로 바꾸기
“업로드가 된다”, “시드가 끝난다”는 문장은 너무 넓습니다. 무엇이 성공이고, 어느 순간 사용자가 기다려야 하며, 일부만 처리됐을 때 무엇을 다시 해야 하는지부터 써야 합니다.
상태 표부터 만든다
| 상태 | 서버의 사실 | 사용자에게 보여 줄 것 | 다음 행동 |
|---|---|---|---|
| 성공 | 필요한 계약을 모두 충족 | 완료 건수와 다음 단계 | 공개 경로 확인 |
| 진행 중 | 작업이 아직 소유자 안에 있음 | 진행 상태와 중복 실행 방지 | 기다리거나 떠남 |
| 부분 실패 | 일부만 처리되고 실패 목록이 있음 | 처리 수·실패 수·파일별 이유 | 실패 항목만 재시도 |
| 실패 | 트랜잭션 또는 필수 검사가 거부됨 | 안전한 오류와 재실행 방법 | 원인 수정 후 재시도 |
다섯 관점의 증거
기획은 정상·예외 요구를, 디자인은 좁은 화면·키보드·포커스를, 개발은 API·DB 계약을, 사용자는 현재 상태와 재시도를, 운영은 health·로그·복구를 확인합니다. 아래 흐름에서 한 칸이 비면 완료가 아니라 검증 대기입니다.
요구사항 → 상태/오류 → API·DB → UI 피드백 → 자동 검사 → 배포 smoke
Codingstairs Admin의 콘텐츠 시드는 파일 오류를 조용히 성공으로 만들지 않고 409와 오류 목록을 반환해야 합니다. 화면은 role=status, 처리·실패 건수, 펼칠 수 있는 상세, 재실행 안내를 제공해야 합니다. 사용자는 “버튼을 눌렀다”가 아니라 “어디까지 반영됐는지”를 알아야 합니다.
직접 해 보기
새 기능 하나를 골라 위 표를 작성하고, 각 행마다 실제 테스트 명령 또는 로그 위치를 하나씩 적습니다. 성공만 검사하는 테스트는 부분 실패를 추가한 뒤 다시 설계합니다.