독학하다 막힌 게임 QA 지망생이 점검할 것

이 글과 연결된 과정게임 QA 과정 알아보기

게임 QA는 출시 전에 게임의 문제를 찾아내는 품질 관리 직무입니다. 단순히 게임을 많이 해 보는 일이 아니라, 기획서를 읽고 무엇을 확인해야 할지 정리한 뒤…

QA 독학에서 흔히 생기는 오해

가장 흔한 오해는 '게임을 많이 하고 버그를 잘 찾으면 QA가 된다'는 생각입니다. 실제 QA 업무에서는 정해진 테스트 범위를 빠짐없이 확인하는 일이 대부분입니다. 새로운 기능이 들어오면 기획서를 읽고 무엇을 확인할지 목록을 만들고, 그 목록을 하나씩 수행하며 결과를 기록합니다.

또 하나의 오해는 버그를 찾는 것이 끝이라는 생각입니다. QA의 결과물은 버그 리포트이고, 리포트를 받은 개발자가 같은 문제를 다시 만들어 볼 수 있어야 의미가 있습니다. 찾은 버그가 많아도 리포트가 모호하면 개발팀은 시간을 낭비하게 됩니다.

이 두 가지를 이해하면 독학 방향이 달라집니다. 플레이 시간을 늘리기보다 문서를 만들고 고치는 시간을 늘려야 합니다. 게임 경험은 그 문서의 재료가 됩니다.

점검 1: 테스트 케이스를 설계해 본 적이 있는가

테스트 케이스는 '어떤 조건에서, 무엇을 하면, 어떤 결과가 나와야 한다'를 한 줄씩 정리한 확인 목록입니다. 예를 들어 상점에서 아이템을 사는 기능이라면, 재화가 충분할 때, 정확히 같을 때, 부족할 때, 인벤토리가 가득 찼을 때를 각각 다른 케이스로 나눕니다.

독학하는 사람의 테스트 케이스는 정상적인 흐름만 다루는 경우가 많습니다. 실무에서 버그는 경계값(허용 범위의 끝), 순서가 뒤바뀐 조작, 네트워크가 끊기는 상황처럼 예외 쪽에서 더 많이 나옵니다. 내 케이스 목록에서 정상·경계·예외가 균형 있게 들어 있는지 확인해 보세요.

케이스마다 사전 조건, 수행 절차, 기대 결과, 실제 결과 칸이 있는지도 함께 보세요. 이 형식이 갖춰져야 다른 사람이 같은 케이스를 그대로 수행할 수 있습니다.

점검 2: 버그 리포트가 재현 가능한가

좋은 버그 리포트는 처음 보는 사람도 그대로 따라 하면 같은 문제를 볼 수 있어야 합니다. 그러려면 제목, 환경, 재현 절차, 기대 결과, 실제 결과, 발생 빈도, 첨부 자료가 들어가야 합니다.

• 제목만 읽어도 어디서 무슨 문제가 생겼는지 알 수 있는가
• 기기, 운영체제, 빌드 버전 같은 환경 정보가 있는가
• 재현 절차가 번호를 매긴 단계로 빠짐없이 적혀 있는가
• 기대 결과와 실제 결과가 구분되어 있는가
• 매번 일어나는지, 가끔 일어나는지 빈도를 적었는가
• 스크린샷이나 짧은 영상을 첨부했는가

지금까지 쓴 리포트를 며칠 뒤에 다시 읽고, 내가 직접 재현해 보세요. 글만 보고 재현이 안 된다면 절차에 빠진 단계가 있는 것입니다. 심각도(문제가 게임에 미치는 영향의 크기)를 어떤 기준으로 정했는지도 함께 적어 두면 판단력을 보여 줄 수 있습니다.

점검 3: 테스트 범위를 스스로 판단할 수 있는가

실무에서는 시간이 한정되어 있어 모든 것을 다 테스트할 수 없습니다. 이번 업데이트에서 바뀐 부분이 무엇인지, 그 변경이 영향을 줄 수 있는 다른 기능은 무엇인지 판단해 우선순위를 정해야 합니다. 이미 확인한 기능이 새 변경 때문에 다시 망가지지 않았는지 확인하는 회귀 테스트도 이 판단에 포함됩니다.

독학으로 이 감각을 키우려면, 게임 업데이트 공지를 읽고 '내가 QA라면 무엇을 먼저 확인하겠는가'를 적어 보는 연습이 좋습니다. 바뀐 기능과 영향 범위를 나눠 적으면, 테스트 범위를 정하는 사고 과정이 문서로 남습니다.

범위를 정할 때는 이유도 함께 적으세요. 결제와 관련된 기능은 문제가 생기면 피해가 커서 먼저 확인하고, 화면 문구 수정처럼 영향이 작은 변경은 뒤로 미루는 식입니다. 이런 우선순위 근거가 있으면 면접에서 '시간이 부족하면 무엇부터 테스트하겠느냐'는 질문에도 자신 있게 답할 수 있습니다.

점검 결과를 반영한 새 독학 계획

1. 한 게임의 기능 하나(상점, 우편함, 친구 추가 등)를 골라 정상·경계·예외로 나눈 테스트 케이스를 만듭니다.
2. 케이스를 실제로 수행하며 결과를 기록하고, 발견한 문제를 형식을 갖춘 버그 리포트로 씁니다.
3. 업데이트 공지 하나를 골라 테스트 범위와 우선순위를 정하는 문서를 써 봅니다.
4. 스프레드시트로 케이스와 결과를 관리하는 표를 만들어 진행률을 확인해 봅니다.
5. 완성한 자료를 묶어 QA 포트폴리오 초안을 만들고 다른 사람에게 재현을 부탁해 봅니다.

공개된 게임으로 연습할 때는 이용 약관을 지키고, 다른 이용자에게 피해를 주는 방식의 테스트는 하지 않아야 합니다. 찾은 문제를 외부에 공개할 때도 신중해야 합니다. 이런 태도 자체가 QA에게 필요한 직업윤리입니다.

작은 인디게임이나 친구가 만든 프로젝트를 테스트해 주는 것도 좋은 방법입니다. 개발자에게 리포트를 직접 전달하고 반응을 들으면, 내 리포트가 실제로 도움이 되는지 확인할 수 있습니다.

혼자서 확인하기 어려운 부분 채우기

QA 실력은 결국 '다른 사람이 내 문서를 쓸 수 있는가'로 판단됩니다. 그래서 독학의 한계는 내 문서를 써 볼 사람이 없다는 데 있습니다. 스터디에서 서로의 리포트로 재현 연습을 하거나, 테스트를 부탁할 개발자를 찾는 등 문서를 검증받을 방법을 꼭 만들어 두세요.

지금 만든 테스트 케이스와 리포트가 실무 기준에서 어느 정도인지, 포트폴리오로 무엇을 보강해야 할지 판단이 어렵다면 SBS아카데미게임학원 게임QA 과정 상담에서 자료를 함께 보며 보완 방향을 정해 볼 수 있습니다.

자주 묻는 질문

가까운 캠퍼스에서 게임 QA 알아보기

사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.

함께 읽으면 좋은 글