원본 링크: https://techblog.sega.jp/entry/2018/08/27/100000
QAエンジニアってどんな仕事？～ゲーム開発におけるテストの世界～ - SEGA TECH Blog
はじめまして。 セガゲームス「龍が如くスタジオ」専属QAエンジニアの阪上と申します。 今回は、QAエンジニアという職種の紹介とゲーム開発におけるテストの話を、「龍が如くスタジオ」
techblog.sega.jp
세가 게임스의 용과 같이 스튜디오에서 QA 엔지니어 직종의 테스트 자동화 관련 내용을 정리한 문서입니다.
QA는 Quality Assurance 의 약어, 품질 보증이라는 뜻을 가지고 있습니다.
게임 개발 단계에서 동작 확인, 버그 체크, 퀄리티 체크 등 하는 팀입니다.
게임이 커지다보면 테스트 등 모두 수동으로 하기엔 너무 방대하여 곤란하기에, QA 엔지니어 직종이 개발 환경이나 QA의 자동화 효율화를 진행합니다.
개발 환경으로는 빌드, 데이터 컨버팅 자동화, Redmine 등 티켓 관리 시스템 워크플로의 효율화 등 실시합니다.
빌드 엔지니어라고도 한다네요.
(필자) 요즘은 DevOps 엔지니어 또는 SRE라고도 많이하죠.
용과 같이 스튜디오에서는 QA 엔지니어가 겸임하면서 각 툴 담당자, 타부서 협력 등을 통하여 자동화를 진행하고있습니다. 이번 글은 테스트 이야기 중심이기 때문에 개발 환경의 자동화는 간단하게만 설명합니다.
자세하게 알고 싶다면 심퍼지엄 2016 도쿄의 강연 자료를 확인해주세요.
http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf
(2009년~) 자동 플레이 테스트
QA 엔지니어의 주된 일의 하나인 테스트 자동화에 대해, 용과 같이 시리즈의 역사와 함께 소개합니다.
용과 같이 스튜디오는 대규모 게임을 빠르게 출시하기 위해 개별 팀 및 팀 전체 개발 환경을 적극적으로 자동화, 효율화해 나아가려는 조직의 기조가 있습니다. 이러한 환경에서 등장한 것이 자동 플레이 테스트 입니다.
PS3 세대 타이틀 개발할 때 부터 오토 테스트라고 하는 독자적인 자동 플레이 테스트를 개발하여 운용하였습니다.
개발 멤버가 들어온 후 개발 환경(PC나 개발기기)를 활용, 심야에 자동으로 게임을 플레이하여 에러를 감지하는 시스템입니다.
오류 전송은 용과 같이 스튜디오 독자적인 크래시 리포트 기능
무작위로 플레이어를 이동시켜 벽에 부딪히고 콜리전 누락을 찾거나, 미리 준비한 패스(조작 순서를 커맨드화 한 것)에 따라 게임의 메인 시나리오를 클리어할 수 있는 등 광범위한 테스트를 자동으로 수행할 수 있습니다.
오토테스트 기능은 이후에 계속 진화하여 북두와 같이(2018년 발매)에서는 아레의 그림과 같이 메인 시나리오를 클리어하는 테스트를 진행하고 있습니다만, 대화중 O버튼으로 대화를 진행, 적과 배틀 상황일 때에는 플레이어를 배틀용 봇 AI로 전환하여 싸우는 등, 게임 상황에 맞춘 세세한 자동 테스트 기능을 추가해 다양한 버그를 검출할 수 있었습니다.
조합이 너무 많아 수동으로 테스트할 수 없었던 것도 오토테스트가 전임으로 실시하는 등, 수동 테스트와 협력 체제가 가능해지고 있습니다.
이와 같이 자동 플레이 테스트는 최근 AI에 의해, AI로 대체하는 일로 볼 수 있지만 어디까지나 오토 테스트는 수동 테스트의 보조 목적으로 사용하고 있습니다. 쉽게 발견할 수 있는 버그는 가능한 AI에게 맡기고 수동 테스트에서는 보다 복잡한 조건의 버그를 찾고 게임의 품질과 재미 향상에 주력했으면 하는 생각으로 매일 오토 테스트를 개량하고 있습니다.
(2013년~) QA 엔지니어의 탄생과 가속되어가는 테스트 환경의 자동화
용과 같이 스튜디오에서는 시리즈의 개발을 거듭할 때마다 개발과 QA 환경의 자동화가 진행되었습니다.
개발의 스피드 업, 게임 품질 향상에 공헌하는 반면, 자동화한 구조의 유지가 개발팀에게 부담이 되어왔기에 용과 같이 유신! (2014년 발매)의 개발로부터 제가 전속으로 QA 엔지니어링을 담당하게 되었습니다.
전속 QA 엔지니어를 개발팀에 두는 것으로 지금까지 자동화 환경을 유지하기 쉽게 정리 후 일원화하여 관리하거나 오토 테스트 기능 확장, 로그 분석 등 새로운 기능을 구현할 무렵, 용과 같이 스튜디오의 QA 엔지니어링 기술이 극적으로 진화하기 시작합니다.
(2015년~) 테스트 결과 분석
테스트를 자동화하는 것까지가 QA 엔지니어의 끝이 아닙니다. 자동화 도구로 자주 사용되는 Jenkins는 테스트 결과의 성공, 실패를 알 수 있지만, 테스트 결과를 더 자세히 알고 싶다는 요구가 있었습니다.
여기서 용과 같이 극(2016년 발매)에서 시험 운용을 거쳐, 드래곤 엔진으로 개발된 용과 같이 6: 생명의 시(2016년 발매)에서 도입한 것이 로그 분석 기능입니다.
아래의 그림은 오토테스트 실행 중 게임 내 VRAM(Video RAM, 그래픽 메모리)의 사용량을 수집하여 히트맵에서 볼 수 있도록 제공합니다.
▪ VRAM 히트맵(북두와 같이)
에덴이라는 거리의 VRAM 사용률을 히트맵으로 표시한 것입니다.
붉게 되어 있는 곳이 사용률이 높고, X가 100%를 넘어 수정이 필수인 구간입니다.
▪ 콜리전 누락 맵 (북두와 같이)
광야라는 광대한 맵에서 콜리전 누락을 표시한 맵입니다.
게임을 자동으로 플레이하고 있기에 명확한 에러(예외처리 또는 ASSERT) 이외 경고 레벨의 문제, 통상 게임 플레이와 같이 발생하고, 퍼포먼스 측정도 가능합니다. 이 내용들을 로그로 수집하여 보여주는 것으로 문제되는 부분을 찾는 수고를 줄일 수 있으니 수정을 정확하고 신속하게 실시할 수 있게 되었습니다.
또한 수동 테스트의 플레이 로그도 분석하여 게임 밸런스 조정에 사용하거나 바로 게임의 품질(재미) 향상에도 활용할 수 있게 되었습니다. 다음은 수동 테스트 및 자동 테스트 로그를 분석하여 게임 밸런스 조정에 활용한 사례입니다.
▪ 플레이어가 게임 오버가 된 장소 (용과 같이 6: 생명의 시)
수동 테스트로 플레이어의 HP가 0(게임 오버)이 된 지점을 가시화하여 게임 밸런스 조정에 활용.
▪ 아이템 드롭률 (북두와 같이)
적이 떨어뜨리는 아이템의 드롭률을 계측, 스펙의 확률 대로 아이템을 드롭하는지, 레어 아이템이 정말 드롭되는지 오토테스트를 통하여 계측.
이번에 소개한 오토테스트와 로그 분석은 소프트웨어 테스트 심포지엄 2018 도쿄에서 강연했을 때 자료보다 자세하게 설명하고 있으므로, 흥미가 있다면 봐주세요.
http://www.jasst.jp/symposium/jasst18tokyo/pdf/D4.pdf
▪ (2018년~) 테스트 피라미드의 고찰과 QA 엔지니어링의 미래
자동화하고 결과를 분석할 수 있게 해도 QA 환경을 쾌적하게 하는 노력에는 끝이없습니다. 현재 어느 업계에서도 AI 활용이 트렌드이지만, 지금까지 해왔던 자동화나 로그 분석을 기초로, AI를 활용한 새로운 자동화 및 효율화가 기대되고 있습니다.
지난주 개최된 CEDEC 2018에서는 차세대 QA와 AI ~게임 개발에 있어서 AI 활용을 올바르게 마주하기 위해~ 라는 세션에서 QA의 향후 진화, AI를 활용의 미래라는 테마로 패널 리스트로서 참가 요청 받았습니다. 이번에는 CEDEC 2018에서 소개한 테스트 피라미드에 대해 팔로우 업 하고자 합니다.
테스트 피라미드란, 테스트를 자동화 및 효율화 하는데 있어 그 생각의 베이스에 자주 사용되고 있습니다. 일반적인 시스템이나 웹개발에서는 이하와 같은 테스트 피라미드가 되는 것을 이상적으로 봅니다.
일반적인 테스트 피라미드
| UI 테스트 | 최종 제품에 가까운 테스트로 높은 비용으로 자동화하기 어려운 테스트. |
| 결합 테스트 | 기능 마다 실제 사용할 서비스에 결합, 문제가 없는지 동작 확인 등 실시하는 것. |
| 단위 테스트 | 기능별 테스트, 가장 저렴한 비용. |
비용이 적게 드는 단위 테스트를 늘리고 자동화함으로써 비용을 절감하면서 효율성을 높일 수 있습니다. 그렇다면 게임 개발의 테스트 피라이드는 어떻게 되는가 하면, 현재 상황은 다음과 같은 상황에 있을 것입니다.
게임 개발 테스트 피라미드 (현실)
| 수동 플레이 테스트 | 사람이 실제로 게임 플레이를 진행하는 테스트 |
| 스모크 테스트 | 게임의 기동, 각 모드가 올바르게 동작하는지 간이적으로 확인하는 테스트, 최신 빌드를 릴리즈할 때 최소한의 동작을 보장하기 위한 테스트임으로 짧을 수록 좋다. (1~5분 정도) |
| 엔진 라이브러리 테스트 | 라이브러리나 엔진을 사내에서 개발하는 경우, 샘플 등 정상동작하고 있는지 테스트한다. |
| 데이터 테스트 | 모델, 텍스처, 레벨 디자인 등 데이터 파일이 올바르게 게임내에서 동작하는지 개별적으로 테스트. 게임내에서 동적으로 테스트하거나, 컨버트시 정적 체크를 진행한다. |
위 그림에서 최종 제품에 가까운 상태에서 수동 테스트 비율이 높고 비용이 많이 들기에 피라미드 균형이 매우 나쁩니다. 고비용에 사람에 의존하는 테스트이기에 요즘 같은 인력 부족 시대에 게임의 스케일을 키우기에 매우 어려울 수 있습니다.
또, 게임 개발에서 데이터 드리븐 구조를 채용하는 경우가 많기에 데이터 버그가 매우 많은 구조로 되어있습니다.
(경우에 따라 프로그램 버그보다 많을 수 있습니다.)
단위 테스트라고 하면, 바로 느낌이 오지 않을수 있습니다만, 하나하나 데이터의 결함이나 일관성의 테스트, 최종적인 제품의 테스트전에 검출할 수 있으면 되돌아가는 코스트 등 번거로움을 줄이기가 어렵지 않다고 생각합니다.
용과 같이 스튜디오에서는 이번에 소개한 오토테스트와 로그 분석 외에도 데이터 컨버트시 에러 검출 강화, 스모크 테스트를 늘리는 등 개량을 더해 역 피라미드로부터 이하의 올바른 피라미드가 되도록 매일 개선하고 있습니다.
게임 개발 테스트 피라미드 (이상)
여기까지 읽으셨다면, 이상적인 피라미드 다이어그램을 보고 궁굼할지도 모릅니다. 왜 가장 높은 비용인 플레이 테스트를 자동화하는 것으로 시작했는지.
이것은 게임이라는 특성상 단체 테스트에서 결과가 화면 출력 밖에 없는 경우가 많아, 화면별로 결과가 안정되지 않아 판정하기 어렵기에, 자동 테스트의 에러를 개발 멤버가 에러로 받아들일 수 있는 두가지 이유가 있습니다.
특히 후자가 중요하고 오류가 나오면 수정해줘야 하지만, 자동 테스트의 에러에 대한 신뢰성이 낮은 경우, 이 에러는 제품에서도 일어나는 것인가? 라고 말해 수정되지 않은 채 방치 되어 테스트 자체 의미가 없어져버립니다. 우선 자동 테스트를 일반 게임에 가깝게 실행함으로써 신뢰를 받고 자동 테스트 오류를 즉시 수정하는 팀 문화를 만드는 것이 중요합니다.
용과 같이 스튜디오에서는 자동 플레이 테스트를 팀에 받아들인 뒤, 현재 진행형으로 저비용인 자동 테스트를 늘리고 있는 곳입니다. 자동 테스트를 처음부터 도입하는 것을 생각하는 분은 랜덤하게 플레이어가 움직이는 자동 플레이 테스트 부터 만들어 보고, 팀의 멤버에게 보여주는 것 부터 시작해보는 것은 어떻습니까?
댓글