QA의 핵심 결과물은 버그 리포트입니다. 어떤 상황에서, 어떤 순서로 했을 때, 무엇이 기대와 다르게 나왔는지 누구나 다시 재현할 수 있게 써야 합니다. 수업…
왜 범위를 먼저 정해야 할까
게임에는 캐릭터, 아이템, 퀘스트, 상점, 설정 메뉴, 네트워크 등 확인할 대상이 끝없이 많습니다. 여기에 기기 종류와 언어, 계정 상태까지 곱하면 경우의 수는 금방 감당할 수 없는 크기가 됩니다. 범위 없이 테스트를 시작하면 눈에 띄는 곳만 반복해서 보게 되고, 정작 위험한 곳은 놓치기 쉽습니다.
범위를 정하면 팀 전체가 같은 그림을 보게 됩니다. 개발자는 어떤 부분이 확인될지 알고, 기획자와 PM은 출시 판단에 필요한 정보가 어디까지 모일지 미리 압니다. 문제가 생겼을 때도 '여기는 범위 밖이었다'는 기록이 있으면 원인을 찾고 다음 계획을 고치기 쉬워집니다.
범위는 한 번 정하고 끝나는 것이 아닙니다. 빌드가 나올 때마다, 일정이 바뀔 때마다 다시 조정합니다. 그래서 범위 설정은 테스트 시작 전에 한 번, 진행 중에 필요할 때마다 반복되는 판단입니다.
범위를 정하는 네 가지 기준
| 기준 | 확인할 질문 | 범위를 넓히는 신호 |
|---|---|---|
| 변경 내용 | 이번 빌드에서 무엇이 새로 들어오거나 고쳐졌나 | 공통 시스템 수정, 대규모 리팩터링 |
| 위험도 | 깨지면 얼마나 심각한가 | 결제, 저장, 계정, 진행 불가 가능성 |
| 유저 영향 | 얼마나 많은 유저가 거쳐 가나 | 튜토리얼, 로그인, 메인 화면, 핵심 반복 콘텐츠 |
| 남은 시간과 인원 | 주어진 시간 안에 어디까지 볼 수 있나 | 일정 여유, 추가 인력 투입 |
네 기준은 서로 곱해서 생각하면 판단이 쉬워집니다. 변경이 있고, 위험하고, 유저가 많이 거치는 곳은 가장 먼저 깊게 봅니다. 변경이 없고, 위험이 낮고, 유저가 드물게 가는 곳은 간단히 확인하거나 이번에는 범위에서 뺍니다.
시간은 마지막 조정 장치입니다. 시간이 부족하다고 위험한 곳을 빼서는 안 되고, 우선순위가 낮은 곳부터 깊이를 줄입니다. 그래도 부족하다면 그 사실을 일찍 알려 일정이나 인원을 다시 논의하는 것이 QA의 몫입니다.
변경 내용에서 영향 범위 읽어 내기
범위를 정하는 첫 단계는 패치 노트와 변경 목록을 꼼꼼히 읽는 것입니다. 이때 바뀐 기능만 보는 것이 아니라, 그 기능과 연결된 곳까지 떠올려야 합니다. 예를 들어 아이템 가격 표시 방식이 바뀌었다면 상점뿐 아니라 우편함, 거래소, 보상 팝업처럼 가격이 보이는 모든 화면이 영향권에 들어옵니다.
연결 관계가 잘 보이지 않을 때는 개발자에게 직접 묻는 것이 가장 정확합니다. '이 수정이 다른 화면에서 쓰는 공통 코드를 건드렸는지'를 확인하면 범위를 크게 좁히거나 넓힐 수 있습니다. 이런 질문을 자주 하는 QA일수록 범위 판단이 정확해집니다.
과거 기록도 좋은 근거입니다. 이전 패치에서 버그가 자주 나왔던 기능, 수정 후 다시 깨졌던 기능은 이번에 직접 바뀌지 않았더라도 범위에 넣어 확인하는 편이 안전합니다. 버그 관리 도구에서 기능별로 과거 버그 수를 살펴보면, 어느 영역이 유독 자주 흔들리는지 감이 옵니다. 숫자로 근거를 보여 주면 범위를 넓히자는 제안도 받아들여지기 쉽습니다.
범위를 문서로 남기는 방법
- 이번 테스트의 목적을 한 문장으로 적습니다. (예: 신규 던전 추가 빌드의 출시 가능 여부 판단)
- 테스트할 범위를 기능 단위로 나열하고, 각각 깊이를 상·중·하로 표시합니다.
- 이번에 테스트하지 않을 범위와 그 이유를 적습니다.
- 테스트할 기기, 운영체제, 계정 조건 같은 환경을 정리합니다.
- 언제까지 무엇을 끝낼지 일정과 담당자를 적습니다.
- 범위가 바뀌면 바뀐 날짜와 이유를 함께 기록합니다.
가장 중요한 칸은 세 번째, 제외 범위입니다. 무엇을 보지 않았는지가 적혀 있어야 출시 판단을 내리는 사람이 남은 위험을 알 수 있습니다. 제외 이유도 '변경 없음, 이전 빌드에서 확인 완료'처럼 구체적으로 써야 설득력이 있습니다.
깊이 표시도 기준을 정해 둡니다. '상'은 정상 흐름과 예외 상황, 여러 기기까지 모두 확인, '중'은 정상 흐름과 대표적인 예외만 확인, '하'는 기능이 열리고 기본 동작이 되는지만 확인하는 식입니다. 이렇게 정의해 두면 다른 테스터가 문서를 봐도 같은 수준으로 테스트할 수 있습니다.
문서는 길 필요가 없습니다. 한두 장 안에 목적, 범위, 제외 범위, 환경, 일정이 보이면 충분합니다. 너무 길면 아무도 읽지 않아 범위를 공유한다는 목적 자체가 흐려집니다.
신입 QA가 범위 설정에서 자주 하는 실수
첫째, 새로 추가된 기능만 보는 실수입니다. 신규 콘텐츠는 눈에 잘 띄어 집중하게 되지만, 실제 큰 문제는 그 콘텐츠 때문에 기존 기능이 깨지는 곳에서 자주 나옵니다. 신규 기능 옆에는 늘 기존 기능 확인 항목을 함께 두세요.
둘째, 모든 항목을 같은 깊이로 보려는 실수입니다. 성실해 보이지만 결과적으로 위험한 곳을 충분히 파고들 시간이 부족해집니다. 깊이에 차등을 두는 것은 대충 하는 것이 아니라 시간을 위험에 맞게 배분하는 것입니다.
셋째, 범위를 혼자 정하고 공유하지 않는 실수입니다. 범위는 QA 내부 결정이 아니라 팀과의 약속입니다. 테스트 시작 전에 기획자나 PM에게 범위 문서를 보여 주고 빠진 곳이 없는지 확인받으면, 나중에 서로 다른 기대 때문에 생기는 갈등을 막을 수 있습니다.
연습할 때는 실제 출시된 게임의 업데이트 공지를 하나 골라, 내가 QA라면 어디까지 테스트할지 범위 문서를 직접 써 보세요. 바뀐 기능에서 영향권을 넓혀 가는 연습이 쌓이면 판단 속도가 빨라집니다. 직접 써 본 범위 문서가 실무 기준에 맞는지 확인받고 싶다면, SBS아카데미게임학원 게임QA 과정 상담에 그 문서를 가져와 보세요. 어떤 근거가 더 필요한지 구체적으로 짚을 수 있습니다.
자주 묻는 질문
테스트 범위는 QA 리더만 정하나요?
최종 결정은 리더나 담당자가 하는 경우가 많지만, 신입도 맡은 기능의 영향 범위를 조사해 의견을 내는 역할을 합니다. 그 과정에서 범위 판단 실력이 늘어납니다.
자동화 테스트가 있으면 범위를 고민할 필요가 줄어드나요?
반복 확인 부담은 줄지만, 자동화가 무엇을 검사하고 무엇을 검사하지 않는지 알아야 하므로 범위 판단은 여전히 필요합니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.