QA는 네고왕?
협상을 해보자
여러 회사의 QA 직군 모집 요강을 잘 보면 '커뮤니케이션 능력'을 필수적으로 요구한다. 대다수의 직업 직군이 커뮤니케이션을 필요로 하겠지만, QA는 다양한 영역에서 필요하다.
QA와 QA
QA와 개발자
QA와 기획자
QA와 퍼블리셔 담당자
업무 상 주로 대화하는 대상자들은 위와 같다.
QA와 QA
QA끼리에서 대화는 (평상시에도 중요하지만) 업무 상일 때 테스트 방법, 테스트 시 필요한 도구, 이슈 공유 등이 대부분이다. 물어보는 입장이라면 구체적으로 어떤 것을 테스트하는지 정확하게 설명해야 한다. 그다음은 도구다. 테스트 방법은 다양하고 그에 따른 도구들이 있다. 가령 서버 설정을 바꾼다든지, 계정 설정 변경 등이 그것이다. 이때 중요한 건 그 도구 기능을 어떻게 사용하는지 듣는 것도 있지만, 주의할 점은 무엇인지에 대해 알아야 한다는 점이다. 일부는 서버 전체에 영향을 미칠 수 있고 그렇다 보면 다른 테스트에 영향을 줄 수 있다. 또한 즉시 데이터가 클라이언트에서 반영되는 때도 있는 반면, 재실행을 해야 적용되는 경우도 있다.
QA들은 언제 어디서 협력을 할지 모른다. 이번 피처는 따로 일할지 몰라도 다른 영역에서 함께 일할 확률도 높다. 또한 같은 게임이기에 서로 믿고 의지해야 할 때도 온다. 원활한 정보 수집을 위해서라도 평소 친해지면 좋다.
QA와 개발자
QA에게 개발자들은 가장 많은 대화를 나눠야 하는 파트너다. QA는 개발자가 만든 빌드에서 업무를 진행해야 하고, 개발자는 QA가 전달한 다양한 메시지들을 통해 빌드를 수정해나간다. 중요한 건 감정에 치우치지 말아야 한다는 거다. 테스트 환경(dev)이든 라이브 환경이든 일단 무언가 제대로 개발되지 않았다면 QA는 불만을 가질 수밖에 없다. 그도 그럴 것이 테스트를 하다 보면 "처음부터 잘 만들었다면 이런 일은 없었을 텐데" 혹은 "빌드가 늦어서 야근을 해야 하잖아!"와 같은 불평을 쏟아낸다. 개발자 같은 경우 "처음부터 QA팀이 제대로 테스트를 했다면 이런 일은 없었을 거야"라며 QA를 원망할 수도 있다. (특히 이런 경우는 라이브팀일수록 문제의 심각성이 크다)
그런 상황에서 개발자와 대화는 매우 중요하다. 협상적인 부분을 따로 놓고 본다면, 대화의 목적은 주로 다음과 같다.
현재 이슈의 재현 유무
이슈의 심각성
버그 등록 시 테스트 환경에 대하여
구체적인 버그 재현 방법
개발자가 만든 QA기능에 대한 설명
스크립트 작동 등 특정 테스트 환경에 대한 요청
서버 작동 및 업데이트, 재시작
빌드 작동
위에 사례 말고도 개발자와 나눌 대화는 수없이 많다. 일상적으로 가장 많은 대화와 요청, 협상을 해야 한다. 이 때는 논리적인 설명과 QA로서 의견 제시, 그리고 설득이 필요하다. 논리적인 설명으로 왜 해당 현상이 문제이고, 버그인지 설명해야 한다. 또한 유저가 맞이할 게임 환경에서 과연 어느 정도 리스크가 있을지 이야기를 나눠야 한다.
QA와 기획자
QA는 기획에도 영향을 미친다. 무언가 보이지 않는 것을 만든다는 건 수많은 결함이 담길 수 있다. 기획이라는 일이 그렇다. 게임 내 새로운 모드, 새로운 영역을 개발할 때는 필연적으로 게임 속 다른 곳에 영향을 미친다. 이런 영역들을 기획 초기부터 잡아주고, 질문하는 것이 QA의 업무다. 때론 기획서에 그 정의가 없어서 버그라고 하기 애매한 상황이 만들어진다. 이에 대한 기획의도를 묻는 것도 QA가 반드시 할 일이다.
흔한 경우로 QA가 기획자보다 해당 게임을 오래 플레이해오고, 게임사에서 근무했다면 게임 내 다양한 기능에 대해 잘 알 수밖에 없다. 이는 기획자와 리뷰 시간을 가지는 동안 의견을 제시해서 기획을 보충하거나 버그를 미리 예방할 수 있도록 유도해야 한다.
QA와 퍼블리셔 담당자
개발사와 퍼블리셔(공급사)가 따로 있는 경우라면 흔치는 않지만 퍼블리셔 담당자와 대화할 때도 생긴다. 직접적인 대화도 할 수 있지만 보통 BTS(버그 트랙킹 시스템)을 통해 이뤄진다. 보통 유저들의 제보를 통해 퍼블리셔가 버그에 대해 인지하고, 개발사에 해결을 요청하는 경우다. 이때 개발사에 있는 QA는 해당 버그를 재현하기 위해 노력한다. 일반적으로 유저가 제보하는 버그는 그 스텝이나 재현 환경이 명확하지 않아 애를 먹을 때가 다반사다. 퍼블리셔와는 이 부분에서 댓글이나 메일 등 다양한 방법을 의견을 주고받는다. 이때 문제가 해결되지 않는 경우도 많다. 문제의 심각성이나 위험요소를 가만해서 어떻게 처리할지 정해진다. QA는 이때 게임사에서 가장 많이 게임을 플레이하는 만큼 적절한 의견을 제시해야 한다. 유저를 대변하는 존재임을 알고 요청이 이뤄져야 한다.
QA는 업무 속에서 수도 없이 많은 대화를 다양한 사람과 나눠야 한다. 각 직군과 적절한 협상 능력은 무시 못할 능력이다. 다음 시간에는 구체적으로 어떤 기법으로 대화를 가져야 할지 나눠보도록 하겠다.
