ISTQB CT-GaMe 실러버스를 다시 공부하며 (1. 게임 테스팅 개요)

본 ISTQB CT-GaMe 실러버스를 공부하며게시글은 이미 ISTQB CT-GaMe 자격증을 취득하였음에도 이 후 지속적으로 취업을 준비하는 중,

게임 테스트에 대한 이론 지식 습득 및 보완 및 취업 후 원활한 테스트 작업 수행을 위해 CT-GaMe 실러버스 v1.0.1을 바탕으로 학습한 내용을 정리하고 있습니다.

 

본 내용의 실러버스는 아래 첨부한 KSTQB의 학습 자료실 링크를 통해 다운 받아 학습하실 수 있습니다.

https://www.kstqb.org/board_skin/board_view.asp?idx=1874&page=1&bbs_code=4&key=0&word=&etc=

KSTQB

 

 

 

게임 테스팅의 특징

 

소프트웨어 테스팅에서 다양한 전문 분야를 구별하는 것이 일반적이며,

애플리케이션의 성능 테스팅 또는 모바일 애플리케이션 테스팅에 중점을 두어 보안 시스템의 취약점을 찾거나 컴퓨터 게임에서 결함을 찾기도 한다.

 

게임은 다양한 장르와 싱글/멀티 플레이어 모드가 제공되지만, 게임 테스팅은 이러한 특성과는 무관하다고 볼 수 있다.

 

 

게임 제품 리스크

 

비디오 게임 산업이 성장하며 다양한 플랫폼(PC, 모바일, 콘솔 등)에 배포되기 시작했다.

이는 게임이 점차 커지고 복잡 해지며 기술적인 요구사항도 높아지는 것을 의미한다.

이와 동시에 게임 사용자도 늘어나고 품질에 대한 요구도 크게 증가하면서 게임이 더욱 정교하고 까다로워지고 있다.

 

일반적인 소프트웨어의 프로젝트 및 제품 리스크는 비디오 게임과 게임 개발에도 적용되며,

게임 역시 다른 소프트웨어와 마찬가지로 테스트가 필요하다.

그러나 소프트웨어 중 게임에서만 발생하는 리스크도 있으며 더 많은 주의를 요한다.

 

게임 제품 리스크의 일부 예시

• 부정행위로 인한 부당한 이득 획득
• 플레이어의 주관적인 의견에 따라 시장의 성공이 좌우되는 것
• 멀티 플랫폼 호환 문제
• 게임 메커니즘의 효과를 예측하는 것의 복잡성

(이러한 리스크 중 두번째 항목의 사례로 출시 한 제품의 결함 혹은 서비스 중인 제품 운영의 문제점을 통해 유저들에게 부정적인 이미지가 각인이 될 경우 게임 IP에 대해 매출 감소와 같은 악영향이 미치는 것을 보며 쉽게 이해할 수 있었습니다)

 

테스터는 다음과 같은 영역에서 결함을 찾을 수 있다.

• 개발 초기 게임 소프트웨어 아키텍처에서
• 사운드 디자인에서
• 이미 출시 준비가 된 비디오게임의 테스트에서

 

 

게임 테스팅과 관련된 결함

 

비디오게임에서 자주 발생하는 결함에는 다음과 같은 것이 존재한다.

• 그래픽과 애니메이션 문제
• 비디오게임 세계의 물리 법칙 위반
• 비디오게임 인공지능 결함
• 비디오게임 플롯(plot) 구성의 부정확성
• 일부 인터페이스 요소의 잘못된 동작

이러한 결함은 상대적으로 쉽게 발견할 수 있지만 결함을 재현하는 정확한 순서를 식별하는 것이 어려울 수 있으며,

이러한 복잡성으로 인해 게임 테스트팅은 어렵다.

 

우수한 테스터는 아래의 순서대로 테스트를 진행해야 한다.

1. 의도된 게임 시나리오를 기반으로 테스트를 설계
2. 명세를 충족하는지 확인
3. 설계된 시나리오와의 차이(deviations) 분석
4. 그러한 차이로 나타나는 결과 보고

네거티브 테스팅 (Negative testing)

게임 테스팅은 다른 소프트웨어와 마찬가지로 명백한 결함 뿐만 아니라

예외적인 행동의 결과로 나타나는 암묵적인 결함까지 찾는 것이 중요하다.

 

게임에 사용되는 오브젝트 간의 상호작용이 잘못 설정된 경우

전반적인 사용자 경험을 해치거나 의도하지 않은 이점을 제공하는 결함이 발생할 수 있는데

이러한 결함은 멀티플레이어 게임에서 유저간 불공평한 요소가 될 수 있기에 특히 중요하다.

 

이와 같은 리스크 때문에 게임 프로젝트에서 네거티브 테스팅을 수행하는 것은 중요하다.

 

노력 없이 쉽게 승리하기 위해서 제3의 소프트웨어나 특수한 명령어를 요구하지 않은채

개발자가 의도한 대로 플레이를 하지 않고 "적절한" 결함을 찾아

시스템을 "브레이크(break)"하거나 우회하려고 시도하는 플레이어가 있을  수 있기 때문이다.

 

이러한 플레이어는 의도적으로 게임 논리에서 결함을 찾아 개인적인 이익을 위해 결함을 이용하는데,

수익을 창출해야 하는 게임일 경우, 이러한 점은 게임 개발사의 수익 감소로 이어질 수 있기 때문이다.

 

플레이어 의견에 대한 의존성(dependence)

게임 소프트웨어는 다른 소프트웨어에 비해 최종 플레이어의 주관적이고 감정적인 판단에 횔씬 더 영향을 받는다.

 

게임 소프트웨어의 경우, 사용자의 관심과 게임의 첫인상이 가장 중요한데,

그 이유는 충성적인 플레이어는 일부 기능 결함을 눈감아 넘길 수 있지만

새로 유입하는 플레이어의 경우 게임이 지루하거나 오래된 그래픽을 사용할 경우 게임 플레이를 꺼릴 수 있기 때문이다.

또한 많은 비디오게임 플레이어는 게임 평론가, 리뷰어, 기타 오피니언 리더(opinion leader)의 피드백을 기반으로 제품을 구매 또는 플레이하게 된다.

 

(개인적으로도 새로 출시되는 게임을 구매하기에 앞서 스팀의 평가 시스템이나 게임 커뮤니티의 의견을 통해 제품 구매를 결정하는 영향이 있었기에 쉽게 이해할 수 있었습니다)

 

멀티플랫폼

게임 소프트웨어의 중요한 특징은 여러 플랫폼에서 많은 사용자가 흔히 사용한다는 점이다.

게임 스튜디오 및 퍼블리셔는 가능한 한 많은 사용자를 확보하기 위해 다양한 개인용 컴퓨터(PC), 웹, 모바일 기기, 콘솔 등을 포함한 여러 플랫폼에서 게임을 배포한다.

모든 업데이트는 가용한 모든 플랫폼에서 테스트되어야 하며

이는 심각한 리스크가 되어 필요한 테스트 시간도 크게 늘어나게 한다.

 

게임이 컴퓨터에서는 잘 실행 되지만 최신 콘솔에서는 다양한 결함이 발생할 수 있다.

기술 간 비효율적인 커뮤니케이션이나 원래 의도한 플랫폼이 아닌 제3의 조직에서 개발한 다른 플랫폼으로 이식하기 위한 요구사항의 불완전성 등으로 결함이 발생할 수도 있다.

이러한 리스크를 완화하기 위해서는 게임 소프트웨어 개발과 테스팅, 다양한 하드웨어 구성에서의 게임 기능과 성능 테스팅, 또 각 프랫폼 고유 특성을 고려한 테스팅 수행 등에 더 많은 시간을 할애할 필요가 있다.

 

비디오게임을 게임 콘솔 상에서 테스트 하는 것도 고려해야 하는 특별한 점인데

게임 콘솔은 게임만을 위해 설계된 기기로 모바일 기기나 컴퓨터와 달리 다른 소프트웨어는 아무것도 가지고 있지 않기 때문이다.

비디오게임을 테스트하기 위해 블랙박스 테스트 기법을 사용하면 플랫폼 간 차이는 거의 없다.

그러나 게임 콘솔 제조 업체가 비디오게임 출시 전 준수해야 할 고유한 요구사항을 가지고 있을 수 있다.

이러한 요구사항은 기밀 유지 계약에 따라 개발자와 퍼블리셔에게 제공되는 기밀문서이다.

각 요구사항 체크리스트는 여러 범주로 구성되며, 콘솔 제조 업체에서 거부당하지 않으려면 게임은 그것을 준수해야한다.

 

따라서 콘솔용 비디오게임을 테스트하는 사람은 기본적인 스프트웨어 테스팅 방법 외에도 이러한 요구사항을 준수하는지 테스트해야한다.

 

결함을 식별하고 분석해서 그 원인을 파악하기 위해 특수한 콘솔을 사용해야 할 수도 있다.

이 콘솔은 일반 콘솔과 유사하지만, 게임 개발과 테스팅에 도움이 되는 추가 모드를 제공하는데

승인 개발자와 테스터가 이 콘솔을 사이트에 등록하고 활성화하면 추가 모드를 사용할 수 있다.

 

 

테스팅이 비디오게임의 제품 리스크를 완화하는 방법

 

비디오게임, 특히 오픈월드 게임은 너무 복잡하기에 게임 오브젝트, 이벤트, 요소 등의 모든 조합을 테스트하는 것은 불가능하다.

전체 소프트웨어 개발 수명 주기 동안 각 조합을 한 번씩만 테스트하는 것도 많은 시간과 노력이 필요하며,

게임이 업데이트되면 수정 사항에 대한 확인 테스트를 수행하는 것도 추가적인 노력이 필요하다.

 

자원을 효율적으로 할당하고 발생 가능성 및 게임에 미치는 영향을 기반으로 결함을 평가하는 데 리스크 관리가 사용된다.

 

각 테스트 케이스에 대해 테스트 우선순위를 결정하기 위해 두 가지 질문이 필요하다.

• 플레이어가 여기에서 결함을 찾을 가능성은 얼마나 될까?
• 결함을 식별하면 플레이어와 게임 개발사에 어떤 영향을 미칠까?

테스팅을 통해 리스크를 완화하려면 게임에서 개별 결함을 찾는 것보다 결함 그룹을 식별하는 것이 중요하다.

이를 통해 개발자는 게임 코드 또는 아키텍처 문제를 동시에 해결하고, 최종 제품의 품질을 향상시킬 수 있다.

결함 그룹은 중요 영역에 있는 결함의 집합이다.

게임 제품에는 그래픽, 사운드, 현지화, 클라이언트-서버 상호작용, 하드웨어 등 결함 발생 가능성이 큰 영역이 있다.

 

플레이어가 게임을 배우거나 튜토리얼을 수행할 때 게임에 대한 충성도를 얻는 것이 중요한데,

이 단계에서 플레이어는 제품을 평가할 수 있는 수많은 게임 기능을 접하기 때문이다.

그렇기 때문에 이 초기 단계는 일반적으로 매우 중요한 것으로 인식된다.

 

 

테스팅과 "플레이"의 차이

 

컴퓨터 게임 테스터라는 직업의 본질이 하루 종일 동료들과 온라인 상에서 게임을 하는 것이라는 인상을 받을 수 있지만

사실은 그렇지 않다.

 

테스터는 새로운 프로젝트를 알아 갈 때 또는 플레이 테스트를 수행할 때를 제외하고는 그냥 플레이하는 경우가 거의 없으며,

되려 하는 일의 대부분은 다양한 유형의 테스팅을 수행하는 것과 관련이 있다.

이는 여러 측면에서 다른 소프트웨어의 테스트와 동일하다.

 

일반 사용자는 게임을 완료하거나 상대를 이기거나 즐거운 시간을 보내기 위해 게임을 시작하는 반면

테스터는 게임이 명세에 명시된 요구사항을 충족하는지 확인한다.

또한 테스터의 개인 성향이 게임의 의도된 대상 고객과 일치하지 않을 수 있는데

그럼에도 불구하고 테스터는 게임 오브젝트가 올바르게 표시되는지 등을 테스트하기 위해 같은 레벨을 반복해서 진행해야 한다.

 

테스터가 이러한 반복적인 작업을 수행할 때 경험하는 단조로움은

개발자가 생각한 게임플레이를 가로막는 결함을 발견했을 때 얻는 만족감으로 보상될 수 있다.

 

(실제로 단기 계약 테스터로 근무를 진행한 경험이 있는데 그 당시에도 업무 시간 동안 즐거움을 추구하는 게임 플레이를 하기 보다

주어지는 명세를 확인하고 테스트 문서 작업을 진행하는 것이 대부분이었습니다 또한 업무 중 게임 플레이를 진행하더라도 즐거움을 추구하기 보다 결함을 찾기 위해 특정 행동을 반복하는 작업이 대부분이었고 결함을 발견하고 개발팀에 보고 후 해당 결함이 수정 되었을 때의 만족감은 대단했었습니다 이러한 경험을 비추어보며 해당 항목을 쉽게 이해할 수 있었습니다)

 

 

게임 개발팀 내 일반적인 역할

 

대부분의 컴퓨터 게임 개발팀의 역할도 다른 소프트웨어 개발에서의 역할과 크게 다르지 않지만,

비즈니스 책임자, 프로젝트 관리자, 분석가, 개발자, 게임 디자이너, 테스터 등과 같은 차이점이 존재한다.

소규모 팀의 경우 한 사람이 동시에 여러 역할을 맡을 수도 있다.

 

게임 소프트웨어 프로젝트 내 일반적인 역할과 수행 활동 요약

역할	책임
비즈니스 책임자	사업 개발 마케팅 정책 정의 신제품 착수 팀 빌딩 참여 가능
프로젝트 관리자	수행할 작업 설정하고 모니터링 소프트웨어 개발 수명 주기 단계 추적
분석가	제품 요구사항 식별 초기 명세 작성 명세 업데이트 및 최신화
개발자	코드 개발 및 디버깅 결함 수정 단위 테스트 개발
게임 디자이너	게임 메커니즘, 밸런스, 플롯, 레벨, 게임 경제 설계 게임 문서 작성 게임 콘텐츠 기획 및 개발
테스터	테스트 모델 및 테스팅 전략 개발 테스트 데이터 설계 및 준비 명세 리뷰 다양한 유형의 테스티이 수행 결함 식별 및 분석

 

 

게임 소프트웨어 개발 수명 주기 전반에 걸친 테스팅 활동

 

컨셉 단계

이 단계의 주요 목표는 개발팀과 고객이 미래 제품에 대한 공통된 비전에 합의하는 것이며,

게임의 전반적인 비전, 장르, 설정, 게임플레이의 본질, 메커니즘과 주요 기능을 간략하게 설명하는 문서 형태로 아이디어를 작성한다.

 

컨셉 단계에서 리뷰할 수 있는 산출물

• 비전 문서
• 컨셉 문서
• 제품 및 기술 제약

컨셉 단계에서 생성되는 테스트웨어

• 테스트 전략
• 테스트 계획 초안
• 상위 수준의 테스트 노력 추정치
• 테스트 환경

사전 제작 단계

이 단계의 주요 목표는 초기 동작 버전인 게임 프로토타입을 만드는 것이며,

프로토타입은 초기 품질 수준으로 구현한다.

 

이 단계에서 핵심 게임 메커니즘과 초기 가설을 테스트하고 팀의 기술적 능력을 평가한다.

테스터, 게임 디자이너, 개발팀의 기타 구성원이 프로토타입 테스팅에 참여할 수 있다.

 

요구사항 초안을 리뷰하여 개발팀은 구현 가능성을 검토하고,

테스트팀은 메커니즘 간의 상호작용과 구현된 프로토타입의 기능을 식별하게 된다.

또한 테스터는 테스트 계획 및 테스트 일정 문서 작성에 기여한다.

 

게임에 대한 문서가 작성되면 테스트 계획을 작성 및 업데이트하고 문서를 리뷰한다.

이러한 활동은 사전 제작 단계에서 제품의 기술적 리스크를 완화한다.

 

사전 제작 단계에서 리뷰할 수 있는 산출물

• 요구사항 명세
• 게임 프로토타입
• 이전 단계에서 작성한 테스트 산출물

사전 제작 단계에서 생성 및 업데이트되는 테스트웨어

• 테스트 전략
• 테스트 계획
• 테스트 일정
• 테스트 환경

개발 단계

이 단계는 게임이 개발되는 가장 긴 단계로서 일반적으로 게임의 알파 및 베타 버전으로 나눠지게 된다.

 

이 단계에서 테스터는 체크리스트와 테스트 컨디션 세트를 마무리하고

구현된 제품 구성 요소의 기능 및 비기능 테스팅과 단위 통합, 시스템, 인수 테스팅 등의 수행된다.

 

이 단계에서 가장 많은 수의 결함이 식별되기 때문에 테스터는 확인 및 리그레이션 테스팅을 수행하게 된다.

 

개발 단계에서 생성 및 업데이트되는 테스트웨어

• 테스트 계획
• 테스트 일정
• 테스트 케이스, 테스트 컨디션, 체크리스트, 테스트 스위트, 스크립트
• 결함 보고서
• 테스트 보고서

후반 작업 단계

게임 테스팅의 후반 작업 단계에는 일반적인 소프트웨어의 유지 보수 기간 동안 수행되는 테스트 활동과

업데이트 및 리그레이션 테스팅이 포함된다.