아, 그거 기획 의도예요

QA의 자세

QA(Quality Assurance)가 이슈(결함, 문제)를 발견해 개발자가 이를 수정하도록 하는 과정은 다양한 커뮤니케이션을 통해서 이뤄진다. QA는 업무 중에 이슈로 보이는 증상을 발견하면 이것이 진짜 문제인지 기획자나 개발자에게 확인하는 과정을 거쳐야 한다. 내 경우 이슈를 버그 트래킹 시스템(BTS. Bug Tracking system)에 등록한 뒤 기획 의도(As Design)라는 사실을 종종 봤다.      

쉽게 말해, 기획자가 ‘아, 그거 기획 의도예요’라고 말하는 경우다.     

다른 표현으로 ‘이거 스펙(Spec)입니다’라고도 한다. 저기서 스펙은 기획 의도라는 의미를 내포하고 있다. QA로서 가장 힘이 빠질 때가 이 소리를 들을 때다. 이렇게 발견하기 어려운 버그를 찾아내고 재현까지 하고 사진이나 동영상으로 남기기까지 했는데 스펙이라니. 라이브 (실제 게임 사용 환경)에서 유저들이 겪으면 불만이 나올 텐데.라고 생각하면서 자리에 돌아올 수밖에 없다.     

물론, 버그까지 재현 스텝의 복잡성, 개발 수정의 우선순위, 중요도 등 여러 가지 요소를 고민했을 때 당장 수정이 불필요한 버그들도 있다. 그러나 테스트하고 있는 콘텐츠나 기능은 기획자나 개발자들이 더 잘 안다. 그들이 기획 의도로 본다면 아쉬움을 뒤로할 뿐이다. 

이때 중요한 건

스펙 혹은 이슈로 판단되는 현상을 마주했을 때 QA는 기획서를 본다. 그리고 어느 부분에 해당하는지 찾는다. 여기서 중요한 건, 기획자나 개발자에게 ‘이게 기획 의도가 맞는지 증명해’가 아니다. QA로서 내가 어느 부분을 더 점검해야 하는지 하는 추가적인 확인이다. QA 업무를 논외로 하더라도, 일하다 보면 내 고집이 생기는 부분이 있을 수 있다. 이 고집에 빠져 ‘내 말이 맞는다’라는 논리가 ‘더 좋은 게임을 개발하자’의 논리를 집어삼키면 안 된다. 무엇이 우선인지 항상 냉정히 생각해야 한다.     

또한, 기획서에 명확하게 서술되지 않는 내용이 테스트 중에 발견될 때가 있다. 이때는 항상 ‘사용자가 봤다면 어떻게 느끼고 생각할지’가 기준이 되어야 한다. 문제의 수정은 누구에게 이 책임이 있냐가 아니다. 핵심은 최대한 빠르게 원인을 파악하고 제품을 품질을 높이는 거다. 이런 과정들이 비효율적으로 보일지도 모른다.  

    

하지만, 게임 회사에서, 게임의 개발 과정에서 가장 원칙을 고수해야 하는 사람들은 바로 QA다. 그게 QA의 존재 이유다.