게임회사 QA는 게임만 하나요?: ② QA가 하는 일

[게임회사 QA는 게임만 하나요?] 시리즈 보러 가기 ▼

게임회사 QA는 게임만 하나요? ① QA에 대하여

앞선 글에서 언급했지만 게임 QA의 업무는 프로세스 전반에 걸쳐 있어, 그 범위와 성과를 측정하는데 어려움이 있다. QA의 업무를 가볍게 살펴보면 기획서 정리, 개발에 대한 피드백 제공, 테스트 케이스 작성, 테스트, 버그 리포트 작성, 테스트 방법 개발 등이 있다. 오늘은 게임 개발 프로세스를 따라 QA가 하는 일을 살펴보고자 한다.

기획서, 어떻게 읽어야 할까

게임 QA(Quality Assurance; 품질보증)는 게임의 리스크를 줄여서 품질을 높여야 한다. 이를 위한 모든 업무의 바탕은 기획서다. 기획서를 바탕으로 개발자가 개발한 게임을 플레이하고, 테스트 케이스를 작성하고, 버그로 보이는 현상이 기획 의도인지 아닌지 파악하기 때문이다.

이 때문에 필자 회사의 경우 경험 있는 리드 QA가 기획서를 기반으로 테스트할 내용을 정리하는 기술 문서(TB; Technical Brief)를 작성해 관련자들과 리뷰 회의를 연다. 이 회의에는 QA는 물론 해당 프로젝트의 기획자, 개발자 등 다양한 사람들이 함께한다. 기획서를 보다 보면 헷갈리는 부분들이 있기에, 이를 정리하기 위함이다. 리뷰 회의에서는 해당 부분이 기획대로 개발이 가능한지, 예상되는 사이드 이펙트는 어떤 것인지, 관련해 필요한 문서는 어떤 건지 모든 구성원이 공유한다.

기획서는 미리 읽어야 한다. 하지만 단순히 글자와 이미지만을 보고 내용만 이해했다고 넘길 문제가 아니다. 반드시 본인만의 언어로 정리해야 한다. 이유는 다음과 같다.

첫 번째, 기획서 자체가 양이 방대하다. 기획자의 스타일에 따라 다르지만 기본적인 양 자체가 방대하다. 간단하게 석박사 논문 정도 생각하면 편하다. 이 때문에 반드시 자신만의 언어로 짧게 재정리해야 한다.

두 번째, 업무 중 기획서를 다시 볼 여유가 적다. 바빠지는 시기에 방대한 양의 기획서를 구석구석 찾아보기 어렵다. 기억에 의존한다면 시간이 더 걸릴 수밖에 없다. 반면 본인이 만든 문서는 기억에 오래가는 법이다

세 번째, 공유와 피드백이다. 업무 효율성보다 중요한 건, 기획자의 의도 파악이다. 그렇기 때문에 쓰면서 헷갈리거나 궁금한 점들을 물어봐야 한다. 또한 공유 폴더나 사내 공동 소프트웨어를 통해 동료들과 자신이 정리한 문서를 비교할 수도 있다. 피드백을 통해 서로가 이해한 내용이 맞는지, 부족한 부분은 어디인지 파악하는 것이다.

테스트의 시작은 빌드와 서버 확인부터

QA(quality assurance)를 간단하게 설명하면 제품의 품질을 보증하는 업무다. 업무에서 무엇도 빼놓을 수 없지만, 기본은 ‘빌드 넘버’와 ‘서버’에 대한 지속적인 확인이다. ‘빌드 넘버’와 ‘서버’를 체크하는 것을 야구에 비유한다면 경기장이 존재하고 그 안에 1루~홈 베이스와 파울 라인, 홈런 펜스 등이 준비되어 있는지 체크하는 것과 같다. 테스트를 하기 위한 스킬이나 도구가 배트나 글러브 운동복 등이라면, ‘빌드’나 ‘서버’는 그 모든 것이 이뤄지는 경기장이라고 볼 수 있다. 

빌드는 소스 코드를 실행할 수 있는 소프트웨어를 말한다. 쉽게 말해 게임 클라이언트라고 생각하면 된다. 이 빌드는 게임 개발 중 무수히 많은 버전으로 존재한다. 상위 버전일수록 이전 버전의 수정이나 새로운 내용이 들어간다.

서버 역시 빌드처럼 서버 담당자에 의해 지속적으로 업데이트된다. QA 기능을 지원하는 도구들은 서버의 영향을 받는다. 프리 테스트(디버깅 기간 전 개발된 영역까지 테스트하는 기간)나 디버깅(본격적으로 버그 파악 및 수정하는 기간) 동안 일반적으로 빌드와 서버는 함께 업데이트된다.

게임 내에서 다수가 필요한 상황이라든지, 확인해야 할 에셋(아이템, 맵 등)이 많을 때 등 특수한 빌드를 사용하기도 한다. 이런 환경을 위해 만들어진 빌드나 서버에서 테스트가 진행될 경우 특히 주의해야 한다. 프리 테스트나 디버깅 기간에 쓰는 빌드, 서버와 다르기 때문이다.

특히, 서버 전체에 영향을 미치는 테스트 도구를 활용할 때는 각별한 주의가 필요하다. 보통 테스트를 제어하는 게임사 자체 소프트웨어의 경우 그 주소가 서버 숫자 빼곤 같은 경우가 많다. 서버를 오가며 테스트 시 자신이 해야 하는 곳이 아닌 엉뚱한 곳에 데이터를 바꾸는 실수는 빈번하게 일어난다. 본격적인 테스트에 나서기 전에 해당 게임 테스트 환경에서 빌드나 서버는 어디서 어떻게 알 수 있는지 확인하는 게 우선이 되어야 한다. 빌드와 서버에 대한 확인은 업무 간 상시 이뤄져야 하기 때문에 습관으로 만들어야 한다. 정확한 테스트를 위해서는 정확한 테스트 환경 파악이 우선이다.

버그 리포트는 어떻게 써야 할까

빌드와 서버를 확인했다면 테스트를 시작해보자. QA의 주 업무는 테스트를 통해 버그를 발견하여 제품의 안정성을 높이는 일이다.버그를 발견한 뒤엔 리포트를 작성한다. 이후 담당 기획자와 개발자에게 내용을 공유한다. 업무의 많은 시간을 할애하고 그 중요도가 높은 만큼 리포트 작성에 대한 고민이 크다. 버그 리포트에는 다음과 같은 내용이 포함된다.

- 제목

어느 글이 그렇듯 제목이 가장 중요하다. 제목은 리포트 내용의 요약이다. 구체적인 현상을 한 문장으로 정리해야 한다. FPS 게임을 예로 들어보겠다. ‘특정 맵에서 주 무기의 총기 반동이 제대로 반영이 안 되는 문제’가 제목이라면 구체적인 문제를 파악하기 힘들다. ‘특정 맵에 있는 OO좌표에 있는 50m 거리 표적에게 사격하는 AK47의 총기 반동이 다른 맵보다 큰 문제’라고 하면 전보다 좀 더 자세한 설명이 된다. 너무 길면 안 되지만, 상세히 제목을 쓰려고 노력해야 한다.

- 환경

테스트를 진행하는 환경에 대해 자세히 서술한다. 필자 회사의 경우 BTS(Bug Tracking system)로 JIRA 프로세스를 이용 중이다. 버그 리포트는 종종 형사의 수사 보고서로 비유된다. 범인을 잡기 위해선 범죄 현장의 모든 요소가 중요하다. 이처럼 어떤 서버, 빌드 등 고려해야 하는 다양한 환경에 대한 정보가 포함되어 있어야 한다.

- 재현율

해당 현상이 어느 정도의 빈도로 나타나는지 적어야 한다. 모든 버그는 100%로 일어나지 않는다. 때문에 대략적으로라도 재현율을 제공해야 한다. 만약 %로 나타나기 어렵다면, '20번 시도했으나 다시 재현하지 못함'처럼 구체적인 수치로 표시하는 게 좋다.

- 설명

제목으로 모든 내용을 담을 수 없기에 자세한 사항을 설명하는 칸이 필요하다. 해당 부분에는 재현을 위한 버그 사전 스텝이나, IP와 포트, 스트림, 서버, 클라이언트 등을 적는다. 이외에도 참고가 될 만한 정보를 모두 쓴다. 기대 결과도 적어주면 좋다. 버그가 없고 소프트웨어가 정상 작동하면 나타나는 결과에 대해 쓴다.

- 재현 스텝

재현 스텝은 알아보기 쉽고 짧게 쓰는 게 좋다. 필자 회사의 경우 굳이 '전원을 넣는다' 같은 항목을 쓰지 않는다. 이미 게임을 실행했다는 전제를 깐다. 이후 생략이 가능한 부분은 모두 적지 않는다. '1. A -> B -> C / 2. OO 접속해 해당 증상 확인'과 같이 쓴다.

- 참고 파일

백 마디 글보다 한 장의 사진이 더 이해하기 쉬울 때가 있다. 때문에 스크린 샷과 영상을 만들어 보기 좋게 편집해서 첨부해야 한다.

- 댓글

버그 리포트(이슈라고도 부르는데) 관련 새로운 소식이나 추가적인 정보는 댓글로 남기는 게 좋다. 이미 이슈에 게재된 정보를 업데이트하면 무엇을 고쳤는지 바로 알기 어렵다. 댓글을 통해 개발자나 기획자에게 알리면서 작업이 어떻게 진행되는지 소통하자.

어떤 직무나 고충이 있다. QA도 마찬가지다. QA는 프로세스 전반적으로 접촉해야 할 사람이 많고, 각각의 업무에 대한 이해는 필수조건이다. 하지만 더 나은 게임을 만들기 위해 테스트를 반복하고, 소통하고, 확인 또 확인하는 것이 QA의 숙명이다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.