QA로서의 건의 방법

요즘들어 QA를 시작할때의 초심을 잃어가는 느낌이다.
한번.. 두번.. 언제부터 작업물에 대한 열정이라 여기고 했던 건의나 피드백에 거부감을 가지는 모습을 보면서 남의 탓을 하면서 왜 받아들여 지지 않는지에 대한 불만만을 토하던게 일상적인 모습이 되어 버렸을까? 이런저런 푸념을 하면서 책과 웹을 떠돌던 중 처음 이 일을 할때 각오했던 일을 상기시켜주는 글을 발견했다.

1. 주관성이 강할 수 있는 건의사항(게임성 요소)은 배제하도록 한다.
- 왜 이렇게 만들었는지에 대한 기획의도를 기획서에서 찾을 수 없다면 기획자에게 기획의도를 물어보는 것을 우선으로 한다.
- 게임성은 곧 게임의 재미요소다. 자기 주관만으로 건의 사항을 내 놓아도 정말 유저에게 먹힌다라는 확신은 없기 때문에 기획자의 의도가 파악되는 한은 기획자의 의도를 받아 들이도록 한다. 서로 게임성에 대해 지향하는 방향이 다른 상태로 건의가 전달되어 테스트팀과 개발팀의 사이가 어그러 질 수도 있다. 최악의 경우 소통의 문제로 발전해 업무에 큰 방해가 되 수도 있기 때문에 조심해야 할 부분이다.

2. 데이터를 확보할 수 있는 건의사항은 데이터와 함께 전달한다.
- 데이터를 근거로 사용 할 수 있는 개선사항도 있다. 예를 들면 FPS게임의 총기 밸런스와 같은 부분이다.
- 총기 밸런스는 다른 총들과 데미지, 연사시간, 집탄력을을 비교해서 필요 시 건의사항을 작성할 수 있다. 새로 내놓는 총기가 기존 총기에 비해 너무 강하거나 약한 경우 데이터를 비교해 건의를 작성할 수 있다.

3. 데이터를 모을 수 있지만 건의사항 작성은 하지 않는게 좋은 경우도 있다.
- 데이터를 모으기 위해 테스트 리소스가 과다하게 사용되는 경우에는 지양한다.
- 데이터의 수집이 반드시 필요한 경우 실서버 등에서 유저의 로그등을 수집해서 분석하는 방식으로 우회 적용은 가능하다.



주의사항!
QA로 일을 하게 되어 게임 제작에 참여한다고 생각해 테스팅보다는 건의사항이나 리뷰에 더 치중하고 싶어하는 사람들이 많다. 그러나 곧 자신의 건의사항이 받아들여지지 않는 것에 많이 좌절하기도 한다. QA가 물론 Quality Assurance로 품질을 보증하는 업무가 맞기는 하지만 QA는 기획자가 아니다. 기획자가 미쳐 생각하지 못했던 기획의 구멍을 찾아내거나 개발자가 미쳐 수정하지 못한 코드적인 문제는 찾아내어 서포트 해주는 업무가 되어야 한다.
하지만! QA(서포트)=심부름꾼으로 여겨지는 것 역시 곤란하다. 각 담당자들의 소통간 문제로 서로간의 마음이 상해서 공유되어야 할 내용이 공유되지 않아서 문제되는 내용이 작업물에 고스란히 반영되는 피해는 없어야 한다.