신작들이 많이 나오는 시기에 맞춰 게임도 열심히 플레이하고, 요즘 푹빠져 있는 마비노기 모바일의 수익 구조 분석도 하고 있는 와중에...(변명) 블로그 업로드 주기가 너무 길어지는 것 같아 급하게 요즘 공부하는 것들을 끌어 모아보았다. 현재 사업PM으로 게임 사업에 참여하고 있으나, 신입사원이기 때문에 당연히 일관된 업무만 진행할 수 없어 아무것도 모르는 분야에 대한 요청들을 받을 때가 많다. 언제까지 뭐든 얼레벌레(?) 할 수도 없고, 또 나 혼자서 공부할 수 있는 것들도 아니기에 뭐든 공백을 채워야겠다는 생각도 든다.
근래 가장 큰 고민을 안게하는 업무는 게임 개발과 서비스에서 굉장히 중요한 역할을 하고 있는 QA 직무가 담당하는 무수한 것들이다. QA를 진행할 때 어떤 자료를 통해 어떤 내용을 테스트해야 하는지 알아야 하는지 정확히 파악하기 어려웠으며, 세분화된 역할들이 가진 범주를 명확히하고 싶었다. 회사의 직무에 관련한 정보가 다수라, 여러 채용 사이트와 기고된 글을 참고하였다.
게임 QA
Game Quality Assurance
게임의 다양한 품질 향상 활동을 통해 결함을 확인하고 개선하여, 게임의 안정성과 완성도를 높인다.
[상세 업무]
- 품질 관리 : 테스트 환경 개선, 테스트 케이스 설계 및 실행으로 게임 품질 확보
- 다양한 테스트 수행 : 기능 테스트, 탐색 테스트, 호환성 테스트 및 플랫폼별 특성과 요구에 맞춘 테스트 진행
- 서비스 안정화 지원 : 버그 트래킹, 로그 기반 테스트 및 정기 점검 관리로 안정적 서비스 유지
- 리스크 예방 : 테스트 프로세스 정밀화 및 결함 관리로 서비스 리스크 최소화
- 기술 활용 및 고도화 : 자동화 도구와 관리 솔루션으로 효율적이고 정교한 테스트 환경 고도화
명시된 바와 같이 QA는 상품의 품질 관리를 위해 다양한 테스트를 수행하고, 서비스의 안정화를 지원하며 여러 기술 및 서비스 지원을 통해 상품의 품질을 보증하는 역할이다. 게임 QA의 경우 게임을 개발하는 과정과 서비스하는 과정에서 업무를 수행하며(사실상 언제나), 서비스를 제공받는 유저와 직결되는 업무가 되기도 한다. 유저가 경험하는 모든 것들이 QA의 업무 수행에 따른 결과가 된다.
쉽게 말하면 게임의 결함을 찾아내는 소프트웨어 테스터이다. (크라이텍 진석준 리드 QA 曰)
> 기존 넥슨 홈페이지에 직무 소개가 굉장히 잘 정리되어 있었던 것 같은데, 리뉴얼되면서 찾기 어려워 다른 곳들을 뒤적여보았다.
> 출처: 넥슨네트워크 홈페이지
개발/서비스 단계의 QA
개발 단계의 QA
1. 개발 내용 검증 및 폴리싱
개발팀에서 기획되고 설계된 게임의 제작 과정에서, QA는 기획서를 검토하여 테스트할 내용을 정리한다.
기획서에서 우선 보이는 ⓐ버그 ⓑ기획의도 적합성 ⓒ테스트 시 필요한 내용 등을 점검한다.
2. 테스트 계획 및 내용 작성
기획서를 검토한 내용을 통대로 TC/CL를 설계한다.
TC/CL을 설계하는 것은 당연히 기획서에 명시된 내역을 바탕으로 진행된다.
[TC/CL]
- TC(Test Case)
테스트 케이스는 테스트할 내용을 조건으로 분류하고, 이를 위해 사전에 준비할 내용들을 기록하고, 결정적으로 기대되는 결과값을 예상하여 작성하는 것이다. 테스트를 위한 과정이 작성되기 때문에, 버그가 발생하여도 해당 동선을 돌아보며 재현할 수 있다.
→ 신규 기능에 대한 전수 검승 시 활용
- CL(Check List)
체크 리스트는 말 그대로 체크해야할 내용을 작성한다.
→ 여러가지 항목을 검증할 때, 확률 및 데이터 검증 시 주로 활용
3. 테스트 진행
중요 항목을 우선으로 테스트를 진행한다.
[버그의 종류] ★
1) 크리티컬(Critical)
- 핵심 기능에 발생한 오류로, 테스트가 불가능한 이슈
- 비정상 종료, 강제 종료 등의 정도이며, 가장 긴급하게 해결해야할 1순위로 분류
2) 메이저(Major)
- 핵심 기능은 아니나, 정상적으로 확인하기 어려운 경우
- 데이터 불일치, 서비스에 문제를 일으키는 이슈로 빠른 수정을 요구하는 분류
3) 마이너(Minor)
- 기능에 문제는 없으나, 서비스 상 이슈가 있을 수 있는 경우
- 예를 들어 디자인/퍼블리싱 작업 과정에서 문제가 생기는 경우. UI/UX 등
4) 트리비얼(Trivial)
- 단순 오류, 오탈, 디바이스 오류 등 사소한 UI 오류
- 즉시 수정이 가능하며, 급한 경우 수정하지 않아도 서비스 영향에 무관
4. 테스트 결과 보고
테스트를 진행하고 발견한 버그를 종류 별로 보고하며, 추가적인 개선사항까지 보고한다.
밸런스, FunQA 등 여러 항목에 따라 분류되어 있는 QA의 업무 특성 상 게임의 발전 방향성까지 검토할 수 있는 결과를 도출해낼 수 있다.
서비스 단계의 QA
1. 점검 테스트
업데이트 당일, 유저에게 공지된 점검 시간 동안 점검 테스트를 진행한다.
전반적인 내용을 모두 검토하고, 모든 버그 및 이슈가 정리되면 유저 대상 업데이트를 배포하여 서비스를 제공한다.
2. 패치 및 라이브 이슈 트래킹
테스트 과정에서 발견하지 못해 라이브 서비스 중 발견하는 버그들이 있어,
해당 사항을 트래킹하고 CS를 통해 접수된 버그들을 관리한다.
필요 시 긴급 패치를 진행할 수도 있고, 이후 라이브 업데이트 시 해당 이슈들을 모아 함께 진행하기도 한다.
게임 QA의 업무
사업 규모에 따라, 요즘의 QA 직무는 업무 목적에 따라 분업화되는 추세로 알고 있다.
Test와 Review의 과정으로 이루어진 QA들의 업무 목적에 따라, 아래와 같이 역할과 내용이 구분된다.
개발 QA
- 게임 패치 단계에서 검증 대상에 대한 테스트 계획 수립 및 이슈 관리, 결과 도출까지 진행하는 역할
- 전반적인 게임 내 모든 시스템, 기능을 검토하여 원활하게 작동되는지를 검토
- 개발 내용에 대한 기획 문서를 검토하여 테스트를 설계하고, 패치를 진행
밸런스 QA
- 게임의 밸런스를 검증하는 역할
- 기획 문서를 검토하여 레벨 디자인, 콘텐츠의 난이도 등 플레이 시 실제 체감되는지까지 검토
Fun QA
- 게임 콘텐츠의 재미요소를 테스트하는 역할
- 신규 콘텐츠가 재미있는지, 혹은 타 게임과 비교 분석하여 개선
LQA
- Language QA로, 글로벌 서비스를 위한 번역을 검수하는 역할
- 보통 전문적인 번역 담당자 혹은 외주로 검증을 진행하며, 언어의 오기뿐만 아니라 적용 여부까지 검토
RQA
- Region QA로, 서비스 대상 지역을 담당하는 역할
- 각 지역 별 정책, 언어 등 게임 서비스에서 지켜야할 문화 등을 검토
호환성 QA
- 글로벌 환경에서의 안정성을 위해 다양한 플랫폼, 디바이스 등이 잘 호환되는지 검증하는 역할
- 보통 게임 빌드는 최저사양 디바이스에 맞춰 테스트
라이브 QA
- 게임 서비스 진행 과정에서 유지 보수를 진행하고, 지속적인 체크와 테스트 진행
- 유저 동향, CS에 따라 대응해야 할 이슈가 발생
PQA
- Publishing QA. 전체를 검수하는 작업
- 개발 서버에서 진행된 개발 완성도에 입각한 QA 이후, 최종 업데이트 등록 이전까지의 테스트 진행
- 마켓 등록 시 국가 별 정책 등을 체크하고 등록될 수 있는 상태를 점검
게임 QA의 역량
아마 내가 진행하고 있는 업무는 PQA의 역할일테나, 전체적으로는 모든 걸(?) 수행하고 있기는 하다. 우리와 같이 퍼블리싱을 하는 경우 PQA로서 정책부터 호환성, 지역까지 검수하는 등 역할의 범위가 달라질 수 있는 것 같다. 가장 궁금했던 버그의 종류부터, 각 역할이 하는 업무 범주를 익히는 등, QA 업무에 대한 이해를 거치니 해당 과정에서 중요한 것이 무엇인지 인지하게 된다.
1. 버그나 개선 사항을 찾기 위한 계획 수립 역량
개발 과정을 검토하여 테스트할 내용을 정리할 때, 어떤 영역에서 버그나 이슈가 발생할 수 있을지 예측할 수 있어야 한다.
업무 과정에서 가장 어려웠던 건 사이드 이펙트를 쉽게 예상하지 못하는 부분이다.
물론 그렇기 때문에 '사이드 이펙트'라는 용어가 붙었을테지만, 늘 예상하지 못한 부분에 아쉬움을 가지게되는 것 같다.
2. 기획서를 검토할 수 있는 인사이트
이미 갖추고 있는 본 게임에 대한 높은 이해도를 기반으로, 기획서를 보고 해당 내용을 도출한다.
또한 기술적 역량이 뒷받침 되어야 테스트 항목을 다각도에서 바라볼 수 있는 시야가 발휘되는 것 같다.
3. 커뮤니케이션 능력
QA 업무에 대한 고민에 앞서, 늘 개발팀과 커뮤니케이션하는 과정에서 '개발' 영역에 알맞는 소통법에 대한 고민이 있다.
본인은 여러 업무를 병행하고 아직 노하우도 유연함도 부족한지라, 어떤 방식이 알맞는 지 판단하기가 어려울 때가 많다.
여러 이야기를 들었을 때 어찌되었던 디버깅을 진행하는 측에 정확한 이해와 논리를 설명해야한다는 건 당연히 정답인 것 같다.
QA를 처음 담당했을 초반에는 (업데이트 규모가 작지는 않았으나) 한 번 진행할 때 3~4시간이 소요되고, 개발사와 소통까지 마치고 나면 하루가 그냥 지나가버려 내가 굉장히 비효율적인 과정으로 진행한다 생각했다. 그래서 어떤 정석적인 방법들이 있을지 궁금하기도 하고... 해서 여러 가지를 공부해보긴 했는데, 정작 실제 업무에 어떻게 적용해야할지는 여전히 어떤 방법이 정답일지 모르겠다. 그럼에도 불구하고 버그 종류조차 모르던 나였기 때문에, 이번 포스팅을 통해 기본 지식을 바탕으로 업무를 수행할 수는 있겠다고 느껴진다. 잘 이겨내보자... 아자아자~!
[참고 인사이트]
리서치를 하다보니 QA 관련 인사이트를 전문적으로 다뤄주시는 분들이 많아, 아래 웹사이트에서 많은 정보를 얻을 수 있었다.
혹시나 QA를 꿈꾸는 분들이 있다면 참고해보는 것도 좋을 것 같습니다!
'STUDY' 카테고리의 다른 글
| [사업] A/B TEST (6) | 2025.01.19 |
|---|---|
| [개발] 넷마블 기술 블로그 - 퍼블리싱 플랫폼 (3) | 2025.01.12 |
| [게임사업] 중국 국내외 퍼블리싱 성공을 위한 6가지 팁 (텐센트) (2) | 2024.12.23 |
| [시장분석] 2024년 국내 게임 산업 돌아보기 (6) | 2024.12.15 |
| [게임사업] "이탈 고객 대상 리타깃팅, 비용 효율적인 마케팅" (1) | 2024.11.26 |
