Devin.KR

검증 범위와 추적표

65분 안팎

학습 목표

인수 기준과 테스트·결함의 연결을 설계합니다.

개념

검사가 있다는 사실과 범위를 연결합니다

테스트가 열 개라는 말만으로 가입과 프로필 정책을 얼마나 확인할 수 있는지 알 수 없습니다. 열 개 모두 가입 성공의 입력만 바꾼 사례일 수 있습니다. 추적표는 요구사항과 인수 기준, 검증 사례 사이의 연결을 보여 주는 문서입니다. 변경이 생겼을 때 어느 사례를 다시 읽어야 할지 찾고 기준이 하나도 연결되지 않은 부분을 발견하는 데 사용합니다. 테스트 수를 늘리는 목표와 요구를 검증할 준비는 다릅니다.

이번 모듈의 추적표는 실행 보고서가 아닙니다. 실제 회원 앱을 아직 사용하지 않았으므로 테스트 상태는 planned 또는 not-run입니다. 추적표에 연결되었다고 passed로 쓰지 않습니다. 실행 결과는 뒤 모듈에서 환경과 증거를 함께 기록합니다. 계획 단계에서 이 구분을 명확히 해 두면 나중에 ‘설계는 했지만 실행하지 않은 조건’을 검증 완료로 잘못 보고하는 일을 줄일 수 있습니다.

연결의 최소 단위는 인수 기준입니다

REQ-01이라는 요구사항 밑에 가입 성공과 저장 효과 기준이 따로 있다면 요구사항 ID만 붙인 테스트 한 개로 모두 확인한다고 결론 내리지 않습니다. 어떤 AC를 확인할지 함께 적습니다. 이 미션에서는 requirementId, acceptanceId, testId를 한 연결 행에 씁니다. 같은 테스트가 여러 기준을 확인할 수 있고 같은 기준에 여러 테스트가 필요할 수도 있습니다. 하나의 ID와 하나의 ID를 항상 일대일로 연결하는 표가 아닙니다.

{
  "tests": [
    {"id": "TC-01", "title": "가입 성공과 저장 결과 확인", "mode": "manual", "status": "planned", "reason": "앱 실행 전 검증 계획입니다."}
  ],
  "links": [
    {"requirementId": "REQ-01", "acceptanceId": "AC-01", "testId": "TC-01", "defectIds": []}
  ]
}

tests는 테스트 식별자 목록이고 links는 관계 목록입니다. 따라서 TC-99라는 이름을 links에 적었는데 tests에는 없다면 검증할 대상을 찾을 수 없습니다. 제목에 REQ-01이라는 글자가 들어가는 것만으로 참조가 만들어지지 않습니다. 관계를 별도 필드에 기록해야 검사기와 다음 작성자가 같은 연결을 따라갈 수 있습니다. 숫자를 정렬한 화면이 아니라 ID와 소속 기준을 기준으로 검토합니다.

의미 없는 연결을 찾아냅니다

TC-01이 가입 성공만 확인하는데 타인 프로필 거절 기준 AC-08에 연결해 놓으면 모든 ID가 실재해도 의미가 맞지 않습니다. 자동 검사기는 그 기준이 해당 요구사항에 속하는지 확인하지만 테스트 제목이 기준을 충분히 검증하는지는 읽지 못합니다. 사람은 Given·When·Then과 테스트 제목 및 검증 계획을 함께 봅니다. 연결은 많을수록 좋은 것이 아니라 필요한 관찰과 행동이 맞아야 합니다.

한 기준에 UI 안내와 저장 효과가 함께 있으면 테스트 계획에 둘을 모두 확인할 방법을 설명합니다. 화면에서 문구를 읽는 수동 테스트만으로 저장 무변경을 확인한다고 말하지 않습니다. 재조회나 데이터 확인이 필요하다는 메모를 추가합니다. 아직 실행 방법을 모르면 자동화 후보로 분류하고 무엇을 준비해야 하는지 reason에 씁니다. 현재 구현을 알고 있는 척하기보다 실행 전에 빠진 관찰 수단을 드러내는 것이 유용합니다.

수동·자동화 후보·제외를 구분합니다

manual은 사람이 수행할 검증 계획입니다. automation-candidate는 반복 비용이나 위험을 근거로 자동화할 후보이며 자동화 코드가 완성되었다는 뜻이 아닙니다. excluded는 현재 범위에서 수행하지 않는 항목입니다. 이 값들은 테스트의 실행 통과 여부와 다른 축입니다. 수동 계획도 실패할 수 있고 자동화 코드가 있어도 실행하지 않은 상태일 수 있습니다. mode와 status를 나누어 적는 이유입니다.

가입·로그인·본인 수정의 핵심 흐름은 반복되는 회귀 후보입니다. 가입 안내의 자연스러운 문장은 수동 검토를 병행할 수 있습니다. 실제 이메일 전달이나 비밀번호 재설정은 이번 교육용 합의에 포함하지 않았으므로 이 미션의 검증 완료 범위로 보고하지 않습니다. 후속 후보로 남기려면 제외 사유와 다시 검토할 조건을 적습니다. ‘시간 부족’만 쓰면 무엇을 감수하는지 드러나지 않습니다.

excluded 행도 기준과 연결되어 있으면 구조상 연결된 것으로 셀 수 있습니다. 그것을 ‘검증된 요구사항’ 수에 더하지 않습니다. 연결 완전성은 연결이 존재하는가이고 실행 커버리지는 선택한 범위에서 어떤 사례를 수행했는가입니다. 위험 관점의 충분성은 그 사례들이 중요한 실패를 다루는가입니다. 같은 백분율로 합치면 계획, 실행, 판단의 차이가 사라집니다. 이번 checker의 PASS는 첫 번째 범주만 제한적으로 확인합니다.

결함은 관찰한 뒤 연결합니다

예상 결과와 실제 결과가 다르면 해당 테스트와 기준을 붙여 결함을 기록합니다. 결함 ID가 생긴 뒤 defectIds에 연결하면 변경 후 어떤 사례를 재실행할지 찾을 수 있습니다. 지금은 앱 미실행 단계이므로 빈 배열을 유지합니다. 예상 위험에 DEF-01을 붙이면 아직 발견하지 않은 문제를 실제 결함처럼 보이게 만듭니다. 위험은 테스트의 reason이나 질문의 impact에 남기는 편이 정확합니다.

결함 수정 뒤에도 원래 기준과 테스트 ID는 유지할 수 있습니다. 실행 결과와 증거가 갱신되는 것입니다. 요구 자체가 바뀌었다면 새 합의 버전을 기록하고 기대 결과를 검토해야 합니다. 지난 실패를 통과로 덮어써서 변경 전후를 알 수 없게 만들지 않습니다. 실제 실행 기록을 어떻게 남길지는 결함 재현 모듈에서 다루며 이번에는 연결 구조와 미실행 상태만 준비합니다.

변경 영향 분석을 연습합니다

‘가입 후 자동 로그인’으로 정책이 변경된다고 가정하면 가입 성공 기준, 로그인 흐름의 사전 조건, 해당 테스트 계획이 영향을 받습니다. 가입 제목만 고쳐서는 충분하지 않습니다. REQ-01에서 AC-01, TC-01을 따라가고 flow의 다음 단계도 읽습니다. 타인 수정 거절 정책이 그대로라면 그 기준은 유지할 수 있지만 새 세션 생성 흐름의 영향이 있는지는 별도로 판단합니다. 추적표는 후보를 찾는 도구이며 최종 영향 판단을 대신하지 않습니다.

닉네임 길이 질문이 보류되어 있다면 길이 경계 테스트는 아직 확정할 수 없습니다. 보류 질문과 관련 요구사항을 연결하면 왜 해당 사례가 없는지 설명할 수 있습니다. 추적표를 제출할 때 미확정 조건을 따로 읽고 다음 담당자가 질문을 해결한 뒤 사례를 추가할 수 있도록 전달합니다. 모든 행을 억지로 채우기보다 준비된 범위와 미해결 범위를 구분하는 보고가 필요합니다.

실패를 고친 뒤에도 읽습니다

‘존재하지 않는 연결’은 REQ, AC, TC 중 어느 ID가 없는지 확인하라는 메시지입니다. 세 ID가 모두 있더라도 AC가 다른 REQ 아래에 있으면 잘못된 소속입니다. ‘연결되지 않은 인수 기준 존재’는 기준이 있는데 유효한 links 행이 없다는 뜻입니다. starter의 TC-99를 tests에 무작정 추가하지 말고 원래 의도한 검증 제목이 TC-01인지 먼저 읽습니다. 이름만 맞추면 의미 오류를 감출 수 있습니다.

최종 리뷰는 기준 한 개를 임의로 골라 출처, 조건, 결과, 테스트 계획까지 거꾸로 따라가는 방식으로 합니다. 계획을 실행 완료로 표시한 행이 없는지, 거절의 무변경을 관찰할 방법이 있는지, 제외 근거를 다른 사람에게 설명할 수 있는지 확인합니다. 미션 형식 검사가 끝나면 이 네 spec 파일을 다음 테스트 설계 모듈의 출발점으로 보존합니다. 작업을 설명하는 기록의 원칙은 더 읽기의 포트폴리오 장에서 확장합니다.

따라하기

테스트 목록과 관계를 나누어 작성

traceability.json의 tests에는 TC-01부터 TC-08까지 각 기준의 검증 제목을 둡니다. mode는 manual, status는 planned, reason에는 관찰할 지점과 앱 미실행 사실을 적습니다. links의 REQ·AC·TC가 서로 맞는지 읽습니다. starter의 TC-99는 의도한 가입 성공 테스트 TC-01로 고칩니다. defectIds는 모두 []로 유지합니다.

연결 누락과 없는 ID 재현

trace-review.py에 아래 축소 예시를 저장하고 python3 trace-review.py로 실행합니다. 연결된 AC와 참조한 TC를 각각 비교합니다. 출력 두 줄은 제품 결함이 아니라 추적 데이터의 결손입니다. 없는 TC와 미연결 AC는 다른 오류라는 점을 확인합니다.

criteria = {"AC-01", "AC-02"}
tests = {"TC-01"}
links = [{"acceptanceId": "AC-01", "testId": "TC-99"}]
for link in links:
    if link["testId"] not in tests:
        print("없는 테스트: " + link["testId"])
linked = {link["acceptanceId"] for link in links}
for aid in sorted(criteria - linked):
    print("미연결 기준: " + aid)

실행 결과

없는 테스트: TC-99
미연결 기준: AC-02

범위와 후보 근거 검토

TC-01은 가입 성공의 UI와 저장 효과를 함께 관찰하는 manual 계획으로 둡니다. TC-06 로그인 거절은 automation-candidate로 바꾸고 인증 세션 미생성을 반복 검증할 후보라는 reason을 씁니다. 모드가 바뀌어도 status는 planned를 유지합니다. 보류 질문 두 건과 실제 이메일 발송 제외를 이번 범위 설명에 적습니다.

미션 형식 검사 실행

starter 압축을 푼 폴더에서 bash check.sh를 실행합니다. 첫 FAIL의 파일·ID부터 수정하고 반복합니다. solution 압축을 별도 폴더에 풀어 같은 명령을 실행하면 형식 PASS와 한계 안내 두 줄을 확인할 수 있습니다. 여기서는 해답 폴더에서 직접 실행한 출력을 제시합니다. 본인 문서의 의미가 합의와 맞는지는 README의 사람 리뷰 기준으로 확인합니다.

bash check.sh

실행 결과

PASS 요구사항·질문·추적 연결·흐름 형식
주의: 앱 동작과 합의의 타당성은 검사하지 않았습니다.

확인 문제

실습

spec/traceability.json에 기준별 REQ→AC→TC 연결을 제출합니다. 테스트 제목·수동/자동화 후보·계획 상태·근거를 적고 모든 AC를 연결합니다. defectIds는 []로 둡니다. 보류·제외 사유와 미실행 사실을 설명한 뒤 미션 폴더에서 bash check.sh를 실행합니다. PASS 뒤에도 연결의 의미와 합의 일치를 사람 리뷰로 확인합니다.

더 읽기

면접 질문

  • 가입 폼의 테스트 조건을 정하는 과정을 설명해 주시면 됩니다.