QA 포트폴리오는 실제 게임 빌드를 테스트한 기록으로 만듭니다. 수업에서 제공되는 테스트용 빌드나 출시된 게임을 대상으로 테스트 계획, 테스트 케이스, 버그 …
게임 QA는 즐기는 사람이 아니라 확인하는 사람입니다
QA는 품질 보증(Quality Assurance)의 줄임말입니다. 게임 QA는 개발 중인 빌드를 정해진 기준에 따라 플레이하며 오류를 찾고, 그 오류가 고쳐졌는지 다시 확인합니다. 여기서 빌드는 테스트를 위해 만들어 둔 게임의 특정 버전을 말합니다.
유저는 재미있는 부분을 반복하지만, QA는 지루한 부분도 반복합니다. 같은 버튼을 수십 번 누르고, 일부러 이상한 순서로 메뉴를 열고, 네트워크를 끊어 보기도 합니다. 이 차이를 이해하고 시작해야 준비 방향이 맞습니다.
비전공자에게 유리한 점은 전공 지식보다 꼼꼼함, 기록 습관, 소통 능력이 먼저 평가된다는 것입니다. 사무직, 서비스직, 고객 응대 경험처럼 실수를 찾고 정확히 전달해 본 경험은 QA 업무와 직접 연결됩니다.
비전공자가 먼저 채워야 할 빈칸은 용어와 환경입니다
현장에서는 크래시, 재현율, 회귀 테스트, 우선순위 같은 용어가 매일 쓰입니다. 크래시는 게임이 갑자기 꺼지는 현상이고, 회귀 테스트는 수정 후 다른 곳이 새로 망가지지 않았는지 다시 보는 테스트입니다. 이런 용어를 정확히 알면 면접에서도 대화가 훨씬 수월해집니다.
테스트 환경에 대한 이해도 필요합니다. 같은 게임도 기기, 운영체제, 해상도, 네트워크 상태에 따라 다르게 동작합니다. 그래서 버그를 기록할 때 어떤 환경에서 발생했는지를 함께 적는 습관이 중요합니다. 집에 있는 스마트폰과 PC 정도만으로도 환경 차이를 비교하는 연습은 충분히 할 수 있습니다.
1단계: 출시된 게임으로 테스트하는 눈을 기릅니다
첫 연습은 이미 출시된 게임 하나를 정해 기능 단위로 나눠 보는 것입니다. 로그인, 튜토리얼, 상점, 설정, 인벤토리처럼 화면 단위로 쪼개고, 각 기능에서 확인할 항목을 적어 봅니다.
- 정상 흐름: 설명대로 눌렀을 때 의도대로 동작하는가
- 경계값: 최대 수량, 0개, 글자 수 제한 같은 끝값에서 문제가 없는가
- 예외 흐름: 중간에 앱을 내리거나 통신이 끊기면 어떻게 되는가
- 표시 오류: 글자 잘림, 겹침, 번역 누락이 있는가
이렇게 관점을 나눠 보면 '버그를 찾았다'가 아니라 '이런 기준으로 확인했다'고 말할 수 있게 됩니다. 면접에서 QA 지원자에게 기대하는 것도 바로 이 기준입니다. 하루에 기능 하나씩만 정해도 몇 주면 게임 하나의 주요 화면을 모두 훑을 수 있습니다.
2단계: 테스트 케이스와 체크리스트를 직접 씁니다
테스트 케이스는 '무엇을, 어떤 순서로, 어떤 결과를 기대하며 확인하는가'를 적은 문서입니다. 기획 문서가 있다면 그것을 바탕으로, 없다면 직접 플레이하며 기능 명세를 거꾸로 정리한 뒤 케이스를 씁니다.
- 기능 하나를 골라 동작 규칙을 문장으로 정리합니다.
- 규칙마다 확인 항목을 만들고 번호를 붙입니다.
- 항목마다 사전 조건, 수행 절차, 기대 결과를 적습니다.
- 실제로 수행하고 결과를 통과·실패로 표시합니다.
- 빠진 경우가 없는지 다른 사람에게 검토받습니다.
스프레드시트 하나면 충분합니다. 칸 구성을 일정하게 유지하는 것만으로도 문서가 훨씬 전문적으로 보입니다. 처음에는 기능 하나에 열 개 안팎의 케이스로 시작하고, 익숙해지면 정상 흐름보다 예외 흐름 케이스의 비중을 늘려 보세요. 실무에서 문제가 터지는 곳은 대부분 예외 흐름이기 때문입니다. 케이스를 쓰다가 기획 의도가 불분명한 부분을 발견하면 따로 '확인 필요 사항' 목록으로 모아 두는 것도 좋은 습관입니다. 실제 현장에서도 QA가 기획의 빈틈을 먼저 발견해 질문하는 일이 많습니다.
3단계: 재현 가능한 버그 리포트를 연습합니다
QA 실력이 가장 잘 드러나는 문서는 버그 리포트입니다. 좋은 리포트는 개발자가 읽고 같은 현상을 그대로 다시 만들 수 있어야 합니다. 제목, 발생 환경, 재현 절차, 기대 결과, 실제 결과, 재현 빈도, 첨부 자료를 빠짐없이 적습니다.
흔한 실수는 '가끔 튕김'처럼 감상만 적는 것입니다. 몇 번 시도해서 몇 번 발생했는지, 바로 직전에 어떤 행동을 했는지를 적어야 합니다. 화면 녹화나 캡처를 붙이면 설명이 짧아도 전달이 정확해집니다. 심각도와 우선순위를 내가 왜 그렇게 판단했는지 한 줄 덧붙이는 연습도 함께 해 두세요. 진행이 막히는 버그와 글자 하나 어긋난 버그는 같은 무게로 다루면 안 됩니다. 연습용 리포트를 쓸 때는 실제 서비스 중인 게임의 버그를 외부에 공개하지 말고, 개인 학습 자료로만 보관하는 것이 예의입니다.
4단계: QA 포트폴리오로 묶고 지원 범위를 정합니다
포트폴리오에는 기능 분석표, 테스트 케이스, 버그 리포트 샘플, 테스트 결과 요약을 한 게임 기준으로 묶어 넣습니다. 모바일과 PC처럼 플랫폼을 두 가지로 나눠 비교한 자료가 있으면 폭을 보여 줄 수 있습니다.
준비 기간은 사람마다 다르지만 관점 연습과 문서 작성에 몇 달 정도를 잡는 경우가 많습니다. 지원할 때는 개발사 내부 QA, QA 전문 회사, 퍼블리셔 QA 등 형태가 다양하니 업무 범위를 확인하고 고르세요. 써 둔 버그 리포트가 실무 기준에 맞는지 궁금하다면, SBS아카데미게임학원 게임QA 과정 상담에서 그 리포트를 기준으로 부족한 항목을 함께 짚어 드립니다.
자주 묻는 질문
게임 QA에 자격증이 필요한가요?
신입 채용에서 자격증을 필수로 요구하는 경우는 많지 않습니다. 소프트웨어 테스트 관련 자격증은 용어와 이론을 정리하는 데 도움이 되지만, 실제 테스트 문서를 보여 주는 쪽이 더 직접적입니다.
QA 자동화도 처음부터 배워야 하나요?
처음에는 수동 테스트의 기본기를 먼저 다지는 것이 좋습니다. 자동화는 무엇을 반복 확인해야 하는지 아는 사람이 다룰 때 효과가 커서, 기본기를 익힌 뒤 단계적으로 배워도 늦지 않습니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.