안녕하세요! 딩딩입니다.
오늘은 게임 QA가 하는 업무에 대해서 전해드리려고 합니다.
(회사마다, 프로젝트마다 업무 진행이 많이 다를 수 있음을 미리 말씀드립니다.)
게임 QA 업무는 크게 개발 중인 프로젝트냐 런칭한 프로젝트냐에 따라 다릅니다.
마찬가지로 입사 준비할 때 개발 단계인지 라이브 운영 중인 프로젝트인지에 따라 주요 업무도 달라집니다.
개발 단계
런칭 전 개발 진행 중인 프로젝트
보통 공고 시 Project A 등으로 가칭으로 적혀있는 경우가 많습니다.
런칭을 거의 앞둔 경우에는 정해진 네이밍으로 올라올 수도 있습니다.
1) 개발 기능 검증 업무
개발 단계에서는 개발된 항목을 검증하고 폴리 싱하는 업무가 반복됩니다.
개발된 항목에 및 예정인 항목에 대해서는 사전에 기획서를 공유 받아서 기획서 기반으로 TC 및 CL를 미리 만듭니다.
(게임에 대한 모든 검증 내용을 포함한 TC를 Full TC라고 합니다.)
그 후 검증을 진행하는 방식입니다.
보통 특정 일정까지 완성되어야 할 기능들의 리스트, 진척도 등을 공유 받아서 완료한 순서대로 차근차근 검증해나가면서 개발팀과 같이 진행하게 됩니다.
물론 개발팀에서 즉각적으로 개발하면서 데이터나 기능을 바꾸는 것이 QA에 영향을 미쳐서는 안되므로 QA를 위한 별도의 빌드로 구성이 됩니다. 일정 텀을 두고 아래와 같은 프로세스로 진행합니다.
- 개발팀이 개발 완료 항목을 QA 팀에 전달
- 개발 완료 항목 검증 후 버그 체크 -> 개발팀으로 전달
- 개발팀 버그 수정 및 추가 개발 항목을 새 QA 빌드로 QA 팀에 전달
그래서 *BTS 툴을 이용해서 서로가 소통하면서 개발된 항목들의 버그를 줄여나갑니다.
이 행위를 특정 *마일스톤을 기준으로 빌드의 완성도를 체크해나가게 됩니다.
2) 계획/결과/최종 결과 공유
- 테스트 계획/결과
모든 검증은 하루 단위로 계획과 결과를 개발사, *유관 부서에게 공유하게 됩니다.
어떤 이슈가 나왔고, 어떤 부분을 검증하고 있고, 진척도는 어느 정도다! 등의 현재 진척도를 공유하는 것이죠.
- 최종 결과 공유
개발 QA의 경우는 기본기능 검증(BVT)를 진행했다 정도로 볼 수 있고 퍼블리싱 QA의 경우에는 마켓에 등록할 수 있는 상태의 빌드라고 판단되었을 때, 보내는 결과 공유라고 보면 됩니다.
런칭 목표로 한 빌드의 검증이 모두 끝난 경우 이 빌드를 기준으로 시장에 내놓을 수 있다, 아니라는 결과 의견을 전달하게 됩니다. SignOff라고도하며, 런칭 가능 의견 등의 표현으로 개발사, 유관 부서들에게 전달하게 됩니다.
(QA는 최종 결정을 할 수 있는 집단이 아닙니다. 최종 결정에 대한 의견을 줄 수 있는 겁니다. 최종 결정은 보통 사업부 쪽에서 판단하게 됩니다.)
3) 정책 검증
- 이 부분은 퍼블리싱 QA의 경우 메인으로 진행합니다.
- 런칭 전에는 사내에서 가이드 하는 사내 정책과 마켓에 올리기 위한 마켓 정책 검수를 함께 챙깁니다.
- 최초 런칭 전에는 정말 꼼꼼하게 전반적인 정책들과 게임에 적용된 플랫폼을 검수 진행합니다.
[개발 단계에서의 QA]
개발 단계에서는 위와 같은 프로세스를 거치면서 게임 내의 모든 기능들과 데이터들 체크까지 모두 검증하게 됩니다. 런칭에 포함된 스펙들의 완성도를 높이고 문제가 없도록 검증해 내는 것이 QA 업무의 주요 목표입니다.
(런칭에 필요한 스펙들의 완료)
라이브 단계
런칭 후 서비스 진행 중인 프로젝트
현재 마켓에서 다운로드할 수 있고 실제로 서비스하는 게임의 경우입니다.
1) 점검
임시, 긴급, 정기 점검 등 라이브 하는 게임에서 진행하는 모든 점검에서 QA 팀은 함께합니다.
보통 점검 시나리오를 미리 공유 받아 별도 라이브 환경에서의 QA 검증을 진행합니다.
점검 간 발생되는 버그, 또는 문제로 QA 최종 완료 사인이 길어지는 경우 연장 점검으로 이어지는 경우도 있습니다.
2) 패치
라이브 환경에서 체크된 버그들 중, 데이터 패치나 서버 패치의 경우 사전에 개발팀과 협업해서 요청받은 내용을
검증합니다. 그 후 라이브에 해당 수정 내역을 적용 후 적용 확인까지 진행합니다.
3) 다음 업데이트 준비 및 일정
개발 단계에서 진행하는 것과 같이 다음 업데이트 스펙에 따른 항목을 검증하고 폴리 싱하는 업무가 반복됩니다.
마찬가지로 사전에 공유된 업데이트 기획서 등으로 TC, CL 등을 만들고 검증을 진행합니다.
이는 개발 단계에서 행하던 3가지를 동일하게 축소화되어 진행한다고 보면 됩니다.
4) 라이브 이슈 트레킹
커뮤니티 또는 별도의 고객서비스팀에 제보되는 CS 및 버그들을 관리하고 재현, 리포팅도 함께 진행합니다.
정말 많은 버그 제보들 중에 데이터 패치, 서버 패치로 당장 패치할 수 있는 버그들은 바로 처리하지만,
코드의 수정이 필요한 클라이언트 패치 내역의 경우 별도로 모아서 다음 업데이트에 맞춰서 진행하게 됩니다.
5) 모니터링
커뮤니티에서 라이브 이슈를 간략하게 체크도 하지만, 보통은 점검이나 업데이트가 지난 후 문제가 없는지 모니터링도 어느 정도 진행하게 됩니다.
[라이브 단계의 QA]
개발 단계에서는 모든 집중이 게임의 자체 제작에 집중되지만, 라이브 단계가 되면 게임의 서비스 품질을 유지할 수 있도록 지속적인 체크와 검증을 진행하게 됩니다.
가장 큰 것은 커뮤니티 유저 동향에 따라서 대응해야 할 이슈들과 유저의 제보로 인한 일정 변수가 많습니다.
자 이렇게 개발 단계, 라이브 단계에서의 QA 업무를 말씀드렸습니다.
약간 덧붙이면 퍼블리싱 QA라고 해서 기능을 보지 않고 정책만 챙기는 것이 아니라, 똑같이 전반적인 빌드 검증을 진행합니다.
또 퍼블리싱 회사라고 하더라도 사내에 자체 개발 스튜디오가 있다면, 개발/퍼블리싱 QA의 두 가지 역할을 함께 진행할 수도 있습니다.
1. BTS 툴
레드 마인, JIRA, 맨티스 등 버그를 리포트 및 관리하고 추적할 수 있는 툴을 말합니다.
개발사+QA+유관 부서가 함께 들어있어서 현재 운영하는 혹은 개발하는 게임의 잔존한 버그 현황을 확인할 수 있고, 처리한 버그들의 히스토리를 관리할 수 있습니다.
2. 마일스톤
게임은 한 번에 모든 걸 정해서 만들지 않습니다. 단계별로 차근차근 늘려나가는데, 이에 대한 일정표 같은 개념으로 보면 됩니다.
예를 들면 프로토 타입은 마일스톤 1, 그다음 스펙들을 포함하는 단계는 마일스톤 2 등등..
전반적인 다음 업데이트 스펙이나 해당 마일스톤에서 필요한 기능들을 정리 및 관리하기 용이하도록 구분하는 것입니다.
3. 유관부서
QA도 개발사에서 보면 유관부서에 포함됩니다.
QA 입장에서 다 보니 QA를 제외한 나머지 부서들을 유관부서라고 표현합니다. 회사마다 부르는 명칭은 다르지만
의미는 같다고 보면 됩니다. (QA, 사업 PM, 서비스 PM(혹은 GM), 모니터링, 고객서비스 등등)
작은 규모의 회사에서는 QA가 다양한 운영적인 업무를 함께 겸임하는 곳도 존재합니다.
'[QA지식정보] > QA 지식' 카테고리의 다른 글
| [지식/경험] 빌드와 마켓 (0) | 2022.03.02 |
|---|---|
| [지식/경험] 이슈(버그) 관리 (0) | 2022.03.02 |
| [지식/경험] 게임 QA 직군 세부 (0) | 2021.09.10 |
| [지식/경험] 게임 QA는 무엇일까? (0) | 2021.09.10 |
| [지식/경험] 블로그를 시작하면서 (0) | 2021.09.10 |