분기형 스토리 테스트 방법: 상태 매트릭스, 경로 커버리지와 회귀 테스트 완전 템플릿

분기형 스토리 테스트는 “모든 루트를 한 번씩 플레이하기”만으로 완료할 수 없습니다. 경로 수는 빠르게 늘어나며, 많은 결함은 상태 조합에서 발생합니다. 더 신뢰할 수 있는 방법은 먼저 상태 전이를 검증한 다음, 위험도에 따라 우선순위를 정한 경로로 핵심 조합을 커버하고, 마지막으로 발견한 결함을 각각 회귀 테스트 케이스로 만드는 것입니다.

읽는 지점이 없는 변수는 삭제하고, 출처가 없는 값을 읽는 조건에는 그 출처를 보완합니다.

각 테스트 케이스에는 시작 노드, 사전 상태, 조작, 예상 다음 노드, 상태 변화, 스크린샷 또는 로그를 기록합니다. 시간제한 선택은 시간 초과, 제한 시간 경계에서의 입력, 반복 클릭도 테스트해야 합니다. 미디어 노드는 로딩 실패와 복구를 테스트해야 합니다.

관계 수치의 높고 낮음과 열쇠 보유 여부, QTE 성공·실패와 단서 확보 여부처럼 두 변수의 핵심 조합을 우선적으로 커버합니다. 위험도가 높은 모든 조합의 테스트를 대체할 수는 없지만, 비교적 적은 비용으로 흔한 조건 오류를 발견할 수 있습니다.

기본 메인 루트, 각 엔딩으로 가는 최단 루트, 자원이 가장 적은 루트, 모든 QTE에 실패하는 루트, 저장/챕터 복구 루트, 과거의 심각한 결함에 대한 회귀 테스트 루트입니다.

버전/플랫폼:
시작 노드와 사전 상태:
재현 단계:
실제/예상 결과:
발생 빈도:
스크린샷 또는 로그:

출시 전에는 최소한 모든 심각한 결함이 종결되었는지, 각 엔딩을 두 번 재현할 수 있는지, 저장 데이터 업그레이드와 챕터 이동을 검증했는지 확인하고, 아직 커버하지 못한 조합의 위험을 명확히 밝혀야 합니다.

스토리 그래프만으로 테스트하면 플레이어가 A에서 B로 이동했다는 사실은 알 수 있지만, 어떤 변수가 기록되었는지는 알 수 없습니다. 상태 사전은 변수의 자료형, 기본값, 유효 범위, 쓰기 및 읽기 노드를 정의합니다. 변수 이름이나 범위가 바뀔 때마다 테스트 케이스도 함께 업데이트해야 합니다.

관계 수치는 특히 관리하기 어렵습니다. 단순히 “신뢰 증가”라고 쓰지 말고, 얼마에서 얼마로 변하는지, 상한이 있는지, 어떤 장면에서 읽는지, 인터페이스가 어떻게 피드백을 주는지 적어야 합니다. 엔딩 조건이 trust > 3이라면 경계값인 3과 4를 모두 테스트해야 합니다.

정상적인 선택 외에도 반복 클릭, 카운트다운 경계에서의 입력, 네트워크 단절, 백그라운드 전환, 미디어 로딩 실패, 빠른 건너뛰기, 언어 변경, 저장 데이터 복원을 테스트해야 합니다. 흔한 결함은 스토리가 잘못된 것이 아니라 비정상 조작 후 상태가 중복 기록되거나 아예 기록되지 않는 것입니다.

각 테스트 케이스는 재현 가능한 저장 데이터에서 시작합니다. “3장에 들어가서 왼쪽을 클릭한다”라고만 적어서는 재현하기에 부족합니다. 3장이 서로 다른 관계와 아이템을 이어받을 수 있기 때문입니다.

P0는 메인 루트, 모든 엔딩, 저장 데이터 손상, 콘텐츠 안전성을 커버합니다. P1은 중요한 관계, 아이템, QTE, 챕터 이동을 커버합니다. P2는 개별 대사와 위험도가 낮은 시각적 차이를 커버합니다. 매 커밋마다 노드 테스트와 P0 스모크 테스트를 실행하고, 출시 후보 버전에서는 P1/P2를 실행합니다.

커버리지는 방문한 노드 수만으로 보고하지 마세요. 상태 전이, 엔딩 조건, 비정상 상황에서의 복구, 테스트하지 않은 조합도 함께 보고해야 합니다. 노드를 방문했다고 해서 그 노드의 모든 조건이 올바르다는 뜻은 아닙니다.

문제를 하나 수정할 때마다 원래의 사전 상태와 조작을 회귀 테스트 모음에 추가합니다. 문제가 챕터 이동 시의 기본값에서 비롯되었다면 이후 모든 버전에서 해당 상황을 검증해야 합니다. 그렇지 않으면 리팩터링 후 같은 유형의 오류가 다시 나타납니다.

예를 들어 플레이어가 N05에서 열쇠를 얻었는데, N08로 이동한 뒤 시스템이 기본값인 has_key=false를 사용하는 경우입니다. 기록에는 전체 진행 과정과 챕터 이동 과정의 비교, 저장 데이터 버전, 로그가 포함되어야 합니다. 수정 후에는 새 저장 데이터, 기존 저장 데이터, 챕터 재시작을 각각 검증합니다.

보고서에는 통과한 엔딩, 핵심 경로, 출시를 막는 결함, 남은 위험, 버전을 나열합니다. “전체 흐름 테스트 완료”처럼 감사할 수 없는 표현은 사용하지 마세요. 목표는 버그가 없다고 선언하는 것이 아니라, 어떤 인과관계를 검증했고 어떤 조합이 여전히 확인되지 않았는지 의사결정자가 알 수 있게 하는 것입니다.

메인 루트의 첫 플레이, 결제 진입점, 되돌릴 수 없는 선택, 최종 엔딩은 최고 위험 등급으로 분류해 매 빌드마다 테스트합니다. 흔한 분기 루트와 주요 합류 지점은 매일 회귀 테스트하고, 드문 조합은 버전별로 번갈아 테스트할 수 있습니다. 우선순위는 사용자 영향, 발생 가능성, 수정 비용, 과거 결함을 함께 고려해 결정해야 하며, 자동화하기 가장 쉬운 루트만 테스트해서는 안 됩니다.

각 테스트 케이스에는 초기 저장 데이터, 조작 단계, 예상 상태, 눈에 보이는 결과, 정리 방법을 명확히 적습니다. 실패 시에는 빌드 번호, 노드, 상태 스냅샷, 스크린샷 또는 영상, 최단 재현 경로를 보존합니다. “가끔 잘못된 엔딩으로 이동한다”라고만 설명하면 개발자는 조건 계산, 저장 데이터 마이그레이션, 미디어 로딩 중 어디에 문제가 있는지 파악하기 어렵습니다.

상태를 추가하거나 노드 이름을 바꾸거나 기본값을 조정할 때는 출시 버전의 기존 저장 데이터를 새 빌드에서 불러와 누락된 필드가 어떻게 채워지는지, 해금된 콘텐츠가 유지되는지, 이전 저장 시점으로 돌아갈 때 중요한 마이그레이션을 건너뛰는지 확인합니다. 새 저장 데이터가 테스트를 통과했다고 해서 업그레이드가 안전하다는 뜻은 아닙니다. 호환할 수 없다면 영향을 미리 설명하고 이해하기 쉬운 처리 방안을 제공해야 합니다.

인수 회의에서는 근거가 있는 결과만 다룹니다. 어떤 경로를 실행했는지, 어떤 상태 경계값을 커버했는지, 남은 공백을 받아들일 수 있는 이유는 무엇인지 확인합니다. 포괄적인 통과율 하나로 안도감을 주는 것보다 커버하지 못한 영역을 명확히 나열하는 편이 더 가치 있습니다.