[주석번역] Horizon Zero Dawn:오픈 월드 QA 사례 연구

 역자의 말.

한국 게임개발사에서 근무 했던 기억은 13년 전 쯤이 거의 마지막이었습니다. 이후 대부분의 시간을 중국 국적이지만 글로벌 기업에서 게임개발 프로젝트에 깊이 관여할 수 있었죠. 다른 중국인 동료들도 UBI 나 해외 게임사 출신들이 많았고 특히 기술부서는 EA 와 UBI 출신들이 많았어요. 지금의 한국 게임회사는 어떤지 모르겠지만 제 옛 기억으로 보면 개발 초기부터 QA 가 함께 협업 하는 곳은 일단 제가 본 적이 없었고 다른 3N 사에 다니던 후배들이 들려준 경험담으로도 거의 그런 케이스는 없다라고 그러더군요. 제 바램이라면 지금의 한국 게임사나 스타트업은 꼭 개발 초기부터 내부 QA 를 꼭 두시고 함께 협업하시길 바랍니다. 제 경험이라면 초기부터 QA  과 함께 개발을 하고 소통 할 때의 결과들이 대부분 다 좋았기 때문이고 개발과정의 마일스톤을 설립 할 때도 꽤 분명해지는 효과도 얻었고요. 저는 개인적으로 내부 QA 부서와 인프라팀이 꼭 있어야 한다고 생각하는 개발자로서 이러한 분야에 꾸준히 연구 하고 공유 하도록 하겠습니다. 

절대 간과하지마 마세요. QA 는 정말 중요한 존재 입니다.

---

 

강연이 끝난 후 설문조사를 진행하겠습니다.

저는 게릴라 게임즈의 QA 매니저인 Ana라고 하며, 어떻게 호라이즌 제로 던을 테스트하면서 많은 버그를 놓치지 않았는지, 그리고 어떻게 정신력을 유지했는지에 대한 이야기를 들려드리고자 이 자리에 섰습니다.

Hands – QA, Production, played HZD

항상 기술적 한계를 뛰어넘어 왔습니다.

1.게릴라 게임즈 최초의 오픈 월드 게임, 최초의 액션 RPG 게임

2.RPG 요소, 오픈 월드 설정, 비선형적인 게임플레이로 인해 개발과 테스트 과정에서 고려해야 할 변수가 많았습니다. 컴포넌트와 시스템 간 상호 의존성이 많았습니다.

3.오픈 월드 게임을 제작할 수 있는 툴이 없었기 때문에 처음부터 새로 만들어야 했습니다.

4.새 프로젝트를 지원하기 위해 데시마 엔진을 완전히 개편해야 했습니다.

5.범위를 모르고, 게임플레이의 많은 부분을 정의하지 않았으며, 알고 있는 부분에 대한 구현 세부 사항도 없었습니다.

6.이전에는 이와 같은 작업을 해본 적이 없었습니다.

1.범위에서 가장 무서웠던 부분은 게임 컴포넌트가 모두 서로 연결되어 영향을 주고받는 방식이었습니다.

2.더 이상 깔끔하게 구분되어 따로따로 테스트할 수 없었고, 변경 사항이 어떤 영향을 미칠지 예측하기 어려웠습니다.

3.레그 헌터 예시 프로젝트 전체에 걸쳐 내부 팀은 8명에 불과했습니다.

4.킬존 프로젝트와 동일한 테스트 접근 방식을 적용할 수 없었고, 이전에 해본 적 없는 새로운 것을 생각해내야 했으며, 성공할지 실패할지 알 수 없었습니다. 또한 프로젝트에 대한 초기 정보가 이전보다 훨씬 적었기 때문에 예상하고 계획하기가 훨씬 더 어려웠습니다.

5.내부 QA와 외부 테스트 파트너였던 소니의 퍼스트 파티 QA 모두 오픈 월드 게임 테스트 경험이 없었습니다.

이러한 일의 핵심은 사람, 프로세스, 도구입니다.

제가 게릴라에 입사했을 때만 해도 창문도 없는 방에 3명이 모여서 "게임을 플레이하고 버그를 찾아내는" 업무를 담당했습니다. 개발자들은 "QA"라는 단어만 들어도 눈을 동그랗게 뜨곤 했습니다. 지금은 QA 팀이 스튜디오의 필수 요소로 자리 잡았고, 개발자들이 "감사하다"는 의미로 고급 초콜릿을 가져다 주는 등 많은 발전이 있었습니다.

HZD의 프로토타입 단계부터 참여.전문 QA는 해당 분야에 대한 깊은 지식을 습득하고 이를 바탕으로 해당 분야에 대한 테스트 전략을 결정했습니다. 이러한 지식은 엄청난 가치가 있으며 테스트의 품질과 효율성을 크게 향상시켰습니다.내부에 있었던 덕분에 QA는 개발팀과 좋은 관계를 형성하고, 프로젝트의 모든 단계에서 필수적인 정보 루프와 피드백 루프를 구축할 수 있었습니다.

저희 QA는 대부분 자율적으로 일하며 자신의 지식과 경험을 바탕으로 업무와 접근 방식에 대한 결정을 내릴 수 있도록 장려됩니다.

덕분에 팀을 세세하게 관리하는 데 드는 시간이 훨씬 줄어들고 테스트 전략, 전반적인 게임 품질, 업무용 이메일에 넣을 가장 적합한 고양이 사진을 찾는 데 더 많은 시간을 할애할 수 있게 되었습니다.

오너십 = 전폭적인 투자, 이는 팀의 사기에 매우 중요한 요소입니다.

QA 전문가는 프로젝트에서 최악의 상황을 보게 되면 상당히 부정적인 시각을 갖게 될 수 있으므로 권한이 부여되면 이를 완화하는 데 도움이 됩니다. ( 역자 주: 한국에선 이런 개념을 본 적이 없고 역자가 중국 대기업등에서 근무 할 때 경험으로는 QA 팀장이 클라팀장과 거의 대등 한 권한이 있음 )

게이머로서의 전문성, 프로젝트에 대한 경험, 개발자와 플레이어의 중간에 있는 독특한 위치가 게임을 개선하는 데 활용되었습니다.

- 활 전투 느낌 분석 - 하지만 8명만으로는 게임 전체를 테스트할 수 없었습니다....

...그래서 소니의 퍼스트 파티 QA 팀을 불러들였습니다.

초기 단계부터 (KZ:SF보다 13개월 먼저) 참여시켰습니다.

처음부터 고객 서비스 제공업체가 아닌 진정한 파트너십을 구축하고자 했습니다.

우리는 매우 개방적이고 정직하게 소통했고, 소니에게도 같은 것을 기대했습니다.

또한 프로젝트에 대한 정보를 공유하는 데 매우 자유로웠기 때문에 일부 프로듀서들은 이 결정에 대해 부정적이었지만 감수할 만한 위험이라고 생각했고, 그 결실을 맺을 수 있었습니다.

-관리 병목 현상

-팀 리더는 많은 시간과 압박을 받습니다.

-대부분의 시간을 데이터베이스에서 보내거나 워크로드를 관리합니다.

-단일 장애 지점

-긴 통신 회선과 지연된 응답.

보다 효율적인 커뮤니케이션 전문 지식 공유.

작업에 대한 협업과 지속적인 피드백 루프로 효율성 향상.

단일 장애 지점 및 병목 현상 제거.

프로덕션/개발 팀의 기대치에 대한 소유권 공유.

개별 버디 팀이 구축하고 소유하는 책임 영역별 테스트 전략.

교육 및 개발 하나의 QA.

스튜디오 방문 및 공유 활동.

왼쪽 아래 사진은 하루에 3개의 방탈출 게임을 하고 이를 '팀 빌딩'이라고 표현한 QA 관리팀의 모습입니다.

우리는 진정한 파트너십을 구축하여 테스트 전략을 포함한 모든 부분에서 협업했습니다.

적응성:

  경량

  테스트 전략의 주요 개정 사항:

  개발 단계

  실패한 실험

  요구 사항 변경

확장성:

  매우 효율적인 교육 프로그램

  FPQA(외부QA조직)와의 협업

관련성

  테스터의 경험과 지식을 바탕으로 한 가이드

  위험 기반

  변화된 사항에 집중

효율성:

  도구와 기술의 도움

  70~90% 탐색적 테스트

예를 들어 '적응성'에 대해 좀 더 자세히 알아보겠습니다.

테스트 전략을 정의한 초기에 저희는 플레이어 유형과 페르소나를 조사했습니다.

이러한 페르소나와 원형을 테스트에 적용하면 고유한 문제를 발견할 수 있다는 전제가 있었습니다.

저희는 바틀 테스트와 몇 가지 다른 플레이어 심리 모델을 사용하여 9개의 페르소나를 구축했습니다.

호더의 예. 그래서 우리는 그것을 버렸습니다. 이것은 변화하는 요구 사항이나 지속적인 자체 모니터링 및 효율성 추구에 따라 프로젝트의 여러 지점에서 전략의 주요 수정이 어떻게 이루어졌는지를 보여주는 예일 뿐입니다.

다음으로 테스트의 효율성을 높이기 위해 사용한 방법 중 하나에 대해 말씀드리겠습니다.

저는 효율성을 좋아하고 제가 가장 좋아하는 것 중 하나입니다.

많은 체크리스트와 테스트 케이스, 복잡한 테스트 계획이 포함된 KZSF의 테스트 방법론은 더 이상 적합하지 않아 세션 기반 탐색적 테스트라는 방법을 사용하기로 결정했습니다.

소프트웨어 테스트에서 차용 - (Jonathan Bach, Satisfice)

왜 탐색적 테스트인가요?

  모든 것을 테스트할 수 없음 - 집중해야 함

  테스터의 터널 비전 방지

  전문 테스터 활용

  버그를 발견할 가능성이 가장 높은 방법

  매우 유연함

  광범위한 테스트 케이스가 필요하지 않음

예시: 헌장은 테스트 세션의 매개 변수, 즉 답변하고자 하는 질문을 정의합니다. 이 경우를 보면… 나열된 로봇에 대해 전기적 손상에 대한 저항이 올바르게 제거되었는가?

이 예에서는 이 특정 헌장에 대한 버그는 발견되지 않았지만 몇 가지 질문이 발생하여 이를 탐색하기 위해 새 작업을 만들었습니다. 때로는 테스트 중에 더 많은 질문을 발견할 수도 있습니다.

우리의 목표는 모든 버그를 찾아내는 것이 아니라 중요한 버그만 찾아내는 것이었습니다.

Bridge: QA는 단순히 버그에 관한 것이 아닙니다.

-개발 초기 단계의 첫 번째 라인 플레이 테스터는 QA였습니다.

-이러한 플레이 테스트를 통해 정성적인 피드백이 도출되었지만, AI

-Seeker 팀 - 490개의 이슈를 조사하고 259개를 Jira에 입력했으며, 이 중 138개(조사된 모든 이슈의 1/4 이상)를 수정하여 패치로 릴리스 했습니다.

-출시 후 지원 트랙에 대한 플레이어들의 반응은 매우 긍정적이었습니다.

-

전략에 대해 이야기했다면, 이번에는 프로젝트 기간 동안 QA 팀이 사용한 도구와 기술에 대해 자세히 알아보고자 합니다.

게임 내에는 250개가 넘는 디버그 그리기 모드와 창이 있습니다.

디버그 뷰를 통해 게임의 동작을 확인할 수 있습니다.

  최종 사용자가 사용할 수 없는 원시 데이터 또는 정보의 시각화 표시

개발자와 QA를 위한 추가 정보

내부 작업 노출

디버그 정보를 보여주는 동영상이 있으면 개발자가 무엇이 잘못되었는지 훨씬 더 빨리 파악할 수 있어 매우 유용합니다.

디버그 툴을 사용하면 게임의 동작에 영향을 줄 수 있으므로 테스트 속도가 빨라집니다.

 

감시자 - 시각적 인식 원뿔

 

대화형 버그 맵(FPQA에서 개발)

게임 분석 오버레이

Jira 통합

데시마에드(게임 에디터)

심층 디버깅

게임 분석

  탐색 전략 수립에 도움

LocQA 전략 및 진행 상황 보고의 핵심 부분

 

이것은 게임에 표시되는 실제 맵입니다. 게임 내 맵에서 버그를 시각화하는 것 외에도 버그의 첨부 파일을 미리 보거나 도구에서 Jira를 열 수 있었습니다.

왼쪽에는 많은 Jira 사용자 지정 필드와 기타 매개 변수를 사용하여 버그 분포를 자세히 분석하는 매우 포괄적인 필터링 시스템이 있습니다.

예를 들어 스트리밍 관련 버그 또는 예산 초과 메모리 버그만 토글할 수 있습니다.

또한 테스트 팀의 테스트 범위를 추적하거나 플레이 테스터의 게임 내 여정을 추적하기 위해 위치 데이터를 가져와 PSN ID로 필터링할 수도 있습니다.

이 도구를 사용하여 게임 내에서 테스터와 플레이 테스터 모두의 방문이 적은 영역이 있다는 것을 발견하여 조사에 집중했습니다(플레이어 위치 데이터가 채워지기 시작하면 경고 전에는 동영상 건너뛰기).

플레이어 위치에 대한 게임 분석 결과, 사용자나 테스터가 탐색하지 않는 영역이 몇 군데 있었습니다.

이를 조사하기 위해 탐색 테스트 차트를 만들었습니다.

나침반의 감지 범위가 너무 짧아 플레이어가 해당 영역에 존재하는 콘텐츠로 안내되지 않는다는 사실을 발견했습니다. 이 도구를 통해 놓칠 수 있었던 문제를 발견하고 수정할 수 있었습니다.

테스트 자동화에 대한 거대한 도전:

비선형 게임

오픈 월드

기존 자동화 프레임워크 없음

복잡한 자동화 스크립트를 생성하고 유지 관리하려면 보유하지 않은 리소스가 필요했습니다.

  큰 레벨에서 자동화된 이동과 플레이어의 움직임 테스트를 실험했지만, 유지 관리에 시간이 많이 걸리고 디버깅이 어려웠습니다.

우리가 선택한 솔루션은 전 세계를 돌아다니며 간단한 상호작용을 하는 자동화된 봇을 구현하는 것이었습니다.

 

프레임워크는 네트워크(TCP/Telnet)를 통해 세상에 대한 정보를 수신한 다음 수행할 작업에 대한 결정을 내립니다.

 

예를 들어 Aloy에는 다음과 같이 구성 가능한 우선 순위가 부여됩니다.:

1) 범위 내에 있는 로봇을 사냥하세요.

2) 수집품으로 이동하여 수집하기

3) 위의 어느 것도 얻을 수 없다면 지도의 특정 위치로 이동하는 것을 목표로 하세요.

 봇은 게임 분석 데이터를 생성하며, 발생하는 모든 어설트 또는 경고도 기록됩니다.

다음 슬라이드는 지금까지 논의된 사항을 요약한 것입니다.

신뢰 - 개방적이고 정직한 커뮤니케이션을 위한 필수 요소

커뮤니케이션 및 협업:

대화 회선 단축 및 확장

소통 장소의 장벽을 낮추세요

투명성

권한 부여 및 소유권

개별 스킬셋과 경험 활용

질적 피드백은 중요하며 투자를 촉진합니다.

이러한 사항은 일반적이고 당연하게 들릴 수 있지만, 역사적으로 QA는 개발팀과 분리되어 있었으며 최근에야 그 관계가 바뀌기 시작했다는 점을 기억하세요.

그리고 QA는 버그를 찾는 것 이상의 가치를 가져올 수 있다는 것을 기억하세요!

도구와 프로세스 모두에서 효율성을 지원할 수 있습니다.:

  테스터의 경험이 테스트 노력을 뒷받침해야 합니다.

  테스터가 정보에 기반한 의사 결정을 내릴 수 있도록 지원

  도구를 사용하여 테스트 속도를 높일 뿐만 아니라 개발자에게 더 관련성 있고 유용하게 만들 수 있습니다.

초점:

  시간 상자

  위험, 변화 및 취약 분야를 중심으로 구축된 탐색적 차트

  헌장의 결과에 따라 다음 단계가 결정됩니다.

지속적인 프로세스 개선

테스트 및 개발 팀이 무엇이 잘못되었는지, 무엇을 보고해야 하는지 파악하는 데 필수적인 도구 지원

도구는 테스트 전략을 지원해야 합니다.

개발자에게 필요한 것은 무엇인가요?

원격 분석을 통해 과거 데이터를 사용하여 향후 테스트 접근 방식을 추진할 수 있습니다.

재사용 가능한 테스트 데이터는 비선형 환경에 필수적입니다.

앞서 처음 시작할 때 범위가 알려지지 않은 요소였다고 말씀드렸는데, 이제 이를 측정할 수 있는 수치가 생겼습니다.

그리고 어려움 속에서도 우리가 해온 일과 성취한 결과를 돌아보니 기분이 매우 좋습니다.

플레이어, 동료, 언론의 매우 긍정적인 반응은 우리의 성공에 대한 증거입니다.

"호라이즌 제로 던을 플래티넘으로 플레이했는데 버그를 발견하지 못했어요"라는 말을 몇 번이나 듣거나 읽었는지 셀 수 없을 정도입니다.

-일일 교육 주기

-필수 정보

-테스터에게 한 번에 '모든 것'을 가르치려 하지 않고, 실수할 여지를 줄이고, 모든 사람의 개별적인 요구 사항을 외우느라 지치는 테스터를 피하고자 했습니다.

-교육은 테스터가 업무를 효과적으로 수행하는 데 필요한 도구를 갖추는 데 가장 필수적인 요소에 초점을 맞췄습니다. 테스트 방법을 알려주는 데 중점을 두지 않았습니다!

-트레이닝 사이클은 하루 동안의 스프린트를 중심으로 구성되며 각 사이클마다 특정 초점이 맞춰져 있습니다.

-몇 가지 예입니다;

-신규 시작자(Horizon 사용 경험이 없음).

-버그 분류, 디버그 시스템 개요, 테스트 기대치에 중점을 둔 교육

-디버그 시스템 개요에 초점을 맞춘 교육.

-새로 시작하는 모든 분들을 위해 각 버그 유형과 디버그 시스템에서 필요한 사항을 안내해 드렸습니다.

-각 버그 유형과 라이브 환경을 보여주기 위해 사용된 JIRA 기록 정보는 필요에 맞게 디버그 시스템을 조작하는 방법을 보여주기 위해 사용되었습니다..

-팀 규모를 확장하는 데 사용되는 숙련된 테스터

-테스터는 버디 팀에 직접 배정되어 전문 교육을 받고 요구 사항, 기대치, 디버그 시스템에 집중할 수 있습니다.

-리소스 이동성

-이러한 주기를 통해 QA 관리자는 교육에 많은 시간을 낭비하지 않고도 테스터를 즉각적인 커버리지/지원이 필요한 영역으로 이동할 수 있었습니다.

-온라인 기술 자료

-테스트 가이드, 디버그 튜토리얼, 보고서 템플릿 및 일반 도움말 가이드의 온라인 리포지토리(Confluence, SHIPWatch) .

-전문 지원

-버디 팀은 특수 쿼리를 위한 테스트 오라클로 사용됩니다.

-구체적인 집중 및 교육 제공

-각자의 책임에 대한 지식 공유를 통해 정보를 집중적이고 구체적으로 전달할 수 있습니다.