2021.08.13 Technology: Push the Boundaries

QA 테스트 자동화에 도전하다

자동화는 인류의 오랜 로망이었습니다. 단순 반복 작업을 기계가 대신하게 하려는 시도는 기원전 215년 이집트 알렉산드리아 신전의 성수 자판기*부터 250년 전 독일의 자동 글쓰기 인형 오토마타**까지 거슬러 올라갑니다. 그 시대의 인류는 인공지능이 이렇게 발달할 줄 상상이나 했을까요?

컴퓨터가 막 도입되던 시기, 기계가 한 계산을 믿지 못해 주판알을 튕기며 사람이 검산해서 확인했었다는 지금은 농담 같은 이야기가 전해집니다. 하지만 지금도 여전히 사람이 하지 않으면 불가능할 거라고 여기는 영역들이 있습니다. 엔씨의 공통 QA(Quality Assurance)실 SET팀 김종원 팀장이 처음 ‘게임 테스트 자동화’라는 말을 꺼냈을 때 사람들의 반응이 그랬습니다. 게임 QA 테스트는 사람이 직접 할 수밖에 없는 영역이며, 자동화는 허상이라는 반응이 대부분이었습니다. 그러나 김종원 팀장은 포기하지 않았습니다. 엔씨의 모토처럼 기술은 ‘가능한 것’의 한계를 넓히기 위한 것이니까요.

‘Technology: Push the Boundaries’ 시리즈에서는 이러한 엔씨인들이 각자의 분야에서 한계에 맞서 끊임없는 도전으로 탄생시킨 ‘기술’을 소개합니다. 그 첫 번째 이야기는 게임 QA의 자동화 테스트를 향한 도전입니다. 이 이야기는 ‘기본적이고 반복적인 테스트를 자동화할 수는 없을까?’라는 생각에서 출발합니다.

*기원전 215년 이집트 알렉산드리아 신전에 설치된 ‘성수(聖水) 자판기’는 문헌에 기록된 최초의 자판기다. 고대 그리스 과학자 헤론이 쓴 ‘공기역학’ 에 소개됐지만, 누가 발명했는지는 알려지지 않았다. 위쪽의 구멍에 동전을 넣으면 지렛대의 원리로 아래쪽 구멍의 뚜껑이 열려 물이 흘러나오는 방식이었다.

**오토마타’는 그리스어로 ‘스스로 작동하는 기계’란 뜻을 가진 ‘오토마타’는 250년 전 독일에서 약 6,000여 개의 기계 부품으로 만들어졌고, 스스로 펜에 잉크를 찍어가며 40자 정도의 글을 쓸 수 있다.

technology_210813_01

*리니지의 ‘진명황의 집행검’ 


New Craving: 게임 테스트를 자동화할 수 없을까?

한 게임이 출시되기까지 수십만 번 반복되는 테스트 수작업

게임을 제작할 때는 수많은 검증 테스트가 필요하다. 이는 수많은 시간과 인력을 필요로 하며 게임 내용이 조금이라도 바뀔 때마다 다시 해야하는 고강도의 작업이다. 이를테면, 아이템이 1,000개일 경우 1,000개 모두가 잘 동작하는지 사람이 직접 하나씩 테스트해봐야 하는 것이다. 이러한 테스트는 비효율적이기도 하지만 휴먼 에러가 발생하기도 쉽다. 엔씨 게임의 테스트를 담당하는 공통 QA실 SET팀 김종원 팀장은 조금 더 효율적인 방법을 찾고자 했다. 바로 스크립트가 사람 대신 자동적으로 테스트를 수행하는 방법이었다.

일원화된 환경으로 테스트 커버리지를 확장하라

김종원 팀장은 우선 게임 자동화 시스템 개발을 위해 크게 두 가지 목표를 설정했다. 첫 번째는 게임 QA에 일원화된 자동 테스트 환경을 제공하는 것이고, 두 번째는 게임 개발 과정에서 자동화에 적합한 테스트 영역을 개발해서 테스트 커버리지를 확장하고 궁극적으로 게임의 퀄리티 향상에 기여하는 것이었다.

자동테스트의 첫 프로토타입을 본 사람들은 테스트 로그만 잔뜩 나오다 ’성공’이라는 결과만 뜨는 걸 보고 당황했다. 그래서 자동 테스트 결과를 확인하기 쉬운 리포트 형태로 제공하기 위해 테스트 스크립트 관리와 테스트 결과 리포트 제공 서비스를 만들기로 했다. 테스트마다 달라지는 스크립트나 데이터를 브라우저에서 바로 편집할 수 있게 한 것이다. 기기 검색과 현재 사용 여부도 확인하기 쉽게 했다. 여러 테스트를 순서대로 시행하거나 여러 기기에 나누어 할 수도 있게 했다. 테스트 로그를 모두 남겨 테스트 실패 원인을 찾을 수 있게 만들고 체크 항목마다 스크린 숏과 전 과정을 녹화해 테스트 과정을 확인해 볼 수 있게 만들었다. 테스트 환경도 최대한 하나로 통일했다. 모든 테스트 스크립트 관리를 일원화하고 기기나 네트워크 플랫폼이 달라도 동일한 방식으로 사용할 수 있게 했다. 플랫폼이 달라도 서비스하는 게임의 버전이 같으면 원칙적으로 가급적 동일한 테스트 스크립트를 적용하고 게임 엔진이 달라도 동일한 스크립트 언어와 개발 툴을 사용하게 했다. 리포트 형식을 최대한 동일하게 유지해서 테스트 목적이 달라도 리포트를 보는 사람들이 익숙한 포맷으로 제공했다. 이런 테스트 환경의 일원화를 위해 ’테스트 워크벤치’를 만들었다.

일관된 사용자 경험을 위해 만들어진 ‘테스트 워크벤치’의 구조도

테스트 워크벤치의 주 사용자는 게임 QA나 스크립트 개발자다. 테스트워크벤치 시스템을 사용하면 사용자는 테스트하는 기기의 종류나 플랫폼에 상관없이 테스트 결과의 해석에만 집중할 수 있다. 현재 안드로이드, IOS, 앱 플레이어, 퍼플까지 지원하고 있다.

이를 통해 결과적으로 자동 테스트의 커버리지를 확장할 수 있었을 뿐만 아니라 자동테스트 영역 자체도 확대되었다. 예를 들면 게임 QA가 매뉴얼 테스트를 진행하기 전 기본적인 테스트 수행이 완료되었고, 정기 점검 시간에 기껏해야 사람이 서버 두 개 정도를 점검할 수 있었던 것을 30개까지 늘릴 수 있게 되었다. 아이템 상자를 수천 번씩 열어서 기획에서 의도한 확률이 실제로 나오는지 확인하는 등의 단순 반복 테스트도 자동화되었다. 또한 주말, 새벽 등 시간에 구애받지 않고 테스트를 수행할 수 있게 되었다. 외주를 주기도 하던 반복적인 업무를 자동화함으로써 엄청난 발전을 이룬 것이다.

리니지2M의 라이브 서버 자동 점검 영상: 자동화 테스트를 한눈에 알아보기 쉽게 하기 위해 첨부한 이 동영상은 자동 테스트로 만든 QA 중 각 서버군을 점검하는 테스트 시연 영상이다. 리니지2M의 게임 서비스 점검 시 13개의 기기에서 동시에 자동으로 테스트가 수행된다.

Never-ending Challenge: 장애물을 하나씩 넘어서

시시각각 변하는 게임 UI와 스크립트, 물리적인 문제까지

모든 개발 과정이 그렇듯 해결해야 할 문제는 끊임없이 나왔다. 스크립트를 개발하는 도중에도 게임의 UI가 계속 바뀌었고, 게임마다 적용된 게임 엔진이 달라서 새로운 게임이 출시되거나 엔진 버전이 업데이트될 때마다 새로운 플러그인을 만들어야 했다. 테스트 스크립트가 늘어날수록 변경 사항들도 늘어났다. 테스트 기기 수가 늘어나면서 배터리 방전 등 물리적인 문제도 발생했다.  또한 게임 개발팀이 여유가 없어 자동 테스트 빌드를 나중에 주겠다고 하는 경우도 있어 자동 테스트용 빌드를 직접 빌드하고 테스트하기 위해서 배포하기도 했다.

이런 문제들은 장애물을 하나씩 넘듯 해결해 나가야 했다. 우선 UI가 변화하더라도 검색할 수 있도록 게임 내 오브젝트 검색 방법을 다양하게 했다. 추가로 테스트마다 공통적인 스크립트를 따로 모은 공통 라이브러리를 만들어 하나의 라이브러리에서 여러 스크립트가 공통적인 부분을 활용하도록 했다. 물리적인 문제는 하나하나 시행착오를 겪으면서 해결했다. 모니터링 시스템을 도입하고, 원격 재부팅을 하고, 무선랜 AP를 추가했다. 개발팀의 사내 배포는 개발팀에서 사내 빌드에 디폴트로 포함해서 자동 테스트 빌드를 따로 만들지 않도록 바꾸었다.

공동 설계와 2,600번의 테스트로 신뢰를 확보하다  

자동 테스트를 개발하는 과정에서 게임 QA가 던진 질문은 아이러니하게도 ‘QA가 자동 테스트의 결과를 신뢰할 수 있느냐’였다. QA 입장에서 보면 단지 PASS라고 찍힌 결과지를 쉽게 신뢰하고 그냥 받아들이기가 어려운 것이 당연했다. 그래서 시행착오를 거치면서 게임 QA와 함께 테스트 영역 선정과 테스트 시나리오 설계를 했고, 확인하고자 하는 항목이 포함된 리포트 양식도 함께 설계했다. 그 결과 최근에는 2,600회 정도의 테스트를 연속적으로 시행하면서도 네트워크 오류 외에는 거의 테스트 오류가 발생하지 않는 높은 신뢰도를 확보했다.

technology_210813_04 (1)
technology_210813_04 (1)

자동 테스트 시스템 구현을 위해 게임 UI를 통제하라

그렇다면 자동 테스트 시스템은 과연 어떤 방식으로 구현했을까? 우선 게임의 UI를 웹 브라우저의 UI와 동일한 방식으로 다룬다. 파이썬 스크립트로 웹 UI를 컨트롤하듯이, 게임 UI를 컨트롤해서 전체적인 테스트를 수행한다. 스크립트 입장에서는 웹 화면의 구성 요소를 식별하는 방식인 XPath와 비슷하게 게임 UI의 식별자를 생성한다. 게임 클라이언트에 이런 역할을 하는 플러그인을 포함하는 빌드를 따로 만든다. 모바일 자동 테스트 시스템인 Appium에 이 플러그인과 통신하는 기능을 추가하고 모바일 웹과 게임 UI들을 모두 컨트롤해서 원하는 테스트 동작을 수행한다.

스크립트를 이용해서 게임을 제어하는 순서는 다음과 같다. 스크립트 명령은 Appium 서버를 거쳐 ‘게임 오브젝트 인스펙터’라고 부르는 게임 클라이언트에 들어 있는 플러그인에 UI 정보를 요청한다. 요청한 UI가 화면 표시 여부나 표시된 위치 또는 표시하고 있는 텍스트들과 정보를 전달하면, Appium이 안드로이드 OS에서 제공하는 UI Automator라는 기능을 이용해 터치 이벤트를 발생시켜 마치 사람이 터치한 것과 동일한 형태로 게임에 이벤트를 준다. 실제로 플러그인은 정보를 전달하고 있을 뿐 별다른 액션을 취하고 않으며 모든 것은 바깥에서 컨트롤 된다.

technology_210813_05
technology_210813_05

게임 오브젝트 뷰어로 게임 UI 정보를 파악한다

스크립트 작성자는 어떤 식으로 게임의 UI 정보를 알아낼 수 있을까? 바로 ‘게임 오브젝트 뷰어’라고 불리는, 게임 내 플러그인을 통해서 할 수 있다. 현재 화면에 보이는 게임 UI 구조의 스냅숏을 파악하는 툴을 이용하는 것이다. 화면 왼쪽에는 저장한 게임 화면들을 보여주는 스냅숏 히스토리가 나열되어 있고, 오른쪽에는 현재 화면의 UI 구조를 파일 디렉터리처럼 보여준다. 왼쪽에서 원하는 화면을 선택하면 그 화면에 속해 있는 UI 구조의 전체 스냅숏이 오른쪽에 보인다. 그 안에 있는 각각의 UI를 선택하면 해당 UI의 ID, 텍스트, 표시 여부, 좌표, 크기 등의 정보 여부를 확인할 수 있다. 리니지2M을 만든 언리얼 엔진 같은 경우, 언리얼 엔진의 요소인 액터, 슬레이트, UMG를 모두 다 UI 요소로 간주하고 이를 추출해서 요소의 특성을 같이 볼 수 있다. 또 화면 중앙을 클릭하면 커서 위치를 중심으로 오브젝트들을 검색을 해서 화면 중앙 하단에 그 오브젝트들에 대한 리스트를 표시한다. 스크립트 작성자가 이 리스트를 보고 실제 스크립트에서 어느 오브젝트를 사용해야 할지 결정한다.

Next Change: 자동 테스트가 가져온 변화

자동 테스트를 수행하는 테스트 워크벤치

자동 테스트 결과 리포트의 실제 예시와 테스트 워크벤치의 사용 과정을 한번 살펴보자. QA에 배포된 빌드가 테스트 가능한 수준인지 확인하는 테스트를 BAT라고 한다. 빌드가 올라오면 자동으로 실행되며 QA가 매뉴얼 테스트를 하기 전에 최대한 빠르게 자동 테스트를 수행한다. 이런 테스트는 테스트 워크벤치를 통해서 생성하고 실행하게 된다.

테스트 워크벤치가 실제 자동화 테스트를 동작시키는 장면: 위 영상은 테스트 워크벤치의 동작 화면이다. 테스트 워크벤치는 자동 테스트들과 기기를 관리하는 시스템이다. 테스트 생성창에서 테스트 이름을 선택하고 테스트가 수행될 네트워크 환경, 빌드를 선택한다. 테스트를 할 스크립트의 종류와 어느 버전의 스크립트를 수행할지도 결정한다. 영상에서는 안드로이드 기기와 iOS기기를 두 대씩 선택했다. 테스트 준비를 마치면 테스트 실행 버튼을 눌러서 테스트를 시행한다. 화면에는 테스트 별로 진행률이 표시된다. 상세보기를 통해서 현재 진행하고 있는 전체 테스트 목록을 볼 수도 있고 테스트 중간 결과도 확인할 수 있다. 테스트가 끝나면 결과 리포트가 생성이 되는데 테스트 중에 남긴 스크린샷을 한 번에 볼 수도 있고, 실패한 테스트 스크린샷만 따로 볼 수도 있다. 긴급 재난 알림 문자로 인해서 테스트가 중단되어 실패한 경우도 발생했었다. 이런 경우 상세한 상황을 파악하려면 테스트 과정을 녹화한 동영상을 열어서 테스트 과정 전체를 확인하여 정확한 원인을 파악할 수도 있다.

시간의 제약을 넘어 더 빠르고 정확하게

자동 테스트는 어떤 변화를 가져왔을까? 게임 개발 시 기능이 변경되면 업데이트된 내용만 사람이 직접 확인하고 변경되지 않은 기능은 자동 테스트를 통해 보다 수월하게 점검할 수 있다. 테스트가 정확할수록 작은 변화에도 취약하기 때문에 스크립트의 지속적인 관리는 필수다. 대신 테스트가 가능한 시간의 제약이 사라졌고 수백, 수천 가지 항목을 반복해서 테스트할 수 있다. 간단한 검증이라도 이를 반복하면 중요한 검증이 되는데 이른바 검증의 양질 전환을 이루어 낸 셈이다. 또한, 단순/반복 테스트를 자동테스트로 전환하면 사람이 실수할 수 있는 여지를 없앨 수 있다. 이러한 자동테스트의 진화는 궁극적으로 보다 양질의 게임을 만든다.

물속에서 자맥질하는 백조의 발처럼 보이지 않는 곳에서 양질의 게임을 만들기 위한 끊임없는 기술적 도전이 계속되고 있다. 물리적인 시공간의 제약을 넘어 모두가 즐거움으로 연결되는 무한한 가능성의 세계. 엔씨가 꿈꾸는 미래를 위해 엔씨인들의 새로운 도전은 앞으로도 계속될 것이다.

TOP