[목차]
Part I. 게임 개발사와 QA의 현실
- 1. 한국 개발사의 현실
- 2. 게임 QA의 현실
Part II. 사람들이 잘 모르는 QA업무
- 1. QA 업무 영역
- 2. QA 업무 사례
- 3. QA 업무 한계와 포지셔닝
[내용]
Part I. 게임 개발사와 QA의 현실
I – 1. 한국 개발사의 현실
한국의 게임 개발 업체 수 3,317개
온라인 게임 업체 당 평균 인원 21명
- PD : 1명
- 관리 : 1명
- 기획 : 4명 (시스템, 레벨, 스크립트)
- 프로그램 : 5명 (서버, 클라이언트)
- 그래픽 : 8명 (원화, 캐릭터, 배경, 애니메이션, 이펙트)
- 그외 : 2명 (사장, 이사, QA, GM, SE 등)
온라인 게임 평균 개발비 10억~15억
온라인 게임 평균 개발 기간 22개월
1인당 1개월 비용은 15억원 / (21명 x 22개월) = 325만원
통상적으로 1인당 비용은 임금의 2배가 소요되므로,
1인당 월평균 임금은 200만원이 되지 않는다는 결론 입니다.
질문! 당신이 이 회사의 사장이라면,
QA를 충원 하시겠습니까? 프로그래머를 충원 하시겠습니까?
I – 2. 게임 QA의 현실
전체 게임 종사자 중 QA 인원의 비율은 3%
임원급 필요 인력 중 QA 인원의 비율은 0%
직종별 학력 분포에서 고졸 비율이 최다,
직종별 선호 전공에서 전공 무관으로 최상위권,
인력 충원에 어려움 없음도 최상위권 입니다.
결론! 한국 개발 업체에서 QA는
없어도 되거나, 있더라도 단순 테스터로 인식하고 있어요
Part II. 사람들이 잘 모르는 QA 업무
II – 1. 사람들이 잘 모르는 게임QA 업무
테스트
- QA의 기본은 테스트 에서 출발
- 기본 테스트, 기능 테스트, 적합성 테스트, 플레이 테스트, 과부하 테스트
테스트 툴
- 테스트는
테스트 시트 로 체크 되고,
테스트 프로세스 로 담당자에게 넘겨지고
버그수정으로 확인
※ 회사별 테스트 툴의 일반적인 진화
(1) 엑셀
(2) 오픈 소스 (멘티스, 버그지라)
(3) 자체 툴
(4) 자체 툴의 통합
※ 해외 업체별 툴
- EA : devtrack, hansoft
- 반다이남코 : filemaker
- Lucas : 자체툴(엑셀)
- SONY : alienbrain
- Crystal Dynamics : hansoft
프로세스 개선
- 모든 개발팀은 저마다의 개성을 가짐. 그래서 개발팀 마다 프로세스가 다 제각각
- 프로세스에 적합한 테스트 툴을 만들고, 테스트 툴을 적용 하기 위해 프로세스를 개선
일정관리
- 버그는 우선순위가 있고, 우선순위에 따라 개발인원들의 일정이 변경
※ 버그 처리 프로세스
(1) 버그의 신고는 누구나 자유롭게 가능
(2) 모든 신고된 버그는 QA에서 확인
(3) 버그로 확인되면 담당자 지정
(4) 담당자는 처리 후 다음 담당자에게 전달
(5) 결국 버그 수정 후 다시 QA로 넘어옴
(6) QA에서 업데이트 확인 후 종료
기획 피드백
- 기획문서가 작성되면 구현에 앞서 테스트시트를 기획 문서에 첨부
이를 통해 구현 단계에서 크로스체크가 가능
FGT
- 게임의 시장성 조사나 유저 피드백을 강화하기 위해 FGT를 실시
게임패치
- 외부 로 게임이 제공 된다는 것은 서비스가 개시 된다는 의미
게임 패치 프로세스가 도입되고 QA가 최종적으로 패치 여부를 판단
게임평가
- 게임에 대한 시장 반응과 FGT, 설문, 유사게임 조사 등을 토대로 게임에 대한 평가 보고
개발자산관리
- 개발팀을 유지하기 위한 하드웨어, 소프트웨어의 자산 관리 이슈 발생
QA는 문제점 발생의 원인을 파악해야 하므로 하드웨어, 소프트웨어 명세를 알고 있어야 함
인트라넷
- 각 개인의 업무 형태를 생각해 보면 여러 툴들은 통합적으로 운용되는 것이 효율적
QA 업무를 다시 정리하면
"테스트 + 피드백 + 관리"
II – 2. QA의 업무 사례
- 사례1 : BugTrap Report
- 사례2 : Test - TSearch
- 사례3 : AION 분석
- 자체 테스트 처리 툴인 버그 게시판
- 개발 프로세스와 QA 업무 프로세스
- 게임 시장조사와 타 게임 분석 피드백
- 개발 시기별로 요구되는 다양한 분석 피드백
- 인트라넷으로 통합된 일정, BugTrap Report, SVN Log
- 인트라넷을 통한 하드웨어, 소프트웨어 자산관리
II – 3. QA의 업무 한계 와 포지셔닝
QA 업무의 재정의
- 개발실패의 위험요인을 제거 하고
게임의 브랜드 가치 를 향상 시키기 위한 모든 업무
※ QA업무는 테스트로 한정된 것이 아니라
필요에 따라 테스트, 피드백, 관리로 확장.
프로젝트가 실패 하는 이유?
- 개발자는 자기 일만 한다.
- 게임 개발을 위해서는 소스 제작 이외의 관리이슈가 많다.
- 열악한 개발 환경은 관리 이슈를 개선하기 보다는 개발자를 한 명 더 충원 하는 쪽으로 돈을 쓴다.
- 결국 누군가 는 그 일을 해야 프로젝트가 실패하지 않고 그 일을 할 가장 적임자 는 여러 업무를 공유하는 QA
갖춰진 조건 하 에서의 QA
- SE가 세팅 되어 있다면, 자산 관리를 QA가 할 필요가 없다.
- 마케팅이 세팅 되어 있다면, 시장 조사를 QA가 할 필요가 없다.
- GM이 미리 세팅 되어 있다면, 운영을 QA가 할 필요가 없다.
- 웹팀이 세팅 되어 있다면, 인트라넷을 QA가 만들 필요가 없다.
- 현실이 뒷받침을 해준다면 QA는 본연의 정도(正道)를 향해 나아가야
QA의 분업 과 포지셔닝은 회사 사정에 맞게
- 소규모 회사 : 1인 다역 (테스트, 자산관리, 시장조사)
- 대규모 회사 : 개발QA, 퍼블리싱QA, 운영QA, 평가QA
※ 이러한 원인으로 현재 각 회사마다 QA는 각각 다 다른 포지션.
Q & A
'도서관' 카테고리의 다른 글
[강의] 영진 - 6주) QA업무 스킬 - 엑셀 (3) | 2010.10.12 |
---|---|
[강의] 영진 - 5주) QA업무 사례 - 매니지먼트 (1) | 2010.10.05 |
[강의] 영진 - 4주) QA업무 사례 - 테스트 (2) | 2010.09.28 |
[강의] 영진 - 3주) QA업무 사례 - 피드백 (1) | 2010.09.15 |
[강의] 영진 - 1주) 게임QA의 역사 (1) | 2010.08.30 |