게임회사 QA는 게임만 하나요?: ③ QA의 자질
[게임회사 QA는 게임만 하나요?] 시리즈 보러 가기 ▼
지난 글에서는 QA가 무엇인지 어떤 일을 하는지 알아봤다. 게임 QA가 된 지도 곧 3년 차에 접어든다. 오늘은 그간 느꼈던 ‘QA에게 필요한 자질’에 대해 말해보고자 한다.
QA는 네고왕?
여러 회사의 QA 직군 모집 요강을 잘 보면 '커뮤니케이션 능력'을 필수적으로 요구한다. 대다수의 직군이 커뮤니케이션을 필요로 하겠지만, QA는 정말 다양한 영역에서 소통 능력이 필요하다. 업무 상 주로 대화하는 대상자들은 아래와 같다.
QA와 QA
QA와의 대화는 테스트 방법, 테스트 시 필요한 도구, 이슈 공유 등이 대부분이다. 물어보는 입장이라면 구체적으로 어떤 것을 테스트하는지 정확하게 설명해야 한다. 또한 테스트 방법은 정말 다양하고 그에 따라 도구들이 있다. 가령 서버 설정을 바꾼다든지, 계정 설정 변경 등이 그것이다. 이때 중요한 건 그 도구 기능을 어떻게 사용하는지 듣는 것도 있지만, 주의할 점은 무엇인지에 대해 알아야 한다는 점이다. 일부는 서버 전체에 영향을 미칠 수 있고 그렇다 보면 다른 테스트에 영향을 줄 수 있다. 또한 즉시 데이터가 클라이언트에서 반영되는 때도 있는 반면, 재실행을 해야 적용되는 경우도 있다.
QA들은 언제 어디서 협력을 할지 모른다. 이번 피처는 따로 일할지 몰라도 다른 영역에서 함께 일할 확률도 높다. 또한 같은 게임이기에 서로 믿고 의지해야 할 때도 온다. 원활한 정보 수집을 위해서라도 평소 많이 소통해 놓는 것이 중요하다.
QA와 개발자
QA에게 개발자들은 가장 많은 대화를 나눠야 하는 파트너다. QA는 개발자가 만든 빌드에서 업무를 진행해야 하고, 개발자는 QA가 전달한 다양한 메시지들을 통해 빌드를 수정해나간다. 중요한 건 감정에 치우치지 말아야 한다는 거다. 테스트 환경(dev)이든 라이브 환경이든 일단 무언가 제대로 개발되지 않았다면 QA는 불만을 가질 수밖에 없다. 그도 그럴 것이 테스트를 하다 보면 "처음부터 잘 만들었다면 이런 일은 없었을 텐데" 혹은 "빌드가 늦어서 야근을 해야 하잖아!"와 같은 불평을 쏟아낸다. 개발자 같은 경우 "처음부터 QA팀이 제대로 테스트를 했다면 이런 일은 없었을 거야"라며 QA를 원망할 수도 있다. (특히 이런 경우는 라이브팀일수록 문제의 심각성이 크다) 그런 상황에서 개발자와 대화는 매우 중요하다. 협상적인 부분을 따로 놓고 본다면, 대화의 목적은 주로 다음과 같다.
위의 사례 말고도 개발자와 나눌 대화는 수없이 많다. 일상적으로 가장 많은 대화와 요청, 협상을 해야 한다. 이 때는 논리적인 설명과 QA로서 의견 제시, 그리고 설득이 필요하다. 논리적인 설명으로 왜 해당 현상이 문제이고, 버그인지 설명해야 한다. 또한 유저가 맞이할 게임 환경에서 과연 어느 정도 리스크가 있을지 이야기를 나눠야 한다.
QA와 기획자
QA는 기획에도 영향을 미친다. 무언가 보이지 않는 것을 만든다는 건 수많은 결함이 담길 수 있다. 기획이라는 일이 그렇다. 게임 내 새로운 모드, 새로운 영역을 개발할 때는 필연적으로 게임 속 다른 곳에 영향을 미친다. 이런 영역들을 기획 초기부터 잡아주고, 질문하는 것이 QA의 업무다. 때론 기획서에 그 정의가 없어서 버그라고 하기 애매한 상황이 만들어진다. 이에 대한 기획의도를 묻는 것도 QA가 반드시 할 일이다.
흔한 경우로 QA가 기획자보다 해당 게임을 오래 플레이해오고, 게임사에서 근무했다면 게임 내 다양한 기능에 대해 잘 알 수밖에 없다. 이는 기획자와 리뷰 시간을 가지는 동안 의견을 제시해서 기획을 보충하거나 버그를 미리 예방할 수 있도록 유도해야 한다.
QA와 퍼블리셔 담당자
개발사와 퍼블리셔(공급사)가 따로 있는 경우라면 흔치는 않지만 퍼블리셔 담당자와 대화할 때도 생긴다. 직접적인 대화도 할 수 있지만 보통 BTS(버그 트랙킹 시스템)을 통해 이뤄진다. 보통 유저들의 제보를 통해 퍼블리셔가 버그에 대해 인지하고, 개발사에 해결을 요청하는 경우다. 이때 개발사에 있는 QA는 해당 버그를 재현하기 위해 노력한다. 일반적으로 유저가 제보하는 버그는 그 스텝이나 재현 환경이 명확하지 않아 애를 먹을 때가 다반사다. 퍼블리셔와는 이 부분에서 댓글이나 메일 등 다양한 방법을 의견을 주고받는다. 이때 문제가 해결되지 않는 경우도 많다. 문제의 심각성이나 위험요소를 감안해서 어떻게 처리할지 정해진다. 게임사에서 플레이데이터를 가장 많이 쌓은 것은 QA이므로 적절한 의견을 제시해야 한다. 유저를 대변하는 존재임을 상기하며 요청을 해야 한다.
유저는 어떻게 할까?
소통 능력과 더불어 QA의 중요 덕목은 상상력이라 생각한다. 언젠가 퍼블리셔로부터 유저의 버그 재현을 부탁받은 적 있다. 퍼블리셔 CS로 들어온 경우다. 무조건 우리에게 떠넘긴 것은 아니다. 그들도 오랜 시간에 걸쳐 재현을 위해 노력했다. 그러나 실패했다. 그래서 개발사로 넘어온 경우다. 몇몇 건의 경우 결국 재현하지 못해 남아 있는 케이스도 있다.
버그를 고치기 위해선 버그 재현 스텝이 필수다. 문제를 해결해야 하는 개발자 처지에서 상황이 정확하게 구현되지 않는다면 버그를 고칠 수 없다. 내부 개발과정에선 이 재현 스텝을 곧잘 찾을 수 있다. 보통은 QA 본인들이 하는 업무 중에서 발생하기 때문에 이전 상황을 어렵지 않게 기억해낸다. 로그 등 다른 방법도 충분히 활용할 수 있다.
정말 어려운 경우는 제보에 의한 경우다. 이 경우는 정보가 턱없이 부족하다. 버그 사진이나 동영상, 사용 컴퓨터 정보 정도만 받는다. 그 어떤 로그 기록이나 정확한 스텝, 기타 사항에 대해 알 수 없다. 증거가 부족하니 추리하는 것도 여간 어려운 게 아니다. 무턱대고 해봐야 한다. 이래서 QA의 중요한 덕목 중 하나가 상상력이다.
평소 고객에 대해 반드시 알아야 하는 이유이기도 하다. 유저들을 모르면서 그들을 어떤 행동을 할 지 상상하고 대변할 수는 없다. 스스로 최근 고객들이 우리 회사 제품을 어떻게 이용하는지 알기 위해 현장을 방문했는가라고 물으면 답하기는 매우 어렵다. 게임의 고객, 게이머들을 보기 위해서는 PC방이나 E-Sports 스타디움을 가보는 게 가장 현명할 것이다. 그러나 실제로 방문하기는 현재 상황도 안 좋을뿐더러 대다수의 QA는 게임을 즐길 시간도 부족하다. 그래서 나온 대안이 커뮤니티들이다. 유명 커뮤니티부터 게임 사이트, 카페, 블로그, 뉴스, 고객센터 등 다양한 창구가 있다. 우리 회사의 경우 퍼블리셔에서 유저 동향을 파악해 정리한 리포트를 정리해 매일 메일로 공유해준다. 그러나 여기서 멈춰서는 안 된다. 누군가가 요약정리한 문서는 쓰는 이의 영향을 받을 수밖에 없다. 날 것의 유저 생각을 보기 위해서는 직접 봐야 한다.
결국 유저를 향하는 것
항상 고객의 입장에서 생각하는 태도가 필요하다. QA뿐만 아니라 다른 직군도 마찬가지다. 꼭 버그가 아니더라도 하나의 이미지나 문구 등이 고객의 마음을 상하게 할 수 있다. 대상을 여러 각도로 보기 위해 노력해야 한다.
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
