결함 보고서와 재현 단계

보고서는 해결을 위한 입력입니다

결함 보고서는 불편함을 표현하는 글이 아니라 다른 사람이 같은 차이를 관찰하도록 만드는 작업 자료입니다. 개발자가 입력과 시작 상태를 다시 물어야 한다면 재현 시간이 길어집니다. QA는 더 강한 표현 대신 실제 행동과 비교 근거를 붙입니다. 이번 목표는 64자 비밀번호 거절과 공백 닉네임 허용을 서로 다른 보고서로 작성하고, 수정 버전에서도 같은 기준으로 비교하는 것입니다.

제목은 기능·조건·증상을 짧게 담습니다. “가입 오류”보다 “가입 / ASCII 비밀번호 64자 / 길이 거절로 회원 미생성”이 검색과 분류에 유리합니다. 원인을 확인하기 전에는 비교 연산자 누락이라고 제목에 단정하지 않습니다. 오류 메시지가 없다고 결함이 없는 것도 아닙니다. 공백 닉네임 사례는 정상 완료 안내를 보이지만 합의한 거절 규칙에 어긋납니다.

같은 출발점과 순서를 적습니다

환경은 reports/environment.json을 연결하고 buggy 버전과 초기 회원 수를 명시합니다. 사전 조건은 행동 전에 이미 준비되어 있어야 하는 상태입니다. 초기화가 완료되었고 같은 이메일이 없으며 나머지 입력이 유효하다는 조건을 적습니다. 재현 단계에는 그 상태를 만드는 행동과 관찰을 순서대로 씁니다. 가입 뒤 실패했다는 한 문장에는 어떤 입력으로 어디를 눌렀는지 정보가 없습니다.

TC-05는 길이 64의 ASCII 입력입니다. 가입 전에 회원이 없는지 확인하고, 해당 입력을 제출한 뒤 결과와 회원 수를 확인합니다. 비밀번호 원문은 보고서에 옮기지 않고 길이와 합성 입력 생성 방법을 적습니다. TC-26은 닉네임에 스페이스 세 개를 넣고 다른 필드를 유효하게 둡니다. 빈 문자열이 아니라 길이 3의 공백이라는 조건을 명시해야 같은 증상을 재현합니다.

단계 하나에는 하나의 행동 또는 관찰을 둡니다. “초기화하고 가입하고 다시 조회”를 한 덩어리로 묶으면 어느 시점에서 전제가 깨졌는지 알기 어렵습니다. 이번 보고서에는 reset·submit·state 조회의 최소 세 단계를 적습니다. 각 재현 전 초기화가 필요하다는 조건도 reset 필드에 남깁니다. 첫 시도 뒤 생긴 데이터로 반복하면 중복 이메일 조건이 끼어 다른 결과가 날 수 있습니다.

예상과 실제는 서로 다른 출처를 씁니다

expected는 REQ-01/AC-01과 password-length 계약, 또는 REQ-04/AC-04에서 가져옵니다. actual은 reports/replay.json의 실제 HTTP 응답과 처리 전후 회원 수에서 가져옵니다. 결과를 보면서 기대값을 맞추면 결함을 정답으로 바꿀 수 있습니다. 요구사항 ID와 인수 기준 ID는 사람이 근거를 바로 찾게 하는 연결이며, 숫자를 채우는 장식이 아닙니다.

64자 입력의 기대는 VALID·완료 안내·회원 수 0에서 1입니다. buggy 관찰은 INVALID·길이 거절·회원 수 0 유지입니다. 공백 닉네임의 기대는 BLANK_NICKNAME·필수 안내·회원 수 0 유지이고 buggy는 VALID·완료 안내·회원 수 1입니다. HTTP 상태는 둘 다 200일 수 있으므로 상태 숫자만으로 성공을 판단하지 않습니다. 실제 테스트의 합격 여부는 내용과 저장 효과를 계약과 비교해 결정합니다.

응답과 저장 증거는 evidence/DEF-01.json과 DEF-02.json에 둡니다. 공개 파일에는 해당 사례의 variants 객체를 복사하고 requestId로 보고서를 연결합니다. 환경 문서와 증거 파일 경로도 상대 경로로 씁니다. 한 장의 화면 이미지만 제출하면 요청과 저장 변화가 분리되어 있을 수 있습니다. 이번 자동 증거는 요청 처리와 메모리 회원 상태의 비교이며 브라우저 이동은 포함하지 않습니다.

반복 재현과 수정 확인을 구별합니다

한 번 발생한 증상은 발견 증거입니다. 초기화 후 세 번 같은 입력을 실행해 세 번 차이가 나면 이번 환경에서 3/3 재현했다고 씁니다. 세 번의 실패만으로 모든 환경에서 발생한다고 말하지 않습니다. reproduce.py는 두 RegressionTest를 buggy·fixed 각각 세 회 실행하고 테스트 수·실패·오류·종료 코드를 repetition.json에 남깁니다. 재현 실패가 문법이나 실행 오류 때문이면 제품 결함 증거로 세지 않습니다.

buggy 명령의 nonzero는 이번 비교에서 기대한 결과입니다. Tests run 2, failures 2, errors 0을 확인합니다. 이 사실과 starter 문서 미작성 때문에 check.sh가 실패한 사실은 종류가 다릅니다. fixed 명령은 같은 두 기준을 만족해야 합니다. 조건을 느슨하게 바꾸거나 테스트를 삭제하고 통과를 얻으면 수정 효과를 확인했다고 말할 수 없습니다.

수정 확인에서는 환경과 입력을 유지하고 variant만 fixed로 바꿉니다. 두 사례 통과가 전체 회귀 통과를 뜻하지 않으므로 11개 가입 사례의 비교와 15개 blocked 범위도 함께 보여 줍니다. 실제 UI·세션·DB까지 완료라고 쓰지 않습니다. 결함 상태를 closed로 바꾸는 정책은 팀의 리뷰 기준을 따르며 이 교육용 검사기가 실무 상태 변경을 대신하지 않습니다.

영향과 처리 순서를 설명합니다

심각도는 제품과 사용자에게 발생한 영향의 크기이고 우선순위는 어떤 순서와 시점에 처리할지의 판단입니다. 64자 사용자가 가입하지 못한 영향과 출시 전 가입 규칙 수정의 필요를 분리해 적습니다. 공백 닉네임 허용은 데이터 품질과 식별에 영향을 주지만, 그것만으로 모든 계정의 정보가 유출된다고 확대하지 않습니다. 심각도 이름과 등급은 팀 정책에 맞춰 사용합니다.

제공 양식은 severityReason·priorityReason을 요구해 명칭 암기보다 근거를 연습하게 합니다. 실제로 확인한 대상·범위·우회 가능성·발생 빈도를 구분하고 아직 모르는 것은 미확인으로 씁니다. 사업 영향 수치를 추정해 쓰지 않습니다. QA는 위험 자료를 주고 개발·제품 담당과 처리 순서를 논의합니다. 담당자를 비난하는 표현은 재현과 해결에 도움이 되지 않습니다.

서로 다른 두 증상이 같은 근본 원인인지 아직 모르면 보고서를 무리하게 합치지 않습니다. 반대로 같은 사례를 이메일만 바꿔 두 건으로 세면 결함 수를 부풀립니다. 여기서는 길이 경계와 공백 정책이 서로 다른 요구 조건이므로 두 건으로 분리합니다. 동료가 독립적으로 재현하고 근거를 찾을 수 있는지를 제출 전 리뷰 기준으로 삼습니다.

읽는 사람에게 검증 한계를 보입니다

보고서 checker는 필수 필드·사례 참조·증거와 requestId의 일치를 확인합니다. 한국어 예상 문장이 계약을 올바르게 해석하는지와 영향 판단이 합리적인지는 사람이 읽습니다. TODO를 다른 긴 문장으로 바꾸어 형식만 통과시키는 것은 목표가 아닙니다. 환경·전제·행동·비교·영향이 하나의 흐름으로 이어지는지 보고서 두 개를 소리 내어 읽어 봅니다.

최종 제출에는 미검증 UI와 미제공 로그인·프로필·실시간 만료 범위를 scope에 넣습니다. 결함 원인과 수정 내용을 이해했다고 해서 실행하지 않은 화면이 정상이라고 단정하지 않습니다. 동료는 보고서만으로 시작 상태를 만들고 동일한 응답을 비교할 수 있어야 합니다. 변경을 설명하고 리뷰하는 일반 원리는 더 읽기로 이어 읽고, 이 레슨은 자신의 결함 증거와 보고서를 연결해 마무리합니다.