게임QA 를 어떻게 구분할 것인가에 대해서는 회사마다 여러가지 이견이 있을수 있습니다만,
아무래도 게임QA 가 가장먼저 분화되고 많이 발전되어 있는 NCsoft 의 기준이 전반적으로 많이 통용되는것 같습니다.
입문하려는 분들이 많이 궁금해 하시는 게임QA 의 구분을 적어 봅니다.
게임QA 의 업무를 알기 위해서는 게임이 어떻게 만들어 지고,
어떤 절차를 거쳐 서비스 되는지 알아야 합니다.
[게임이 만들어지는 과정]
1. 게임을 만들고 싶은 사람이 있습니다. 이 사람이 PD입니다.
2. PD가 메인 기획자, 메인 프로그래머, 메인 아티스트를 모아 제안서와 프로토 타입을 만듭니다.
3. 투자를 받습니다. (혹은, 회사내에서 정식 프로젝트가 됩니다)
4. 비교적 적은 인원으로 알파버전을 만들고 허들을 넘습니다.
5. 인원을 늘려 컨텐츠 양을 늘리고, CBT, OBT를 거쳐 상용화 합니다.
실제로는 이보다 훨씬 더 다양한 과정들이 있습니다만,
대략적인 흐름은 여기에서 크게 벗어나지 않습니다.
게임QA 를 조기에 세팅 하는 경우에는 3번째 단계에서 부터 가능합니다만, (이 시기에 QA는 주로 시장조사와 유사게임 분석을 하게 됩니다)
많은 회사에서 4번 단계 즈음에 QA를 필요로 합니다.
게임을 과정에서 만들어진 컨텐츠가 유저에게 서비스 되기 까지는 다음의 과정을 거치게 됩니다.
[게임이 패치되는 과정]
1. 기획자가 기획문서를 만듭니다.
2. 프로그래머와 아티스트가 구현을 합니다.
3. 패치 파일을 만들어 업데이트 합니다.
4. 유저가 플레이 합니다.
게임QA 의 업무는 이런 과정 중 어느 단계에 포지셔닝 하느냐에 따라 다르게 나뉘어 집니다.
[패치 단계에 따른 QA 구분]
- GQA(Game dev QA) : 개발QA 라고도 합니다.
위 패치 과정의 1~3번의 전반에 걸쳐 활동하는 업무 입니다. (이중 3번 패치가 개발QA 의 핵심입니다)
기획서를 검토하여 테스트케이스를 만들어 프로그램팀에 넘기고,
프로그램팀에서 구현한 내용을 기능확인하고,
패치노트를 만들고, 최종패치하고, 버전관리를 합니다.
- PQA(Publishing QA) : 대규모의 테스트케이스를 만들고 전체 검수하는 작업을 합니다.
위 패치 과정의 3번을 전작업인 개발서버 활동과, 후작업인 테스트 서버 활동으로 나누어 볼 때,
후작업인 테스트 서버에서 주로 활동하는 업무 입니다.
개발QA 에서 넘겨준 패치버전을 전체 테스트케이스 기준으로 풀(Full)테스트 합니다.
외부에서 개발한 게임을 퍼블리싱 할 때, (보통 중소 개발사는 영세하기 때문에 QA를 제대로 거치지 않습니다)
기획서를 넘겨받아 케이스를 만들고, 확보된 인력풀을 동원하여 케이스를 인원별로 나눠 진행합니다.
- SQA(Service QA) : 운영에서 진행하는 QA 입니다.
위 패치 과정의 4번 단계에서 진행하는 업무 입니다.
패치노트에 공지된 내용이 실제로 잘 적용되었는지 확인하고,
유저가 리포팅한 내용을 체크하여 개발팀으로 전달합니다.
퍼블리싱QA 를 거치지 않고 서비스 하는 게임들은 서비스QA 에 많이 의존하게 됩니다.
(소규모 캐주얼 게임들은 퍼블리싱QA 과정 없이 바로 서비스 되기도 합니다)
패치 프로세스와 상관없이 테스트(혹은 검수) 할 대상을 무엇으로 할 것인가에 따라 게임QA 를 나눌수도 있습니다.
[테스트 대상에 따른 QA 구분]
- TQA(Technical QA) : 기획서에 예정된 내용대로 구현되었는지의 기술적 내용을 테스트 합니다.
모션이 잘 나오는지, 오타는 없는지, 오작동 하지는 않는지 등,
사람들이 흔히 버그라고 표현하는 내용을 테스트 대상으로 삼고 있습니다.
- FQA(Fun QA) : 게임에 반영된 컨텐츠 자체를 테스트 합니다.
신규 던전이 재미가 있는지, 유저들이 많이 플레이 하지 않는다면 이유가 무엇인지 등,
컨텐츠의 성질을 테스트 대상으로 삼고 있습니다.
사람들이 오해하고 있는 부분 중 하나는, 펀QA 가 테크니컬QA 보다 기술적인 베이스가 적어도 될것이라는 생각인데,
실제 펀QA 에서는 게임로그 분석과 같이 객관적이 자료를 토대로 하는 경우가 많아서
데이터 분석이나 매칭 알고리즘 분석과 같은 이론적인 배경이 다소 필요합니다.
여러 개발사로 게임QA 가 전반적으로 확산되고 발전하면서
이처럼 다양한 이름과 역할로 세분화하고 있습니다.
그러나, 기본적인 QA의 검수과정은 대동소이 하기 때문에
그 과정을 잘 알고 있다면, 어느 포지션에 있더라도 자기역할을 잘 찾을 수 있으리라 생각합니다.
[게임QA 의 전반적인 업무 흐름]
1. 기획자가 기획서를 만들어 QA에 넘겨줍니다.
QA가 다른 기획서와 충돌하는 부분은 없는지 확인하고,
꼭 체크되어야 할 부분만 적은 간략버전의 테스트케이스를 붙여 프로그램팀에 넘겨줍니다.
필요한 경우, 사전 조사(시장조사 등)를 병행할 수도 있고, 타게임 사례를 모아 기획팀에 피드백 할 수도 있습니다.
2. 프로그래머가 1차로 구현된 내용을 개발서버에 올려줍니다.
개발서버에서 이번에 구현된 내용만 따로 기능테스트 합니다.
이때, 기능 테스트케이스를 만들어 사용하고, 이런 기능 테스트케이스를 모으면 추후 풀테스트케이스가 됩니다.
3. 일정 정도 개발내용이 모이면 패치노트를 만들어 패치버전을 만듭니다.
소스를 확인하고, 패치 파일을 만들어 테스트서버에 올리고 테스트 합니다.
상황에 따라 팀내 테스트로 한정할 수도 있고, 퍼블리싱 테스트로 넘기기도 합니다.
4. 문제점을 수정한 최정 버전을 서비스서버에 패치 합니다.
패치 내용이 잘 적용되었는지 확인합니다.
게임내에 영향을 많이 미치는 패치라면, 일정 기간동안 게임의 컨텐츠 상태(예를 들어 총 게임머니)를 체크합니다.
필요한 경우, 로그를 분석하여 어뷰저를 찾거나 추가로 보완이 필요한 내용을 따로 피드백 합니다.
최근에는 이러한 기본적인 업무 이외에
게임의 퀄리티와 매출을 더욱 끌어 올리기 위한 여러 시도들이 이루어 지고 있습니다.
주로 이런 경우에는, 기존에 있던 업무 중 가시적으로 효과를 확인할 수 있는 분야에 집중하는 형태로 포지셔닝 되고 있습니다.
[그 외 새로이 만들어지고 있는 QA]
- CQA(Critical QA) : 게임에 심각한 영향을 주는 어뷰징(예를 들어 아이템복사)을 전문으로 다룹니다.
게임의 기술적인 특성을 분석하고, 취약점을 공략하여 잠재하고 있는 버그를 찾아냅니다.
테크니컬QA 와 게발QA 에서 분화하였으며,
심각한 버그로 인해 손실되고 있는 매출을 방어합니다.
- DQA(Data analysis QA) : 게임로그 분석을 전문으로 다룹니다.
게임의 문제점은 유저의 행동으로 나타나고, 게임로그를 통해 이를 찾아냅니다.
펀QA 와 서비스QA 에서 분화하였으며,
모니터링을 통한 문제점의 조기 차단으로 매출을 방어합니다.
업계에 계신 분들 중에, 혹여 이 외의 새로운 형태로 QA업무를 하고 계신 분이 있으시다면 연락 부탁드립니다.
(연락 주시면 관련 내용 업데이트 하겠습니다)
'도서관' 카테고리의 다른 글
| 게임 장르별 유저수 추정 - 게임QA 의 시장조사 피드백 업무 (0) | 2011.10.06 |
|---|---|
| [연재] 2회: 위기야 말로, 진정 '위태로운 기회' 이다. (소제목: 1박2일의 나영석 PD님 강의 요약) (1) | 2011.10.05 |
| SNG 시장 현황 리뷰 - 게임QA 에서 진행하는 시장조사 (2) | 2011.10.04 |
| [연재] 1회: 좋은 피드백이란 무엇일까? (소제목: 리더와 매니지먼트) (5) | 2011.10.03 |
| 테스트베드(Test Bed 혹은 FGT) 기안과 현장 프로세스 (0) | 2011.10.02 |
