게임 QA 프로세스를 체계화하는 법: 재현 가능한 버그와 우선순위 기준
인디 팀도 바로 적용할 수 있는 게임 테스트 흐름과 버그 보고서 작성법 그리고 영향도·긴급도를 분리한 우선순위 분류 기준을 정리합니다.
QA는 ‘버그를 찾는 일’보다 ‘판단을 반복 가능하게 만드는 일’이다
게임 테스트가 막히는 이유는 버그 수가 많아서만이 아니다. 같은 현상을 서로 다른 이름으로 등록하거나 재현 조건이 빠져 개발자가 확인하지 못하거나 긴급하지 않은 수정이 출시를 막는 문제가 더 자주 발생한다.
작은 팀이라도 테스트 범위, 버그 보고서 형식, 우선순위 판단 기준을 합의해 두면 QA가 개인의 감각에 의존하지 않는다. 핵심은 발견부터 수정 확인까지의 흐름을 한 가지 규칙으로 운영하는 것이다.
flowchart LR
A[테스트 범위 정의] --> B[빌드 배포와 환경 기록]
B --> C[탐색 테스트와 체크리스트 수행]
C --> D[재현 가능한 버그 등록]
D --> E[중복 확인과 우선순위 분류]
E --> F[수정 작업]
F --> G[수정 확인과 회귀 테스트]
G --> H{릴리스 기준 충족?}
H -- 아니오 --> C
H -- 예 --> I[릴리스 후보 승인]테스트 전에 정할 세 가지
1. 이번 빌드에서 확인할 범위
모든 기능을 매번 깊게 검사하면 팀의 시간이 빠르게 소진된다. 빌드마다 변경된 기능과 그 기능이 영향을 줄 수 있는 영역을 먼저 적는다. 예를 들어 전투 보상 계산을 수정했다면 보상 화면만이 아니라 저장·불러오기, 인벤토리 한도, 업적 조건, 상점 경제까지 확인 대상이 될 수 있다.
테스트 범위는 작업 관리 도구나 릴리스 노트에 다음처럼 짧게 남기면 충분하다.
빌드: 0.8.14
변경 영역: 전투 보상, 장비 드롭, 저장 데이터 마이그레이션
필수 확인: 일반 전투, 보스 전투, 인벤토리 가득 참, 저장 후 재접속
제외 범위: 신규 맵 조명 품질2. 테스트 환경
버그는 특정 플랫폼, 입력 장치, 언어, 저장 데이터 상태에서만 나타날 수 있다. 등록 시점에 환경을 기록하지 않으면 나중에 재현 비용이 커진다. 최소한 빌드 번호, 플랫폼, 운영체제 또는 기기, 입력 방식, 신규·기존 저장 데이터 여부를 남긴다.
3. 릴리스 차단 기준
‘치명적인 버그는 고친다’는 표현만으로는 판단하기 어렵다. 출시를 멈추는 조건을 미리 정해야 일정 논쟁을 줄일 수 있다. 예를 들면 다음과 같다.
- 진행 불가, 저장 데이터 손상, 결제 오류는 미해결 상태로 출시하지 않는다.
- 지원 플랫폼에서 반복적으로 발생하는 충돌은 원인 확인 또는 우회책 없이 출시하지 않는다.
- 화면 깨짐이나 오탈자는 출시 차단 사유가 아닐 수 있으나 스토어 심사·연령 등급·법적 표기와 관련되면 별도 기준으로 올린다.
재현 가능한 버그 보고서 작성법
좋은 보고서는 개발자가 질문을 덜 하게 만든다. 원인을 추측해 단정하기보다 관찰한 사실과 기대한 동작을 분리해 적는 편이 정확하다.
권장 필드
| 항목 | 작성 내용 |
|---|---|
| 제목 | 기능과 증상을 함께 적는다. 예: 보스 처치 후 보상 창에서 입력이 멈춤 |
| 환경 | 빌드 번호, 플랫폼, 기기, 입력 장치, 저장 데이터 상태 |
| 재현 절차 | 처음부터 따라 할 수 있는 번호 목록 |
| 실제 결과 | 화면, 입력, 데이터에 실제로 발생한 현상 |
| 기대 결과 | 플레이어 관점에서 정상이어야 하는 동작 |
| 재현율 | 10회 중 발생 횟수처럼 측정 가능한 값 |
| 증거 | 영상, 스크린샷, 로그, 저장 파일, 오류 코드 |
| 영향 범위 | 진행, 데이터, 성능, 접근성, 플랫폼 심사 등에 미치는 영향 |
다음은 간단한 등록 예시다.
제목: 보스 처치 후 보상 창에서 입력이 멈춤
환경: 0.8.14 / Windows 11 / Xbox 컨트롤러 / 기존 저장 데이터
재현 절차:
1. 3장 보스 전투를 시작한다.
2. 보스를 처치한다.
3. 보상 창이 열린 뒤 A 버튼을 누른다.
실제 결과: 선택 강조 표시는 움직이지만 확인과 취소 입력이 작동하지 않는다.
기대 결과: 보상을 선택하거나 취소할 수 있어야 한다.
재현율: 8/10
영향: 보스 전투 완료 후 진행 불가. 게임 재시작 필요.
첨부: 재현 영상, Player.log, 저장 파일‘가끔 멈춘다’보다 ‘8/10회 발생하며 재시작이 필요하다’가 훨씬 빠른 판단을 돕는다. 영상이 있더라도 재현 절차를 생략하지 않는 것이 좋다. 영상은 현상을 보여 주고 절차는 개발자가 같은 상태를 만드는 데 쓰인다.
영향도와 긴급도를 분리해 우선순위 정하기
버그 우선순위를 심각도 하나로만 정하면 논의가 길어진다. 플레이어와 제품에 미치는 영향인 영향도와 지금 처리해야 하는 이유인 긴급도를 분리하면 기준이 선명해진다.
영향도: 문제가 얼마나 큰가
| 등급 | 기준 | 예시 |
|---|---|---|
| S1 치명적 | 진행 불가, 데이터 손상, 반복 충돌, 결제 실패 | 저장 파일이 사라짐, 메인 퀘스트 완료 불가 |
| S2 높음 | 핵심 기능이 크게 훼손되지만 우회 가능 | 보상 수령 실패 후 재시작하면 진행 가능 |
| S3 보통 | 특정 상황에서 기능이나 품질이 저하 | 일부 해상도에서 UI가 겹침 |
| S4 낮음 | 플레이 흐름에 영향이 작은 결함 | 오탈자, 드물게 발생하는 미세한 애니메이션 오류 |
긴급도: 언제 처리해야 하는가
| 등급 | 기준 |
|---|---|
| U1 즉시 | 출시 차단, 라이브 장애, 데이터 위험, 심사 반려 가능성 |
| U2 다음 빌드 | 다음 테스트 또는 기능 완성 전에 해결해야 함 |
| U3 계획 반영 | 일정과 다른 작업의 영향에 따라 처리 가능 |
| U4 보류 | 현재는 비용 대비 효과가 낮아 알려진 이슈로 관리 |
최종 우선순위는 단순히 S1이면 무조건 최상위라고 고정하기보다 출시 단계와 발생 범위를 함께 본다. 예를 들어 출시 직전의 S3라도 모든 플레이어의 첫 화면을 가리는 문제라면 U1이 될 수 있다. 반대로 특정 개발자 도구에서만 나타나는 S2는 릴리스 빌드에 영향이 없다면 U3로 둘 수 있다.
분류 회의에서 확인할 질문
버그 분류 회의는 길게 열기보다 등록된 항목을 빠르게 같은 기준으로 정렬하는 시간이 되어야 한다. 각 항목마다 아래 질문에 답하면 충분하다.
- 플레이어가 정상 진행을 계속할 수 있는가?
- 저장 데이터, 결제, 개인정보, 플랫폼 정책에 위험이 있는가?
- 발생 조건은 흔한가? 재현율과 영향을 받는 플랫폼은 어떤가?
- 우회 방법이 있는가? 있다면 플레이어가 쉽게 알 수 있는가?
- 이번 빌드의 변경 사항과 연결되는가?
- 수정했을 때 회귀 위험이 큰 영역은 어디인가?
이 질문은 QA가 개발 우선순위를 독단적으로 정하기 위한 것이 아니다. 기획, 개발, QA가 같은 사실을 보고 트레이드오프를 결정하도록 돕는 장치다.
회귀 테스트는 ‘수정한 곳’보다 ‘깨질 수 있는 곳’을 본다
버그가 수정되면 해당 재현 절차를 다시 실행하는 것은 기본이다. 그러나 수정으로 바뀐 코드나 데이터 흐름이 다른 기능에 영향을 줄 수 있으므로 회귀 테스트 범위도 함께 정해야 한다.
예를 들어 드롭 보상 중복 지급을 고쳤다면 다음을 함께 확인할 수 있다.
- 일반 전투와 보스 전투의 보상 수량
- 보상 수령 후 저장과 재접속
- 인벤토리 한도 초과 처리
- 멀티플레이 동기화 또는 서버 재접속
- 업적과 퀘스트의 보상 조건
수정 확인 결과는 ‘고정됨’ 한마디로 끝내지 않는다. 확인한 빌드, 환경, 재현 절차 결과, 추가로 실행한 회귀 항목을 남긴다. 재현하지 못했을 때도 닫지 말고 ‘재현 불가’ 상태로 두며 테스트한 환경과 횟수를 기록한다.
작은 팀을 위한 최소 운영 규칙
처음부터 복잡한 QA 도구나 지표를 도입할 필요는 없다. 다음 네 가지부터 일관되게 지키면 체계가 생긴다.
- 모든 버그에 빌드 번호와 재현 절차를 붙인다.
- 중복 버그는 닫지 말고 대표 이슈에 연결한다.
- 영향도와 긴급도를 각각 기록한다.
- 수정 완료 전에는 담당자가 완료 후에는 QA가 상태를 바꾼다.
정기적으로 ‘재현 불가’, ‘보류’, ‘수정 완료’ 항목을 짧게 점검하면 목록이 쌓여 관리 불능이 되는 일도 줄어든다. 좋은 QA 프로세스는 더 많은 버그를 적는 데서 끝나지 않는다. 팀이 같은 위험을 같은 언어로 판단하고 제한된 시간 안에 플레이어 경험을 가장 크게 개선할 문제부터 해결하게 만드는 데 목적이 있다.
