테스트 계획 통합

계획은 다음 실행을 결정하는 문서입니다

동아리 회원 서비스의 가입·로그인·프로필 수정을 여러 모듈에 걸쳐 확인했습니다. 마지막에는 파일을 모으는 것보다 어떤 계약을 어떤 환경에서 확인했는지 설명하는 일이 중요합니다. 팀원이 README-m10만 읽고 실행 대상을 고를 수 있어야 합니다. 테스트 계획은 실행할 목록, 준비 조건, 결과를 받아들일 기준과 중단할 조건을 묶어 주는 문서입니다. 계획에 적힌 검사가 아직 실행되지 않았다면 그 사실도 결과 보고에 남깁니다.

신입에게 모든 검사를 늘리라고 요구하지 않습니다. 대신 가입 거절이 저장을 바꾸지 않아야 한다는 관찰 기준처럼 사용자 피해와 연결된 검사를 설명하도록 요구합니다. 제목이 같은 테스트라도 계약이 바뀌면 기대값이 달라집니다. m09에서 가입 길이와 세션 만료 변경에 대해 만든 RG 사례는 설계 상태입니다. 이전 TC 사례를 새 계약의 실행 증거로 자동 승계하지 않습니다. 계획의 대상에는 계약과 구현 버전을 함께 적습니다.

이번 모듈의 문서 실습은 누적 프로젝트에서 quality 폴더를 추가하는 방식입니다. Python 3·Node·bash를 준비하고 압축을 푼 미션 루트에서 명령을 입력합니다. 운영 계정과 외부 서비스는 사용하지 않습니다. 첫 레슨의 제출물은 문서이며 세 번째와 네 번째 레슨에서 같은 계획을 판단과 설명으로 확장합니다. 실제 앱이나 브라우저 실행이 없으면 결과를 만들어 적지 않습니다. 로컬 검사 통과와 사용자 인수 기준 통과를 구분합니다.

범위와 환경을 한 쌍으로 적습니다

quality/plan.json의 target에는 m09에서 상속한 교육용 프로젝트와 m10 가상 모형 검사를 적습니다. scope에는 가입·로그인·프로필을 넣고 excluded에는 실제 UI 전체와 CH-LENGTH·CH-SESSION 변경 앱 검증을 적습니다. 가입이라는 기능 이름이 같아도 화면 동작과 가상 모형은 대상이 다릅니다. environment에는 사용한 런타임과 실행 방식, data에는 합성 데이터와 seed를 적어 다른 사람이 증거를 해석할 수 있게 합니다.

환경 칸에는 최신 버전이라고 쓰지 않습니다. 실제 실행한 환경은 reports의 기록으로 남기고 상속한 버전 기록은 이전 실행 자료라고 표시합니다. 앱 소스가 함께 있다고 이번에 Java 검사를 실행한 것은 아닙니다. m10의 check.sh는 서버를 열지 않으며 문서 연결과 합성 모형을 검사합니다. 제공 Java 프로젝트를 따로 실행했다면 그 명령·대상·결과를 별도 증거로 붙이고 기존 기록을 덮어쓰지 않습니다.

데이터 계획에는 생성 주체와 정리 범위를 넣습니다. 예를 들어 seed별 read·write 상태를 분리하고 기존 keep 값을 유지하는 검사는 상태 격리의 제한된 증거입니다. 이것이 실제 회원 DB의 전체 정리를 검증한 것은 아닙니다. 팀원이 실행할 때 자신이 만든 데이터와 다른 실행의 데이터를 구분할 수 있어야 합니다. 합성 계정도 공유 파일에 실제 비밀번호나 세션 값을 넣지 않고 요청 식별자만 남기는 방식으로 공개합니다.

진입·중단·완료 조건은 행동으로 씁니다

진입 조건 entry는 상속 파일 해시 일치와 합의 계약 식별입니다. 이는 비교 대상이 달라진 상태에서 결과를 해석하는 실수를 줄입니다. 계약 미확정 상태라면 담당자에게 질문을 보내고 보류 항목을 표시합니다. 질문의 답을 추측해 기대 결과로 넣으면 실패가 제품 문제인지 합의 문제인지 구분할 수 없습니다. 조건을 만족하지 못했을 때 누가 어떤 자료를 준비할지도 같이 정합니다.

중단 조건 stop은 검사를 모두 멈춘다는 뜻만은 아닙니다. 이번 예시는 권한·저장 무변경 증거가 없으면 출시 의견을 보류하는 조건입니다. 실행 자체가 깨졌다면 원인 분류와 환경 준비를 먼저 합니다. 가입 안내 문구 한 건이 통과했다고 타인 프로필 권한 위험을 감수할 근거가 생기지 않습니다. 차단 사유와 계속 실행 가능한 검사 범위를 나눠 적으면 조사와 의사결정을 동시에 진행할 수 있습니다.

완료 조건 exit는 담당 책임자가 대상 앱·UI 증거를 검토하고 미검증 항목의 처리에 동의한 상태로 정합니다. 모든 테스트 성공만 쓰면 선택하지 않은 검사와 제한 환경이 빠집니다. 기한을 넘겨도 위험이 사라지지 않으므로 일정 종료와 품질 조건 충족은 분리합니다. 후속 담당·기한은 기록을 추적하기 위한 약속이며 그 날짜가 출시 승인을 의미하지 않습니다. 기한 예시는 실제 제출일에 맞게 조정합니다.

인수 기준별로 연결을 완성합니다

추적표의 한 행은 requirement와 acceptance를 식별하고 tests·defects·evidence를 연결합니다. REQ-01의 AC-01은 가입 성공이며 cases 파일의 경계 검사를 연결할 수 있습니다. DEF-01은 64자 입력을 거절한 이전 결함 보고서입니다. quality/trace.json은 그 결함을 참조하지만 이번 대상 버전에서 해결됐다고 선언하지 않습니다. status를 PENDING으로 두고 reason·risk·owner·due를 넣어 이어서 할 일을 정합니다.

ID가 존재하는지뿐 아니라 뜻이 맞는지도 대조합니다. TC-01은 초기 추적 파일에서는 가입 성공 제목으로 나타나지만 cases/cases.json에서는 7자 비밀번호 경계 사례입니다. 따라서 ID만 보고 합치면 잘못된 기대값을 물려받을 수 있습니다. 이번 최종 추적표는 cases/cases.json을 테스트 정의의 출처로 명시합니다. 사람이 입력·기대 결과와 계약 참조까지 읽어 연결을 확인하고, 검사기는 해당 요구사항·AC 일치를 확인합니다.

증거 경로에는 무엇을 증명하는지도 생각해야 합니다. spec/requirements.json은 합의 출처이고 cases/cases.json은 검사 설계이며 결함 보고서는 이전 관찰 자료입니다. 이 파일이 있다는 이유로 이번 실행 PASS를 기록하지 않습니다. 각 행에 이번 실행 증거가 없다는 사유와 사용자 위험을 적고, 별도 가상 모형 보고서에는 해당 모형의 관찰 범위를 표시합니다. 증거 종류를 구분하면 문서 숫자가 통과율로 오해되는 일을 줄입니다.

검사 오류를 고칠 때 계약을 보존합니다

TRACE_TESTS_EMPTY REQ-01은 요구사항 행에 검사 연결이 없다는 뜻입니다. starter의 빈 tests를 실제 cases ID로 채웁니다. TRACE_TEST_ID는 없는 ID이거나 다른 요구사항의 검사라는 뜻이므로 cases의 requirementId·acceptanceId를 비교합니다. EVIDENCE_PATH는 파일이 없거나 허용 경로 밖을 가리킨 경우입니다. 파일 이름을 가짜로 만들기보다 그 증거가 왜 필요한지 확인하고 올바른 상대 경로를 넣습니다.

문서 검사기를 통과시키려고 PENDING을 PASS로 바꾸면 UNSUPPORTED_APP_PASS가 발생합니다. 이 과제에는 실제 앱 재실행 증거가 없으므로 미검증 표시가 올바른 답입니다. 작성 후 동료에게 대상·환경·중단 조건·다음 행동을 찾아 달라고 부탁합니다. 찾는 데 오래 걸리는 항목은 계획을 간단히 다시 씁니다. 명세를 작성하는 일반 원리는 더 읽기에서 보충하고 여기서는 누적 QA 산출물의 실제 연결을 완성합니다.