본문 바로가기

도서관

게임회사의 QA 변화 단계 - 엑셀>외부툴>자체툴>통합툴


게임개발과 관련하여
QA 이외의 포지션에서 QA 에 대한 이해를 가지고 있는사람은 거의 없습니다.

※ 심지어 QA 조차도 SWQA 와 GameQA 가 어떻게 다른지 모르는 사람이 많습니다.

그러다보니, 경영진 입장에서는
QA 를 하기는 해야겠고, 어떻게 하는지는 모르겠으니
바닥에서 부터 하나씩 올리는 수밖에 없는것 같습니다.

이런 배경에서, 게임회사의 일반적인 QA 변화는 아래의 단계를 거치게 됩니다.

1단계 - 엑셀
2단계 - 외부 BTS(맨티스, 지라 등)
3단계 - 자체툴 구축
4단계 - 통합툴(PMS+BTS) 사용





1단계
- 테스트케이스를 만들고, 버그 관리를 시작하는 단계 입니다.
- BTS로 엑셀을 사용합니다.
- 별도의 BTS 가 없기 때문에 메일이나, 개발자에게 직접 버그를 전달합니다.
- 엑셀로 관리를 하다보니, 아직 QA 가 버전관리까지 진행하기는 어렵습니다.
 
2단계
- 좀더 체계적으로 버그를 관리하는 단계 입니다.
- 버그 이력, 버그율 등 지표를 만들기 시작합니다.
- 버그에 대한 매니지먼트 기능을 포함하고 있는 외부 BTS 를 도입합니다.
- BTS 를 통해 버그를 전달하고 처리 합니다. 

3단계
- 게임 개발은 프로젝트별로 프로세스가 다 다른데, 외부 BTS 를 이 프로세스에 딱 맞게 사용하는것은 무리가 있습니다.
- 내부에서 자기 프로젝트에 맞는 BTS 를 직접 개발하는 단계 입니다. (혹은 외부 BTS 를 상당규모로 커스터마이즈 합니다)
- 개발의 각 프로세스에 BTS 가 적용되고, QA 가 버전관리를 수행하는데 무리가 없습니다.

4단계
- 개발이 사용하는 매니지먼트 툴이 PMS 와 BTS 로 나뉘어 있어, 효율성을 올리기 위해 통합을 추진하는 단계 입니다.
- 내부에서 개발한 BTS 를 업그레이드 하여 PMS 기능을 갖추거나, 외부에서 만든 전문 매니지먼트 툴을 도입합니다.
- 모든 개발 단계에서 통합툴이 적용되어 있어, 이슈가 발생할 경우, 이슈를 추적하기가 쉽습니다.
- 개발에 참여하는 대부분의 구성원들이, 한번의 로그인으로 자기가 해야할 일을 쉽게 알아볼 수 있고,
   프로젝트 전체의 개발 상태를 한눈에 알아볼 수 있습니다.

 
게임 개발에서 흔히 하는 오류는
툴보다 사람이 더 중요하다는 당연한 사실에 얽매이는 것입니다.

좋은 사람들이 모여 있으면, 어떻게든 게임이 잘 나올 가능성이 높아집니다.
그런데, 좋은 사람들이 모여 있는 곳에 좋은 툴을 도입하면, 성공 가능성은 훨씬 더 높아집니다.
그래서 좋은 툴을 찾고, 도입하고, 만드는 일을 소홀히 해서는 안됩니다.

※ 특히나, QA 업무에서 툴은 업무 전체의 성과를 판가름할 만큼 중요 합니다.
     KPI 에 툴 도입 여부를 별도 항목으로 지정할 정도니까요.


다만, 이러한 게임QA 의 변화 단계가 SWQA 에서 목표로 하는 TQM(Total Quality Management) 이 아니라
개발팀의 업무효율 향상에 초점을 맞추어야 한다는 부분을 잊어서는 안됩니다.