빌드가 안 나왔다, 할 일이 없다?

찾아서 일하기

QA(quality assurance) 직군은 그 특성상 게임 개발 과정에서 가장 마지막에 위치한다. 간단하게 설명하면 제품의 품질을 보증하는 업무다. 테스트가 주요 업무이니 만큼 기획이나 개발 혹은 아트 작업이 되지 않으면 할 일이 없다. 그런데 정말 그럴까?

*빌드는 쉽게 말해 개발 과정의 게임 버전이라고 생각하면 된다. 새로운 빌드일수록 기존의 버그가 수정되거나 최근 작업한 내용이 들어가 있다.

이슈 관리

필자의 회사의 경우 JIRA를 통해 게임의 다양한 이슈를 관리한다. 버그나 작업 등 기록 및 공유를 통해 업무를 한다. 본격적인 테스트에 앞서기 전 이슈를 확인하는 건 당연하면서도 간과하기 쉽다. 테스터들이 하는 흔한 실수 중 하나는 중복된 내용의 이슈를 등록하는 일이다. 기존의 이슈를 확인하지 않아서 빚어지는 실수다. 같은 이슈의 등록은 개발자들이 한 번이라도 다른 작업을 봐야 한다는 점에서 그들의 능률을 저하시킨다. 본격적인 업무에 나서기 전에 기존에 등록된 작업들은 어떤 것이 있는지, 버그는 또 얼마나 있는지 알아야 한다.

히스토리 파악

세상의 모든 일이 그렇듯 게임 개발도 한순간에 이뤄지지 않는다. 뼈대인 기획부터 그렇다. 어느 누구도 한 번에 완벽한 기획을 할 수 없다. 기획서를 작성하다 보면 빠지는 부분이 있을 것이고, 게임 사정상 불가능한 내용이 들어가 있거나, 기존의 다른 부분 기능에 대해 알아야 할 경우가 생긴다. 또 개발자들이 작업을 시작하면 명확하지 않은 기획서의 표현 때문에 재정의에 들어가거나, 구현상 문제가 생기곤 한다. 그러다 보면 기획 내용이 삭제되거나 변경되는 경우가 흔하다. 게임 개발 진행과정이 어떻게 되고 있는지 파악해야 하는 이유다.

빌드 둘러보기

게임회사의 업무는 달력에 고정되어 있는 일정대로 가는 편이다. 그래서 업무를 하다 보면 개발 작업 중인 빌드를 받곤 하는데 작업이 덜 된 모습이 그대로 노출된다. 여기서 중요한 건 그것이 버그인지 아니면 단순히 작업이 덜 돼서 그런지 파악하는 거다. 이 때는 개발자들 문서(ex:TDB) 등이 현재 어느 정도 작업되었는지 확인해야 한다. 기본적인 유저 플로우를 따라 플레이하는 것도 중요하다. 게임에 새로운 부분을 개발하다 보면 기존의 기능이 망가지는 경우가 허다하다. 그중 유저들이 가장 많이 플레이하는 과정을 따라서 테스트하는 것이 중요하다. 의외로 많은 사이드 임팩트를 발견할 수 있다.

테스트 케이스 확인

본격적인 테스트 기간인 디버그 혹은 그전에 실시하는 pre-test 기간 이전에 QA들은 테스트 케이스를 작성한다. 이 테스트 케이스를 기반으로 업무를 진행하고, 버그를 찾아 이슈를 등록해 관리하고 지속적으로 추적한다. 보통 테스트 기간 이전에 모두 작성을 마치는데 간혹 기획이 바뀌어 케이스를 수정해야 할 때가 있다.    또, Telementry(cslog, 로그 기록 기능. 어떠한 로그를 출력할 것인지에 대한 명세)와 같은 경우 새로운 부분이 개발될 때 딜레이가 될 수 있다. 이러한 부분은 지속적으로 확인하고 케이스를 추가해야 한다.

커뮤니티 동향 파악

QA들에게 커뮤니티는 중요하다. 유저들은 그 한 명 한 명이 테스터나 다름없다. 실제로 그들이 어떤 곳에서 불편함을 느끼는지 알아야 한다. 그것이 게임의 밸런스인지 버그인지 게임 내 불편함인지 알아둬야 한다. 실제 많은 버그들이 유저들의 동향으로 파악된다. 테스트 환경과 라이브 환경은 엄연히 다르기도 하고 유저들의 경우 더 창의적인 플레이로 버그를 발견할 확률이 높다. 여기만 확인해도 QA로서 칭찬받을만한 버그들을 찾아 등록할 수 있다. 버그는 유저들이 게임을 떠나는 이유 중 하나가 될 수 있는 만큼 유저 동향 파악은 항상 중시되어야 한다.

사실 이외에도 찾아보면 더 많다. 이러한 일들은 어떤 일이든 마찬가지인 것 같다. 본인의 일을 찾아보면 할 일이 항상 있는 만큼 직군을 막론하고 필요한 태도라고 본다.