게임 테스트 자동화 장치 및 방법
TAS의 추억
출원번호/일자: 1020170103543 (2017.08.16)
등록번호/일자: 1018818040000 (2018.07.19)
'AutoQA'라는 슬로건으로 시작된 회사의 중요 전략 과제를 수행하며 출원했던 특허이다.
테스트를 자동화하는 궁극적인 목적은 '제품 출시의 속도를 빠르게 하는 것과 비용을 줄이는 것'이다.
내가 이 프로젝트를 처음 시작했던 2017년 당시, 회사에서 서비스하는 게임의 숫자는 점점 늘어나고, 개별 게임들의 빠른 업데이트 사이클로 인해 테스트해야 할 콘텐츠도 늘어나고 있는 상황이었다. 특히, 기능 회귀 테스트의 비용이 시간이 지나면 지날수록 커지고 있었고 게임의 출시 및 업데이트에 필요한 시간도 점점 늘어나고 있었다. 고정 비용이 지속적으로 빠르게 증가하고 있었으므로 어떤 식으로든지 테스트에 들어가는 인적 노력을 줄일 필요성이 생기게 된 것이다.
안타깝게도 게임에 특화된 자동화 테스팅 솔루션은 없었다. 물론 유명한 테스팅 툴들은 이미 많이 있었다. 하지만, 해당 툴들로는 게임 애플리케이션에 대해 만족스러운 테스트를 할 수는 없었다. 그 이유는 1) 실행 중인 게임의 상태를 알기가 힘들고 2) 게임의 상태를 다른 프로세스에서 변경하기가 쉽지 않기 때문이다.
조금 더 간단하게 예를 들어보면 웹, 데스크톱, 모바일 앱처럼 그래픽 기반의 UI가 있는 다른 애플리케이션들은 실행 중에 해당 프로세스의 상태를 알 수 있고, 그것을 변경할 수 있는 여러 가지 방법들이 주어진다. 이것은 마치 개발할 때 여러 라벨을 붙인 레고 조각들로 조립을 했다가 실제로 구동이 될 때에도 그 라벨이 붙은 레고를 내가 원하는 대로 확인하고 조작할 수 있는 것과 비슷한 느낌이다. 반면에, 게임 앱은 개발하는 과정에서는 라벨이 붙은 레고로 조립을 했다가, 앱을 빌드하고 나면 모든 라벨이 사라지고 여러 모듈로 분리되어 있던 레고의 조각들이 하나의 덩어리로 뭉쳐지는 느낌이라고 할까?
여담이지만 이 프로젝트를 맡아달라는 요청을 받았을 때 나는 거절했다. 물론 나에게 선택권은 없었지만 가능하다면 맡고 싶지 않았다. 그 이유는 간단했다. 내가 당시 시점으로 지난 7년간 통찰한 바로는 비효율은 도구가 없는데서 발생하지 않는다. 비효율은 사람이 만들어내는 것이고 사람이 하는 일이 효율화되지 않은 채로 아무리 도구를 쥐어줘 봐야 성과를 내기가 힘들 거라고 생각했기 때문이다. 먼저 사람이 하는 업무의 프로세스와 조직 구조를 효율화하는 것이 첫 번째라고 생각했고 그런 일에는 필연적으로 소프트웨어 공학보다는 휴먼 공학이 더 들어가기 때문에 본능적으로 피하고 싶었던 것 같다.
어쨌든 나는 이 도구를 만드는 프로젝트의 책임자가 되었고 이전에는 없었던 새로운 방법으로 문제를 풀어보려고 많은 노력을 했다. 우리에게 주어진 주요한 시스템 요구사항은 아래와 같았다.
1. 컴퍼니 그룹 전체에서 서비스하는 모든 게임을 커버할 것
2. 에뮬레이터가 아닌 실제 모바일 기기에서 수행할 것(Android와 iOS 모두 지원할 것)
3. 빠른 테스트를 위해 병렬로 테스트를 수행할 수 있을 것
4. 스크립팅 작업이 필요하다면 프로그래머가 아니어도 할 수 있는 수준으로 쉬울 것
위의 요구사항을 만족하기 위해 아래와 같은 기술 도전을 시작했다.
1. 주요 게임엔진들(Unity, Unreal, 기타 C++ 기반 게임엔진 like cocos2d-x)에 대한 SDK를 제공하여 게임이 실행 중에 그 상태를 쿼리 할 수 있고 변경할 수 있는 RPC를 게임 별로 자체 정의할 수 있도록 함
2. 모바일 OS(Androd/iOS) X 주요 OS 버전 X 점유율 높은 기기 X 게임엔진(Unity, Unreal,...) X 개별 게임 조합의 복잡도를 지원하는 디바이스 팜 및 디바이스를 매니징 하는 소프트웨어 시스템 구축
3. 스크립팅이 어려워서 포기하는 경우를 막기 위해 초등학생도 잘 다룬다는 비주얼 프로그래밍 언어(스크래치)로 테스트 스크립트를 작성할 수 있게 함
4. 모든 디바이스의 테스트 수행 현황을 중계 및 녹화할 수 있는 스트리밍 체계 구축(H.264 >> H.265)
위의 필수 기능 이외에도 고도화해 볼만한 도전 과제들도 많이 있었다.
1. AI 기반의 스크립팅 자동화: 실제로 이 정도 수준에는 도달하지 못했지만 스크립팅 시 추천 정도는 가능
2. SDK 탑재 없이 게임의 UI와 컴포넌트를 인식할 수 있는 Vision AI: RPG 류 게임에서 텍스트 박스, 버튼 등의 UI Object에 대한 Detecting 탑재
꽤 의미 있는 성과들이 있었다. 특히 게임 개발 단계에서부터 우리가 제공한 SDK를 탑재해서 게임 개발 사이클과 맞추어서 테스트를 자동화 한 프로젝트는 꽤 높은 테스트 커버리지를 시스템이 대체해줬다. 이 커버리지는 매 번 새로운 빌드가 레파지토리에 등록되면 미리 작성해 둔 테스트 스크립트가 수십대의 이종 기기에서 자동으로 테스트를 수행하고 리포트를 발행하는 형태로 이루어졌다.
우리가 만든 테스트 자동화 시스템은 "기능 테스트"에 특화됐다. 흔히들 많은 사람들은 많은 종류의 디바이스에서 비교적 간단한 테스트가 돌아가길 원했지만 애초에 우리 팀의 목표는 점유율이 높은 기기에서 콘텐츠를 깊게 테스트하는 것이 목표였다. 게임의 콘텐츠를 콘텍스트를 살린 채로 얼마나 유기적으로 테스트할 수 있는지가 중요했던 것이다. 최초에 내가 받았던 미션도 가장 비효율이 크게 발생하는 테스트를 자동화하는 것이었고, 호환성 테스트는 전체 테스트 업무에 10%도 채 안 되는 비중을 차지하는 반면 기능 회귀 테스트는 전체 업무의 70%를 차지하고 있었다.
수많은 사람들이 각자가 해석하는 테스트 자동화 솔루션을 만들어 달라고 요청했지만 스폰서가 요구한 본질에 벗어나지 않기 위해 최선을 다했고 결과를 냈다고 생각한다.
DOI: https://doi.org/10.8080/1020170103543
