페이퍼요약 - 게임 테스팅 기법의 개요 by Redavid

제목: 게임 테스팅 기법의 개요(An Overview of Game Testing Techniques)

저자: Claudio Redavid 외 1인, 스웨덴

문서유형: 대학교 페이퍼(총 8 페이지)

 

게임 개발 프로세스에서 적용되는 테스팅 단계 및 기법을 소개한 자료

---

배경

• 비디오 게임 산업이 빠른 속도로 성장 중. 2010년에는 627억달라(약 73조원)이던 세계 비디오 게임 시장의 가치가 2011년 6월에는 650억달라(약 75조원)로 증가
• 비디오 게임 산업이 단순 2D에서 3D 게임으로, 단순 GUI에서 상호작용(interactive) 환경으로 진화하였고, 복잡한 실시간 게임에 대한 요구도 증가
• 1980년대는 한 두 명이 게임 개발을 책임졌지만 2003년에는 수십 명이 참여한 팀으로 늘어남. 예) 2003년 ‘Tony Hawk Underground’라는 게임을 개발하는데 50명이 참여
• 오늘날 대규모 게임의 경우 수백 명이 개발에 참여하여 함께 작업하게 됨에 따라 체계적인 게임 개발 및 테스팅 기법이 중요해짐. 예) 2009년 ‘Assassins's Creed II’라는 게임 개발의 경우 450명의 개발자가 참여
• 개발 코드의 규모도 기존 100~200 라인에서 수천 또는 수백만 라인으로 증가

게임 개발 프로세스

1) 게임 개발의 역할(Game development roles)

게임 개발 팀은 아래와 같은 8개의 주요 분야로 나눌 수 있다.

• 설계 담당(Design parts): 창의적이고 재미있는 게임 아이디어를 고안하고, 이를 경제적, 시간적 제약에 따라 조정. 게임을 더 흥미롭게 만들어주는 레벨 및 대화 설계자도 존재
• 코딩 담당(Coding parts): 설계에 따라 게임 실행에 필요한 모든 코드(3D 엔진, AI 프로그래밍 및 도구 등)를 구현
• 미술 담당(Art parts): 현실적인 3D 모델 개발
• 오디오 담당(Audio parts): 현실적인 음향 효과 개발
• 관리 담당(Management parts): 프로세스 단계와 자원을 조정, 회사의 전략적 이슈 관리, 개발 내용 및 팀원들간의 충돌 해결
• 품질 보증 담당(Quality Assurance parts): 베타 테스팅이 시작되기 전에 소프트웨어 전체를 테스트하고 모든 부분이 의도한대로 작동하도록 만든다. 베타 테스팅은 게임을 반복해서 플레이하며 발견한 모든 문제점을 보고하는 자발적 지원자에 의해 수행된다.
• 사업 담당(Business parts): 손해가 발생하지 않도록 개발에 소요되는 자원을 조절
• 제조 담당(Manufacturing parts): 게임 개발 스튜디오와 판매점 사이의 커뮤니케이션 채널 역할

2) 게임 개발 생명 주기(Game development life cycle)

• 개념 개발(Concept Development): 소규모 팀이 새로운 게임 아이디어를 얻기 위해 브레인스토밍을 하고, 신규 게임에 대하여 간단하면서도 상세하게 기술한 개념 문서(a concept document) 작성
• 생산 전(Preproduction): 게임 설계서(the game design document), 기술 설계서(the technical design document), 프로젝트 계획서(the project plan), 게임 프로토타입의 4개 산출물이 개발된다. 기술 설계서에는 어떤 프로그래밍 언어(예, C#, C++, SQL, UnrealScript 등)를 사용할지, 게임의 어떤 컴포넌트를 기존 소프트웨어에서 재사용할지 또는 외부 벤더 제품의 라이센스를 구매하여 대체할지 등을 명세한다. 소프트웨어 개발을 실패하게 만들 수도 있는 문제점/리스크를 미리 식별하여 제거 내지는 피해를 줄이기 위한 노력을 한다.
• 개발(Development): 게임 요구사항과 설계 문서를 각각의 기술 분야로 분배. 유스케이스 다이어그램 같은 UML 스키마가 종종 사용됨. 게임 플레이어와 직접적인 상호작용이 없는 비가시 요구사항(non-visible requirements)들도 존재하는데, 로칼라이제이션(localization), 보안(Security), 이식성(portability), 데이터베이스 관리, 다수 쓰레드의 병행성(concurrency) 등이 여기에 해당한다.
• 알파/베타/코드동결(Alpha/Beta/Code Freeze): 완전한 테스팅이 시간적, 경제적으로 불가능하므로 품질 보증 계획에서 게임 릴리즈를 위해 달성해야 할 측정 가능한 품질 목표를 명확히 수립한다. 알파와 베타 테스팅 후 코드 동결(더 이상 수정이 허용되지 않음)
• 제조업자에게 릴리즈(Release to Manufacture): 게임이 (제대로 만들어졌다면) 릴리즈에 따른 이윤을 내기 시작하는 시점
• 패치/업그레이드(Patch/Upgrade): 유지보수를 담당하는 전담 팀이 버그 수정 및 기능 추가를 위한 패치를 만들어 배포하고 고객 지원을 한다.

개발 단계에 따른 게임 테스팅

• 생산 전(Pre-production): 대개 초반에는 테스터가 따로 존재하지 않지만 산출된 프로젝트 범위, 설계, 자산의 적절성을 검토하고 수정해야 한다. 소프트웨어 테스트 계획서(Software test plan document)도 초기 단계에 작성한다. 게임의 품질은 코드, 그래픽, 사운드를 평가하여 결정하며, 적절한 문서화 테스팅(프로젝트 계획서, 설계서, 테스트 계획서 등을 검토)도 문제를 초기에 발견하여 낮은 비용으로 수정할 수 있게 해준다.
• 착수(Kickoff): 특별한 테스트 지시 사항, 테스트 실행 관련 질문이나 이슈, 테스트 개선을 위한 제안 등을 다루어 테스트 및 품질에 대한 이해를 돕는 기회로 활용
• 알파(Alpha): 실제 테스팅이 수행되는 단계. 계획 단계에서 수립된 알파 기준(Alpha criteria)에 따라 알파 프로토타입을 테스트한다. 알파 테스팅이 진행되는 중에 여러 다른 프로그래머가 개발한 소프트웨어가 통합되고 게임 설계가 더 정교하게 튜닝된다. 게임의 시작부터 끝까지를 특정 경로에 따라 플레이하고 문제점을 수정한다. 게임의 모든 모듈이 적어도 한번씩은 테스트 된다.
• 베타(Beta): 알파 테스트가 종료된 후(게임 기능이 완성된 상태) 베타 테스팅을 시작. 베타 테스팅의 중점은 이미 개발 완료된 게임에 여전히 남아 있는 버그를 발견하고 수정하여 게임의 완성도를 높이는데 있다. 베타 테스팅은 대개 개발 팀이 아닌 외부 테스터에 의해 수행된다. 베타 테스터는 모든 가능한 경로에서 게임을 플레이 할 수 있고, 전체 사용자 인터페이스가 최종적으로 완성되어 있고, 게임 로직과 인공 지능이 최종적이며, 모든 컨트롤러가 작동하고, 최종 미술 및 오디오가 구현되어 있는지를 확인한다.
• 골드(Gold): 베타 테스트가 종료되면 게임 코드가 동결되므로 게임의 최종 빌드에 대한 짧은 시간 동안의 집중적인 테스팅이 수행된다. 과거 버그가 다시 나타나는지 확인하기 위해 모든(또는 시간이 허용하는 한 최대한의) 테스트 케이스들을 최종 빌드에 재수행 시킨다. 이 단계에서 발견되는 버그는 게임 릴리즈를 지연시킴(즉, 버그 수정 후 최종 빌드를 다시 구축해야 함). 골드 테스트에서 심각한 버그(시스템 충돌, 멈춤, 기능 실패)는 100%, 주요 버그(기능 및 성능 오류)는 90%, 사소한 버그(일부 사용자에게 영향을 주는 시스템 성능 이슈)는 85%를 해결해야 하며, 릴리즈 레벨 성능은 60-fps 프레임 속도를 달성해야 한다.
• 출시(Release): 게임이 골드 테스트를 통과하면 설치 및 배포를 위해 고객에게 전달된다. 이 단계의 게임 품질은 대량 배포(mass distribution)를 하기에 적합한 수준으로 간주된다.
• 출시 후(Post-release): 여전히 남은 버그나 개선을 위한 기능 추가가 있을 수 있으므로 패치 및 업데이트 필요. 매 패치 마다 개발 팀은 전체 버그 리스트를 재검토 하고 해결되지 않은 버그 중 수정이 가능한 부분은 패치에 반영한다. 신규 패치가 원본 게임 및 이전 패치 버전들과 함께 정상적으로 동작하는지 확인하는 테스팅이 수행 되어야 한다.

게임 테스팅 기법(Game Testing Techniques)

게임 테스팅에 효과적인 테스팅 기법들로 아래와 같은 것들이 있다.

• 조합 테스팅(Combinatorial Testing): 게임의 항목, 기능, 선택사항(예, 게임 이벤트, 게임 세팅, 게임 플레이 옵션, 하드웨어 세팅, 캐릭터 애트리뷰트, 커스토마이제이션 옵션 등)으로부터 패러미터를 도출하고, 같은 타입(homogeneous)의 패러미터를 조합하거나 또는 다른 타입(heterogeneous)의 패러미터를 조합하여 테스트를 생성한다. 페어와이즈 조합 테스트(Pairwise combinatorial tests)는 커버리지의 깊이(breadth)와 너비(depth)에 균형 있는 테스트를 제공하여 테스터가 특정 부분에만 집중하지 않고 게임 전체 영역을 골고루 테스트 할 수 있게 해준다.
• 테스트 플로우 다이어그램(Test Flow diagrams): 사용자의 관점에서 게임의 동작(behavior)을 표현한 모델을 생성하고, 이 모델의 모든 가능한 경로들을 실행하면서 예상하지 못한 게임 상태가 있는지를 테스트한다. 그래픽 모델이므로 검토 및 분석하기가 쉽고 테스트 설계자에게 피드백을 제공할 수 있다.
• 클린룸 테스팅(Cleanroom testing): 클린룸 테스팅 기법은 인증 가능한 레벨의 신뢰성(reliability)을 가진 소프트웨어를 개발하려는 클린룸 소프트웨어 엔지니어링 프로세스로부터 파생됨. 게임의 신뢰성을 향상하게 해 주는 클린룸 테스팅은 출시 전에 수백 시간의 테스팅을 거친 게임에서 왜 사용자가 여전히 버그를 발견하는지에 대한 문제를 다루고 있다. 클린룸 테스팅에서 게임팀의 테스트 전략은 실제 사용자들이 플레이 하는 대로 게임을 플레이 하는 테스트를 생성하는 것이다.
• 테스트 트리(Test Trees): 코드 변경 시 해당 변경 부분에 상응하는 테스트 케이스 집합을 선택할 수 있도록 테스트 케이스를 구성(조직)하는 사용성(usability) 기법. 테스트 트리는 복잡한 게임 기능에 대한 전반적인 이해를 돕고, 여러 다른 게임 규칙, 기능, 항목들과 얽혀서 복잡하게 상호작용하는 기능들을 유의해서 다룰 수 있게 해준다.
• 플레이 테스팅(Play Testing): 게임의 난이도, 재미, 균형(예, 과제가 충분히 도전적이지만 짜증을 유발할 정도는 아님, 게임을 배우기 쉽지만 지나치게 단순하지도 않음 등) 같은 비기능 측면(non-functional features)에서 게임을 평가. 플레이 테스팅은 사실 관계라기보다는 품질에 대한 주관적 판단이다.
• 애드혹 테스팅(Adhoc Testing): 비구조적 테스트인 애드혹 테스팅은 테스터가 직관에 따라 경로를 실행하는 것을 허용한다. 애드혹 테스팅은 프리 테스팅(free testing)과 직접 테스팅(direct testing)의 두 가지로 구분됨. 프리 테스팅은 계획이나 문서화가 전혀 없이 수행되는 테스트를 의미하며, 직접 테스팅은 특정 문제에 답을 찾기 위하여 즉석에서 실현되는 단발적인 테스트이다.