게임 테스트

Game testing
시리즈의 일부
비디오 게임 산업
발전
상품들
퍼블리싱
분배 및 수익화
관련된
목록

게임 개발의 하위 집합인 게임 테스트는 비디오 [1][2][3]게임의 품질 관리를 위한 소프트웨어 테스트 과정입니다.게임 테스트의 주된 기능은 소프트웨어 결함의 발견과 문서화입니다.인터랙티브 엔터테인먼트 소프트웨어 테스트는 컴퓨팅 전문 지식, 분석 역량, 중요 평가 기술 및 [4][5]내구성이 요구되는 고도로 기술적인 분야입니다.최근 몇 년 동안 게임 테스트 분야는 경제적으로나 [6]정서적으로 매우 격렬하고 보상이 없는 것으로 인해 비난을 받고 있습니다.

역사

컴퓨터와 비디오 게임의 초기에는 개발자가 모든 테스트를 담당했습니다.게임의 범위가 한정되어 있기 때문에 한두 명 이상의 테스터가 필요하지 않았습니다.어떤 경우에는, 프로그래머들이 [citation needed]모든 테스트를 처리할 수 있었습니다.

게임이 복잡해짐에 따라 "품질 평가" 또는 "품질 보증"이라고 불리는 더 많은 QA 리소스 풀이 필요합니다.대부분의 퍼블리셔는 다양한 개발자의 다양한 게임을 테스트하기 위해 대규모 QA 직원을 고용합니다.대부분의 퍼블리셔가 보유한 대규모 QA 인프라에도 불구하고 많은 개발자들이 현장 QA를 제공하기 위해 소규모 테스터 그룹을 보유하고 있습니다.

이제 대부분의 게임 개발자들은 프로그래밍 코드나 그래픽 레이어에서 결함과 '버그'를 찾기 위해 고도로 기술적이고 게임에 정통한 테스터들에게 의존합니다.게임 테스터들은 보통 다양한 플랫폼에서 다양한 게임을 하는 배경을 가지고 있습니다.세부 보고서에서 발견한 문제를 기록하고 참조할 수 있어야 하며, 과제 마감일을 준수해야 하며, 가장 어려운 환경에서 게임 타이틀을 완성할 수 있는 기술 수준을 갖추어야 합니다.게임 테스터라는 직업은 대부분 임금이 거의 없는 매우 스트레스가 많고 경쟁이 치열한 직업이지만 업계로 진입하는 통로 역할을 하기 때문에 많은 사람들이 찾고 있습니다.게임 테스터는 관찰력이 뛰어난 사람이며 게임 빌드에서 사소한 결함을 발견할 수 있습니다.

일반적인 오해는 모든 게임 테스터가 게임의 알파 또는 베타 버전을 즐기고 때때로 발견된 [5]버그를 보고한다는 것입니다.이와 대조적으로 게임 테스트는 알파 버전 이전에 확립되고 종종 지루한 방법론을 사용하여 버그를 찾는 데 매우 중점을 두고 있습니다.

개요

비디오 게임 산업은 표준적인 방법론을 가지고 있지 않지만, 품질 보증은 게임 개발에서 중요한 요소입니다.대신 개발자들과 출판사들은 각자의 방법을 가지고 있습니다.소규모 개발자는 일반적으로 QA 직원이 없지만, 대기업은 QA 팀을 상근으로 고용할 수도 있습니다.인지도가 높은 상용 게임은 출판사 QA [7]부서에서 전문적이고 효율적으로 테스트합니다.

테스트는 첫 번째 코드가 작성되면 바로 시작되고 게임이 [8][9]완료됨에 따라 증가합니다.주요 QA팀은 QA에 처음 제출할 때부터 제작 [9]후까지 경기를 모니터링하게 됩니다.게임 개발 프로세스 초기에 테스트 팀은 규모가 작고 새로운 코드에 대한 매일의 피드백에 집중합니다.경기가 알파 스테이지에 가까워질수록 더 많은 팀원을 고용하고 시험 계획서를 작성합니다.버그가 아닌 기능이 버그로 보고되는 경우도 있고 프로그래밍 팀이 처음으로 [10]문제를 해결하지 못하는 경우도 있습니다.좋은 버그 보고 시스템은 프로그래머들이 효율적으로 일하는데 도움을 줄 수 있습니다.프로젝트가 베타 단계에 접어들면 테스트 팀은 매일 명확한 과제를 갖게 됩니다.테스터 피드백은 최종 특징의 배제 또는 포함에 대한 최종 결정을 결정할 수 있습니다.새로운 관점을 가진 테스터를 소개하면 새로운 [9][11]버그를 식별하는 데 도움이 될 수 있습니다.이 시점에서 리드 테스터는 매일 생산자 및 부서장들과 소통합니다.[12]개발자가 외부 퍼블리셔를 보유하고 있는 경우 퍼블리셔의 QA팀과 조정을 시작합니다.콘솔 게임의 경우 콘솔 회사 QA팀을 위한 빌드가 전송됩니다.베타 테스트는 예를 들어 게임이 [11]멀티플레이어인 경우 지원자를 포함할 수 있습니다.

테스터는 개발자로부터 [citation needed]고유하게 식별 가능한 게임 빌드를 예약[11] 받습니다.이 게임은 플레이 테스트를 거쳤으며 테스터들은 발견된 오류를 기록합니다.이러한 오류는 버그에서 아트 결함, 논리 오류 및 레벨 버그에 이르기까지 다양합니다.테스트를 하려면 종종 교묘한 버그를 발견하는 창의적인 게임 플레이가 필요합니다.일부 버그는 문서화하기 쉽지만 개발자가 버그를 복제하거나 찾을 수 있도록 자세한 설명이 필요한 경우가 많습니다.테스터들은 버그를 여러 [citation needed]번 기록하지 않기 위해 동시성 제어를 구현합니다.많은 비디오 게임 회사들은 서로 다른 테스트 기술이 [5]필요하기 때문에 기술적 요구 테스트와 기능 테스트를 완전히 분리합니다.

게임 테스트 팀은 비디오 게임 개발이 마감 시간 전에 크런치 타임에 들어갈 경우 지체 없이 늦게 추가된 기능과 콘텐츠를 테스트해야 합니다.이 기간 동안 특히 멀티플레이어 게임에서 다른 부서의 [citation needed]직원이 테스트에 기여할 수 있습니다.Call of Duty: Black Ops [13]4를 개발하는 동안 Treyarch에서 특히 QA 팀이 지속적으로 문제를 해결한 사례가 있었습니다.

대부분의 회사들은 버그의 [14]심각도를 추정한 결과에 따라 버그의 순위를 매깁니다.

  • 버그는 게임이 발송되는 것을 막는 중요한 버그입니다. 예를 들어 게임이 [11]다운될 수도 있습니다.
  • B 버그는 주의를 기울여야 하는 필수적인 문제이지만, 게임은 여전히 플레이 가능할 수 있습니다.여러 개의 B 버그는 A [11]버그와 마찬가지로 심각합니다.
  • C 버그는 작고 잘 알려지지 않은 문제로,[12] 종종 버그보다는 추천의 형태로 나타납니다.

게임 테스터

게임 테스터는 게임 테스트를 수행하는 개발팀의 일원입니다.

역할

직원의 조직은 조직마다 다릅니다. 일반적인 회사는 테스트 분야와 관련하여 다음과 같은 역할을 사용할 수 있습니다.

  • 게임 제작자는 마케팅 및 품질 [15]보증과 함께 테스트 마감 시간을 설정할 책임이 있습니다.그들은 또한 타이틀의 전체적인 제작과 관련된 게임 테스트 이외의 많은 아이템들을 관리합니다.일반적으로 최종 제출 또는 "[16]금" 상태의 경우에는 승인이 필요합니다.
  • 리드 테스터, 테스트[10] 리드 또는 QA[7] 리드는 게임이 올바르게 작동하고[10] 버그 [11]목록을 관리할 책임이 있는 사람입니다.리드 테스터가 [7]QA 직원을 관리합니다.리드 테스터는 특히 프로젝트가 끝날 무렵에 디자이너 및 프로그래머와 긴밀히 협력합니다.리드 테스터는 버그 보고서를 추적하고 이 보고서가 [10]수정되었는지 확인할 책임이 있습니다.또한 QA 팀은 공식적이고 완전한 [11]보고서를 작성해야 합니다.여기에는 중복되거나 오류가 있는 버그 보고서를 폐기하고 [7]해명을 요청하는 것도 포함됩니다.게임이 알파와 베타 단계에 가까워짐에 따라 리드 테스터는 더 많은 테스터를 팀으로 불러들이고 외부 테스트 팀과 조정하며 경영진 [14]및 생산자와 협력합니다.일부 회사는 리드 테스터가 승인할 [12]때까지 게임이 금빛으로 변하는 것을 막을 수 있습니다.또한 리드 테스터는 일반적으로 ESRB [citation needed]및 PEGI와 같은 규제 기관에 제출하기 위한 게임 영상의 대표 샘플을 수집할 책임이 있습니다.
  • 시험관들은 게임이 작동하고, 사용하기 쉬우며, 말이 되는 행동을 가지고 있으며,[12] 재미있는 게임 플레이를 포함하고 있는지 확인할 책임이 있습니다.테스터는 정확하고 구체적인 버그 보고서를 작성해야 하며, 가능한 경우 버그가 [17]재현되는 방법에 대한 설명을 제공해야 합니다.테스터는 전체 제작 기간 동안 한 게임에 배정되거나 부서의 일정 및 특정 요구에 따라 다른 프로젝트에 참여할 수 있습니다.
  • SDET(Software Development Engineer in Test) 또는 Technical Testers는 자동화된 테스트 사례 및 프레임워크를 구축하고 전반적인 게임 성능 및 보안과 같은 복잡한 테스트 문제를 관리하는 책임이 있습니다.이러한 사람들은 보통 강력한 소프트웨어 개발 기술을 가지고 있지만 다른 응용 프로그램의 결함을 노출시키는 소프트웨어 작성에 중점을 둡니다.구체적인 역할과 임무는 스튜디오마다 다를 것입니다.많은 게임들이 테크니컬 테스터 없이 개발됩니다.

고용.

게임 QA는 일반 소프트웨어 QA보다 기술성이 떨어집니다.게임 테스터들은 대부분의 경우 경험을 필요로 하지만 때로는 고등학교 졸업장만 필요하고 기술적인 전문 지식이 없으면 [citation needed]충분합니다.게임 테스트는 보통 숙련된 [18]테스터들에게는 정규직이지만, 많은 직원들이 베타 테스터와 같은 임시 [2][19]직원으로 고용됩니다.경우에 따라서는 게시자가 고용한 테스터를 개발자 사이트에 파견하여 작업할 수도 있습니다.가장 공격적인 모집 시즌은 늦여름/초가을인데[citation needed], 휴가철에 맞춰 게임이 완성되고 출하되는 크런치 기간이 시작되기 때문입니다.

일부 게임 스튜디오는 기존 소프트웨어 테스트에 더 부합하는 기술적 접근 방식을 게임 QA에 적용하기 시작했습니다.기술 테스트 자리는 업계에서 여전히 상당히 드물지만, 이 직업들은 종종 장기간의 경력을 가진 정규직 자리이며 4년의 컴퓨터 과학 학위와 테스트 자동화에 대한 상당한 경험이 필요합니다.

어떤 시험관들은 게임 [3][20]산업의 디딤돌로 그 직업을 사용합니다.비기술적인 기술 집합을 보여주는 QA 레시제는 마케팅이나 [citation needed]생산보다는 관리 쪽으로 치우쳐 있습니다.프로그래밍, 아트 또는 디자인 분야의 지원자들은 이 [21]분야에서 기술적인 능력을 입증해야 합니다.fcnaz.com

보상

게임 테스트 담당자들은 보통 시간당 10-12달러 정도의 보수를 받습니다.시험 관리는 보통 더 수익성이 좋고, 경험과 종종 대학 교육이 필요합니다.매년 실시하는 설문조사에 따르면 테스터들은 연간 평균 3만 9천 달러를 번다고 합니다.3년 미만의 경력을 가진 테스터는 평균 US$25,000을 받는 반면 3년 이상의 경력을 가진 테스터는 US$43,000을 받습니다.6년 이상의 경력을 보유한 테스트 선두업체는 연간 [22]평균 미화 7만 1천 달러를 벌어들입니다.

과정

테스트 프로세스의 일반적인 버그 보고서 진행은 다음과 같습니다.

  • 신분증.잘못된 프로그램 동작을 분석하여 버그로 식별합니다.
  • 보고합니다.버그는 결함 추적 시스템을 사용하여 개발자에게 보고됩니다.보고서에는 버그의 상황과 재현 단계가 포함되어 있습니다.개발자는 버그의 발현에 대한 실시간 동영상과 같은 추가 문서를 요청할 수 있습니다.
  • 분석.아티스트, 프로그래머, 게임 디자이너 등 버그를 담당하는 개발자가 오작동 여부를 확인합니다.이는 게임 테스터의 직무 범위를 벗어나는 것이지만, 보고서의 불일치로 인해 테스터에게 더 많은 정보나 증거가 필요할 수도 있습니다.
  • 검증.개발자가 문제를 해결한 후, 테스터는 버그가 더 이상 발생하지 않는지 확인합니다.예를 들어 개발자가 모든 버그를 해결하는 것은 아니며, 회사 정책에 따라 일부 버그는 기능("NAB" 또는 "버그가 아님"으로 표현됨)으로 주장될 수 있으며, 프로듀서, 게임 디자이너 또는 심지어 수석 테스터에 의해 "웨이브"(무시할 수 있는 권한이 부여됨)될 수도 있습니다.

방법론

주요 기사:소프트웨어 테스트

게임 테스트를 위한 표준 방법은 없으며 대부분의 방법론은 개별 비디오 게임 개발자와 퍼블리셔에 의해 개발됩니다.MMORPG를 테스트하는 방법은 캐주얼 게임과 다를 수 있으며, 지속적으로 개선되고 게임 종류에 따라 다를 수 있습니다(예를 들어, MMORPG를 테스트하는 방법은 다를 것입니다).유닛 테스트와 같은 많은 방법들은 일반적인 소프트웨어 테스트 기법에서 직접 차용한 것입니다.비디오 게임에 특화된 가장 중요한 방법론은 아래에 요약되어 있습니다.

  • 기능 테스트는 게임을 어떤 형태로든 플레이하는 것을 수반하기 때문에 "게임 테스트"라는 문구와 가장 일반적으로 연관됩니다.기능 테스트는 광범위한 기술 지식을 필요로 하지 않습니다.기능 테스터는 안정성 문제, 게임 기계 문제, 게임 자산 무결성과 같은 게임 자체 또는 사용자 인터페이스 내의 일반적인 문제를 찾습니다.
  • 컴플라이언스 테스트는 게임 테스트 [clarification needed]연구소의 존재 이유입니다.콘솔 플랫폼에 대한 타사 라이센스 소지자는 자사 플랫폼에 대해 라이센스가 부여된 엄격한 기술 요구 사항 타이틀을 가지고 있습니다.예를 들어, Sony는 TRC(Technical Requirements Checklist)를, Microsoft는 Xbox Requirements(XR)를, Nintendo는 "가이드라인"(Lotcheck)을 발표합니다.이러한 요구 사항 중 일부는 고도로 기술적이며 게임 테스트 범위 밖에 있습니다.기타 부분, 특히 표준 오류 메시지 서식, 메모리 카드 데이터 처리, 합법적으로 상표 등록 및 저작권이 있는 자료 처리 등은 게임 테스터의 책임입니다.라이센스 승인을 위한 제출에서 단 한 번의 위반이라도 게임이 거부되어 추후 테스트 및 재제출에 추가적인 비용이 발생할 수 있습니다.또한 지연으로 인해 제목이 중요한 런칭 윈도우를 놓치게 되어 게시자에게 더 큰 비용이 발생할 가능성이 있습니다.
요구사항은 비밀유지계약에 따라 개발자와 게시자에게 공개되는 독점 문서입니다.이러한 표준에 대한 숙지는 [citation needed]시험관으로서 갖춰야 할 귀중한 기술로 간주되지만 일반인이 검토할 수 있는 것은 아닙니다.
컴플라이언스는 게임이 특정 콘텐츠 등급을 대상으로 하는 경우 ESRB 및 PEGI와 같은 규제 기관을 지칭할 수도 있습니다.시험관은 원하는 등급에 부적합할 수 있는 불리한 내용을 보고해야 합니다.라이센싱과 마찬가지로 원하는 등급을 받지 못한 게임도 추가 비용을 들여 재편집, 재테스트 및 재제출해야 합니다.
  • 호환성 테스트는 일반적으로 PC 타이틀의 경우 필요하며,[citation needed] 게임의 최종 빌드에 따라 호환성의 대부분이 달라지기 때문에 개발 막바지에 다다릅니다.종종 두 차례의 호환성 테스트를 거칩니다. 베타 초기에 문제 해결 시간을 확보하고 베타 말기 또는 릴리스 [citation needed]후보 기간 동안.호환성 테스트 팀은 다양한 하드웨어 구성에서 게임의 주요 기능을 테스트합니다.보통 상업적으로 중요한 하드웨어 목록은 [9]게시자가 제공합니다.
호환성 테스트를 통해 게임은 하드웨어와 소프트웨어의 다양한 구성에서 실행됩니다.이 하드웨어는 다양한 제조업체의 브랜드와 게임패드 및 [citation needed]조이스틱과 같은 다양한 입력 주변장치를 포함합니다.
시험관들은 또한 성능을 평가하고 결과는 게임이 광고하는 최소 시스템 요구사항에 사용됩니다.호환성 또는 성능 문제는 개발자가 해결하거나 기존 하드웨어 및 소프트웨어의 경우 지원이 중단될 수 있습니다.
  • 현지화 테스트는 게임 내 텍스트 [2]편집기 역할을 합니다.일반적인 텍스트 문제는 기능 테스트의 한 부분이지만 QA 부서에서는 전용 현지화 테스터를 고용할 수 있습니다.특히, 초기 일본 게임 번역에는 오류가 많았고, 최근에는 현지화 테스터를 고용하여 기술적 수정을 하고 게임 내 텍스트의 카탈로그 모음인 게임[23] 스크립트의 번역 작업을 검토하고 있습니다.게임의 현지화의 [9]정확성과 품질을 보장하기 위해 게임이 판매되는 지역에 고유한 테스터가 사용될 수 있습니다.
  • 비디오 게임의 맥락에서 소크 테스트는 공회전, 일시 중지 또는 타이틀 화면과 같은 다양한 작동 모드에서 장시간 게임을 실행하는 것을 포함합니다.이 테스트는 초기 설정 외에는 사용자 상호 작용이 필요하지 않으며, 일반적으로 리드 테스터가 관리합니다.마우스 클릭과 같은 반복적인 동작을 시뮬레이션하기 위해 자동화된 도구를 사용할 수 있습니다.시간이 지남에 따라 나타나는 메모리 누수 또는 반올림 오류를 감지할 수 있습니다.소크 테스트는 준수 요구 사항 [citation needed]중 하나입니다.
  • 베타 테스트는 베타 개발 단계에서 이루어집니다.종종 이것은 게임의 최초 공개 버전을 가리킵니다.공개 베타는 수천 명의 팬들이 개발자의 테스터들이 발견하지 못한 버그를 발견할 수 있기 때문에 효과적입니다.
  • 프로그래머가 버그를 수정한 후 회귀 테스트를 수행합니다.QA는 버그가 여전히 있는지(회귀) 확인한 다음 유사한 테스트를 실행하여 수정이 다른 문제를 일으켰는지 확인합니다.두 번째 단계는 종종 "헤일로 테스트"[citation needed]라고 불리는데, 그것은 버그 주변의 모든 것을 테스트하고, 다른 버그를 찾는 것을 포함합니다.
  • 로드 테스트는 MMO 서버의 플레이어 수, 화면에서 활성화된 스프라이트 수 또는 특정 프로그램에서 실행 중인 스레드 수와 같은 시스템의 한계를 테스트합니다.부하 테스트를 위해서는 많은 테스터 그룹이 필요하거나 [2]작업량이 많은 소프트웨어가 필요합니다.로드 테스트는 로드 중에 애플리케이션이 올바르게 작동하는 능력도 측정합니다.
  • 멀티플레이어 테스트는 게임에 상당한 멀티플레이어 비중이 있는 경우 별도의 멀티플레이어 QA 팀이 참여할 수 있습니다.이 테스트는 PC 게임에서 더 일반적입니다.테스트기는 모든 연결 방법(모뎀, LAN, 인터넷)이 작동하는지 확인합니다.이를 통해 싱글 플레이어와 멀티 플레이어 테스트를 [9]병행할 수 있습니다.
  • 플레이어 경험 모델링은 플레이어 경험을 수학적으로 모델링하고 플레이어가 비디오 게임을 선호하거나 좋아하는 것을 예측하려는 시도를 말합니다.

콘솔 하드웨어

콘솔의 경우, 대부분의 테스트는 일반 시스템이나 소비 장치에서 수행되지 않습니다.개발자 및 게시자에게 특별한 테스트 장비를 제공합니다.가장 중요한 도구는 테스트 또는 디버그 키트와 개발 키트입니다.소비자 장치와의 주된 차이점은 굽은 디스크, USB 스틱 또는 하드 드라이브에서 게임을 로드할 수 있다는 점입니다.콘솔은 모든 게시 영역에 설정할 수도 있습니다.이를 통해 게임 개발자들은 테스트용 복사본을 제작할 수 있습니다.이 기능은 소프트웨어 불법 복제 및 회색 시장 [citation needed]수입을 방지하기 위해 소비자 장치에 존재하지 않습니다.

  • 테스트 키트는 소비 장치와 동일한 하드웨어 사양과 전체적인 외관을 가지고 있지만 종종 다른 테스트 장비를 위한 추가 포트와 커넥터가 있습니다.테스트 키트에는 특히 데이터 저장과 관련하여 자동화된 컴플라이언스 검사 실행과 같은 추가 옵션이 포함되어 있습니다.또한 시스템 소프트웨어를 사용하면 [citation needed]디버깅을 돕기 위해 메모리 덤프를 캡처할 수 있습니다.
  • 개발 키트는 일반적으로 게임 테스터가 사용하지 않지만 하위 레벨 테스트를 위해 프로그래머가 사용합니다.테스트 키트의 기능 외에도 개발 키트는 일반적으로 하드웨어 사양이 더 높습니다. 특히 시스템 메모리가 더 높아졌습니다.이를 통해 개발자들은 최적화에 대한 걱정 없이 초기 게임 성능을 추정할 수 있습니다.개발 키트는 일반적으로 더 크고 테스트 키트나 컨슈머 유닛과는 다르게 보입니다.[citation needed]

참고 항목

메모들

  1. ^ Bates 2004, pp. 176-180
  2. ^ a b c d 무어, Novak 2010, p. 95
  3. ^ a b Oxland 2004, 페이지 301-302
  4. ^ Bates 2004, pp. 178, 180
  5. ^ a b c 옥슬랜드 2004, 페이지 301
  6. ^ IGN의 "게임 테스터의 힘겨운 삶"
  7. ^ a b c d Bethke 2003, p. 52
  8. ^ Bates 2004, 페이지 176
  9. ^ a b c d e f Bethke 2003, 페이지 53
  10. ^ a b c d Bates 2004, 페이지 177
  11. ^ a b c d e f g Bates 2004, 페이지 178
  12. ^ a b c d Bates 2004, 페이지 179
  13. ^ Brendan Sinclair (2019-06-26). "Stories of crunch, neglect for QA at Treyarch". gameindustry.biz. Retrieved 2022-06-09.
  14. ^ a b Bates 2004, pp. 178-179
  15. ^ 무어, Novak 2010, p. 72
  16. ^ Bob Johnstone. "Didi Games". Research on Video Games. Didi Games. Archived from the original on 2014-10-06. Retrieved 2009-04-01.
  17. ^ 베이츠 2004, 페이지 180
  18. ^ 무어, Novak 2010, p. 25
  19. ^ 무어, Novak 2010, p. 2
  20. ^ Bates 2004, 페이지 261
  21. ^ Moore, Novak 2010, 페이지 84, 237-238
  22. ^ Fleming, Jeffrey (April 2008). "7th Annual Salary Survey". Game Developer. United Business Media. 15 (4): 8.
  23. ^ Adams, Rollings 2003, p. 17
  24. ^ Yannakakis, Geogios N (2012). "Game AI revisited". Proceedings of the 9th conference on Computing Frontiers (PDF). pp. 285–292. doi:10.1145/2212908.2212954. ISBN 9781450312158. S2CID 4335529. Archived (PDF) from the original on 8 August 2014.

참고문헌

  • Adams, Ernest; Rollings, Andrew (2003). Andrew Rollings and Ernest Adams on game design. New Riders Publishing. ISBN 1-59273-001-9.
  • Bates, Bob (2004). Game Design (2nd ed.). Thomson Course Technology. ISBN 1-59200-493-8.
  • Moore, Michael E.; Novak, Jeannie (2010). Game Industry Career Guide. Delmar: Cengage Learning. ISBN 978-1-4283-7647-2.
  • Oxland, Kevin (2004). Gameplay and design. Addison Wesley. ISBN 0-321-20467-0.

조사.

  • Lahti, M., 핀란드 게임 회사의 게임 테스트, 석사논문, Aalto University, 과학대학, 2014, 논문

외부 링크