말도 안 되는 버그가 게임 출시 후 발견되는 이유

왜 QA가 못 잡는 버그가 있을까?

QA로서 게임을 제품으로 보면서 일을 하지만 그와 동시에 한 명의 플레이어이기도 하다. 이런저런 게임을 하다 보면 버그가 보인다. "이런 버그는 왜 라이브 서비스 전에 잡지 못했을까?" 또는 "이런 버그가 있는데 QA팀은 무엇을 하는 걸까?"라는 생각도 든다. 한 편으로는 종사자로서 "그럴 수도 있지"라고 넘어간다. 소프트웨어 테스팅 이론의 여러 가지 법칙 중에 한 가지가 있다.

"오류가 부재함은 궤변이다."

이른 완벽한 테스팅은 불가능하다와 비슷한 맥락이다. 문제점이 발견되지 않았다고 그것이 완벽한 게임이라고 부를 수 없다는 의미다. 그러나 이론에 갇혀할 일을 하지 않는 것도 문제라 생각한다.

테스트 환경과 라이브 환경은 다를 수 있다.

QA 업무를 하다 보면 버그인 줄 알았으나 버그가 아닌 케이스들을 종종 볼 수 있다. 기획 의도라거나, 알면서 고칠 수 없거나, 사이드 이펙트(부작용)가 우려되는 등 이유가 많다. 최근에는 새로운 이유를 들었다.

"비용으로 인해 QA환경과 라이브 환경이 다르게 구성되었습니다. 라이브에서는 발생하지 않을 이슈입니다."

네트워크에 과부하를 줬을 때 서버에서 나타나는 반응을 위한 테스트였다. 관련 이슈들을 많이 발견했는데 돌아온 답변이었다. 라이브에서 발생하지 않을 현상이라는 점은 다행이었으나 애초에 관련 내용을 개발팀으로부터 공유받았다면 어땠을까? 버그로 오해하고 하는 시간, 보고하는 시간 등 커뮤니케이션에 들어가는 비용을 줄였을 거라고 본다. 그러나 위 경우 개발팀도 사전에 알지 못했으며 문제를 해결하는 과정에서 인지했다고 한다. 

이번일을 통해 테스트 환경과 라이브 환경에 대한 차이를 사전에 파악하는 활동이 중요하다는 사실을 깨달았다. 언뜻 보면 당연하지만 생각으로 염두만 하는 것과 실제로 관련 팀에 요청하여 미리 정보를 얻는다면 그에 대한 테스트도 달라질 수 있다. 회사가 개발 비용에 크게 투자할 수 있는 환경이 아니라면 비용적인 이유로 테스트 환경과 라이브 환경 서버가 다를 수 있다. 이에 따라 파생되는 버그도 나올 수 있다. 

테스트 환경은 VR로 바라본 세상처럼 실제 서비스하는 라이브 환경이 아닐 수 있다.

QA가 테스트를 할 수 있는 환경이 라이브 서비스를 하는 환경과 동일하면 좋겠으나 사업적인 측면에서 여건이 여의치 않을 수 있다. 그럼에도 무엇이 라이브 환경과 테스트 환경이 다른지, 그에 따라 발생할 수 있는 버그는 무엇인지, 유사하게라도 환경을 비슷하게 할 수는 없는지, 라이브 서비스 후 대응은 어떻게 할 것인지 등 QA로서 생각할 일들은 무수히 많다.

끝으로 서두에 게임을 플레이하면서 손쉽게 발견되는 버그들을 보고 "그럴 수도 있지"라고 생각한다고 했다. 이건 같은 업계 종사자의 시선에서 언급한 말이다. 게이머는 고객이다. 제품을 구입한 사람이라면 다르다. 게이머를 고객으로 바라본다면 최대한 불편을 막으려는 태도가 필요하다. QA라면 더더욱.