• Announcements

    • Zerasion

      GDF 기본 공지 사항   2017년 11월 23일

      이전 (phpbb & Ruby를 쓰던) GDF에 올라왔던 공지사항들을 새 형식에 맞게 수정했습니다.   인벤과 GDF에 대하여 일단, 도메인 주소에서 보실 수 있듯, 이 포럼은 인벤 (inven.co.kr) 에서 제공하는 서버를 통해 돌아갑니다.
      그러나 회원 DB나 운영은 완전히 별개로 독립되어 있습니다. 
      즉 인벤 아이디로 GDF에 로긴하거나, GDF 아이디로 인벤에 로긴하는 등의 일은 불가능합니다. 
      아울러 운영진 또한 인벤직원이 아닙니다. 
      이는 즉 인벤과는 전혀 다른 운영정책을 취하고 있다는 의미입니다. 
      행여나 이 포럼에서 생긴 일에 대한 문의나 요청이 인벤측으로 가거나, 
      반대로 인벤에 대한 문의 또는 요청을 이쪽에 주셔도 저희로서는 어떻게 해드릴 수가 없습니다.
      혹시나 도메인 주소 때문에 오해하시는 분들이 있을까봐 부연합니다.   GDF의 취지 게임 개발자의 역할을 나누는 데는 여러 방법이 있지만, 최근 한국의 게임업계에서는 디자이너, 프로그래머, 아티스트 중심의 구분이 어느 정도 보편적으로 자리 잡았습니다. 하지만 실력 있는 프로그래머, 실력 있는 아티스트에 대한 평가 기준과 거기까지 도달하는 방법론이 비교적 뚜렷한 것과는 달리, 어떤 게임 디자이너가 유능한 디자이너이며 그렇게 되려면 어떤 노력을 해야 하는지에 대해서는 아직까지 수많은 이견이 있을 뿐입니다. 물론 팀의 성향과 개발 여건에 따라 게임 디자이너에게 요구되는 소양은 타 직군에 비해 다양할 수 있습니다. 재미있는 아이디어를 뽑아내는 창의력, 다른 파트와 유연하게 소통하는 커뮤니케이션 능력, 누구나 이해하기 쉬운 문서를 만들어 내는 능력 등은 때로 가장 중요하게 손꼽히기까지 합니다. 그러나 게임 디자이너가 자신의 전문 분야로 삼아야 할 것은 무엇보다 '게임 디자인 능력' 이라 할 수 있겠습니다. 재미있는 게임을 디자인 해내는 능력이야말로 기본이자 필수입니다. 그러나 정작 '어떻게 해야 게임 디자인을 잘 할 수 있는지' 공부하는 길은 그리 만만하지 않습니다. 애초에 '어떤 것이 잘한 게임 디자인인지' 판단하는 것부터도 어렵습니다. 물론 찾아보려 마음 먹는다면 생각보다 많은 정보 더미를 얻을 수야 있겠습니다만, 그것은 말 그대로 건초에서 바늘 찾기입니다. 인터넷만 뒤져본다고 얻을 수 있는 것도 아닙니다. 그 정보들은 누군가의 하드디스크에, 어딘가의 클라우드 서버에, 때로는 오직 인쇄된 문서로만 존재하니까요. 그리고 아마, 가장 중요한 정보들은 수많은 게임 디자이너들이 '내가 이 삽질을 다시 하나 봐라!' 하고 결심하는 그 순간의 뇌리에만 존재할 겁니다. 빠르게 변하는 현대 사회 중에도 최고의 속도를 자랑하는 이 업계에서는, 분명 많은 유저에게 재미를 주던 검증된 게임 매커니즘도 불과 몇 년 사이에 닳고 닳아 진부한 것이 되기 일쑤입니다. 또한 잘 만들어진 게임일수록 그 안의 모든 시스템이 유기적인 관계를 맺고 있어, 몇 개의 디자인 장치를 떼어내 다른 게임에 갖다 붙인다 해서 성공적인 결과가 나오지 않습니다. 결국 이 모든 일은 게임 디자이너들에게 끊임없이 공부할 것을 요구합니다. 무얼 공부해야 할지, 어떻게 공부해야 할지는 사실 막막한 상황에서 말입니다. Game Design Forum은 그런 상황에 대한 하나의 방법론으로 만들어졌습니다. 이 곳에서 게임 디자인에 대해 공부하고 싶은 내용을 함께 나눌 수 있으면 좋겠다고 생각합니다. 눈에 잘 띄지 않는 멋진 게임 디자인 자료들을 찾아내어 공유하고 싶습니다. 자기만의 디자인 노하우나 경험담이 있다면 서로 나누고 싶습니다. 딱히 정답을 찾아내진 못하더라도, 서로 대화를 나누고 토론하는 과정에서 배우는 뭔가가 있을 것입니다. 그런 일을 하기 위해 마련한 자리입니다. 그래서 이 곳은 무엇보다 "게임 디자인"에 대해 토론하고 대화하는 공간이 되었으면 합니다. 이와 비슷한 취지로 만들어졌던 많은 커뮤니티들이 결국 게임 디자인에 대한 이야기에서 게임 개발 전반, 산업 전반에 관한 이야기로 옮겨가는 것을 보았습니다. 물론 게임 디자인 역시 게임 개발의 일부인 이상 그런 화제들을 아예 배제할 수는 없을 겁니다. 그러나 일단 이 곳에서 활동하시는 여러분께서 "GDF는 게임 디자인에 관해 이야기 나누는 곳" 이라는 사실을 분명하게 인지해 주신다면 이 곳의 정체성이 흔들리는 일은 없지 않을까 합니다. 언제나 그 점 기억해 주시면 감사하겠습니다. 지켜주세요 – GDF 사용 규칙 이 포럼을 사용하기 위해 숙지하고, 지켜주셔야 할 규칙들입니다. 
      다소 딱딱하게 느껴질 수도 있지만, 가능한한 최소화하려 노력했는데도 이정도네요. 
      이 규칙들을 의도적으로 또는 과하게 어겼다고 판단되면 적절한 조치를 취할 수도 있습니다. 
      잘 지켜주시면 감사하겠습니다. 1. 게시판의 용도를 지켜주세요.
      각 카테고리에 대한 간략한 설명입니다. Purple Board
      Green/Blue 에서 관리자가 추천하는 게시물이 옮겨진 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, Purple Panel(관리자)만 글을 작성할 수 있습니다. 댓글을 작성할 수 없습니다. Blue Board
      관리자에 의해 승급된 Blue Panel들이 게시물을 작성할 수 있는 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, Blue Panel들만 글을 작성할 수 있습니다. Green Board
      회원 가입 후 인증이 완료된 Green Panel들이 게시물을 작성할 수 있는 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, Green Panel들만 글을 작성할 수 있습니다. Free Board
      잡담 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, 모든 Panel 글을 작성할 수 있습니다. To GDF  운영진에게 부탁하고 싶은 내용, 궁금한 점, 건의 사항 등을 여기에 적어주세요. 
      비회원을 포함한 모두가 읽을 수 있으며, 모든 회원이 글을 작성할 수 있습니다.
      게시판의 의도와 관계없는 게시물은 운영진에 의해 적당한 다른 게시판으로 옮겨지거나 삭제될 수 있습니다.   2. 게시판 예절을 지켜주세요.
      게시판 이용자간에 서로 지나치게 적대적인 태도는 피해주세요. 
      존댓말을 기본으로 하며, 서로 아는 사이라 해도 반말의 사용을 자제해 주세요. (잡담 게시판 예외)
      물론 외부의 글을 옮겨오는 등의 경우에 불가피하게 평어체로 작성된 글은 무방합니다.   3. '포럼처럼' 사용해주세요.
      이곳이 다른 게시판이 아니라 굳이 '포럼' 의 형태를 취하는 이유는, 포럼의 기능을 잘 활용하기 위해서입니다. 
      다음과 같은 내용들을 염두에 두시면 됩니다.
      하나의 이슈에 얽힌 이야기는 하나의 글타래로만 다룹니다. 
      새로운 글타래를 매번 새로 만드실 필요가 없습니다. 꼭 댓글 형태로 달아주세요. 
      댓글을 아주아주 길게 달 수도 있으니 부담없이 이용하시기 바랍니다.
      새 글타래를 만들기 전에 검색을 해보시는 것도 좋습니다.
      이 사항이 지켜지지 않을 경우 강제로 게시물이 이동/삭제될 수 있습니다. 유의하세요.
      너무 오래 전에 올라온 글이라 의견을 달아도 아무도 보지 못할 것 같은가요? 
      이 포럼은 가장 최근에 댓글이 달린 게시물을 자동으로 최상단에 올려줍니다.
      아주 오래 전 이슈를 다시 언급하는 경우에도 새 글타래를 만드실 필요가 없어요.
이 글을 팔로우하기  
팔로워 0
Zerasion

[아카이브] 소프트웨어 테스트와 게임 테스트의 차이점

2 posts in this topic

Voosco 님이 작성하셨던 포스팅의 아카이빙입니다.

---

 


Differences between Software Testing and Game Testing

안타깝게도 제가 소프트웨어 테스트에 대해서도 게임 테스트에 대해서도 전문적인 지식은 별로 없는 관계로 일부 용어나 개념이 한국의 현업에서 쓰는 것과는 상이할 수 있으며, 오역의 가능성도 큰 편입니다. 이런 부분들은 지적해주시면 이후에라도 수정하겠습니다.

참고로 아래 글은 특정한 방법론을 소개하는건 아니고 그냥 차이점이 뭐다만 언급하는 걸로 ...

http://www.gamasutra.com/blogs/JohanHoberg/20140721/221444/Differences_between_Software_Testing_and_Game_Testing.php

----------

어플리케이션 또는 소프트웨어 테스팅과 게임 테스팅의 큰 차이점은 무엇인가? 이것이 내가 십년간 핸드폰 소프트웨어 테스트 및 QA분야에서 일하다가 게임쪽에서 일하기 시작하며 스스로에게 던진 질문이었다. 나는 소프트웨어 테스팅에 대한 일반적인 책은 거의 다 읽어왔다. 그러나 게임 테스트에 대한 실질적인 지식은 전혀 없었다. 그래서 기본적인 사항들을 익히고자 게임 테스트에 대한 책을 두 권 샀고, 경험을 위해 직접 몇 주간 일을 해봤다. 

그리고 나 자신의 개발실력을 숙련하기 위해, 지금껏 내가 배운 것들을 정리해보려 한다. 

소프트웨어 테스트는 공학적 원칙이다. 이는 게임 테스트에 대해서도 적용된다. 물론 별다른 구조적인 고려 또는 전문적인 지식 없이도 게임을 플레이하며 버그를 찾아낼 수 있다. 이는 핸드폰에 대해서도 그렇다. 그러나 그 이상 나아가고 싶다면 프로 테스터가 되어야만 한다. 

프로 게임 테스터가 된다는 것은 일반적인 의미에서의 테스트만이 아니라 게임 테스트만의 고유한 원칙에 대해서도 이해해야 함을 의미한다. 이는 결코 작은 일이 아닌데, 소프트웨어 테스트는 매우 복잡하고 입체적인 일이고, 게임 테스트는 매우 특별한 요령을 요구하기 때문이다. 

차이를 알아보기 전에 우선 게임 테스트와 소프트웨어 테스트간의 공통점에 대한 합의가 필요하다. 켐 카너(Cem Kaner)가 그의 교육 커리큘럼 블랙박스 소프트웨어 테스팅(Black Box Software Testing)[1]에 쓴 내용들은 기본적으로 양 분야에 모두 적용될 수 있다는 것이 내 생각이다. 앨런 페이지(Alan Page)가 테스트 자동화[2]에 대해 쓴 거의 대부분의 것들도 게임 테스트에 적용될 수 있다. ISTQB 테스팅 자격(ISTQB testing certification)[3]에 포함된 대다수의 것들 또한 유효하다. 게임 테스트는 소프트웨어 테스팅이 가진 거의 모든 일반적인 요소들을 내재하고 있다. 심지어 제임스 바흐(James Bach)의 사고방식과 그의 래피드 소프트웨어 테스팅(rapid software testing)[4] 또한 기본적으로는 약간의 짜깁기를 거쳐 게임 테스팅에 적용될 수 있다. 마이크로소프트와 구글이 소프트웨어를 테스트하는 방법 또한 테스팅을 바람직한 방법으로 구조화하고 조직화하는 법에 대해 많은 것을 알려줄 수 있다. [5][6]

7fd1c82c9eb553a9.jpeg

게임 테스팅은 어느모로 보나 다른 테스팅만큼 복잡하며, 같은 방식으로 다루어져야 한다. 훈련받지 못한 비전문가에게 맡겨질 수 있는 일이 아니다. 물론 라이브 유저 테스트, 알파와 베타 테스트 등 일반 유저들을 대상으로 하는 테스트가 있긴 하지만 이는 커다란 전체 퍼즐의 일부분일 뿐이다. 뭔가 문제가 있는지를 알아보기 위해 게임을 플레이하는 정도의 단순한 테스팅은 여러분의 게임이 가진 질적 측면을 심각하게 약화시킬 것이다. 

그렇다면 게임 테스트의 어떤 측면이 고유한 것인가? 어떤 부분들이 게임 테스팅을 일반적인 소프트웨어 테스팅과 구분짓는가? 이를 위해 게임 테스팅이 특히 더 문제시되는 몇 가지 종류의 테스트들을 정리해보았다. [7][8][9]

- 재미 요소 테스트
- 밸런스 테스트
- 게임 레벨/월드 테스트
- AI 테스트
- 멀티플레이어/네트워크 테스트
- 오디오 테스트
- 물리엔진 테스트
- 리얼함 테스트
- API 수정 테스트 

사용성 또는 유저 경험은 모든 소프트웨어에서 테스트하는 부분이다. 그러나 재미 요소 테스트는 게임에만 있는 고유의 것이며, 이는 게임이 엔터테인먼트 제품이기에 그러하다. 게임은 제대로 동작하고 좋은 유저 경험을 제공하는지만을 따지지 않는다. 게임은 여기에 더해 플레이가 재밌어야 한다. 그렇다면 여러분은 뭔가가 재밌는지 아닌지 어떻게 가늠할 것인가? 어떤 경험이 타겟 그룹에게 제대로 어필하는지를 어떻게 알 수 있는가? 이는 게임 디자인, 유저 그룹에 대한 폭넓은 경험과 데이터 및 그 그룹이 무엇을 좋아하는지에 대한 독특한 통찰을 필요로 한다. 

서로 다른 맵, 몬스터나 이벤트 등 서로 다른 선택지들 사이의 밸런스를 잡는 것 또한 게임에만 있는 고유한 것이다. 밸런스 테스트는 게임 디자인 및 각기 다른 단계에서 타겟 유저들이 어떻게 반응할지에 대한 폭넓은 지식을 필요로 한다. 밸런스를 잡는 것은 또한 수십시간동안의 게임 테스트가 요구되는 부분이다. 

게임 테스트의 가장 복잡한 부분은 실제 월드 또는 맵을 테스트하는 일이다. 특히 그 월드가 최신 MMO처럼 넓고 멋대로 뻗어나가 있으며 3D라면 더욱 그렇다. 게임 레벨/월드 테스트의 일부는 게임 월드를 무작위로 움직이는 봇을 돌려보며 어디 걸리는 곳은 없는지, 다른 문제는 없는지 확인하는 등 흥미로운 방식으로 자동화할 수 있는데, 이 또한 게임 테스트의 독특한 점이다. 업무의 복잡도가 증가함에 따라, 여러 도구들을 사용하여 이러한 복잡도를 감소시키려는 노력이 점점 더 중요해지고 있다. 퍼즐 게임의 경우 모든 스테이지에서 그래픽이 멋져 보이는게 중요하지만, 각 스테이지가 클리어 가능한지, 독립적 환경에서 테스트한 게임 매커니즘이 여러가지 다른 스테이지에 적용되어도 제대로 기능하는지를 확인하는 것 또한 중요하다. 

컴퓨터가 제어하는 적이 제대로 동작하는지, 인공지능이 디자인한 대로 잘 동작하는지 확인하는 것 또한 NPC의 행동이 정교해지면서 매우 어려운 일이 되고 있다. 체스는 기본적이지만 꽤 좋은 예시이며, 최신 FPS 게임에서의 적들은 좀더 현대적인 예가 될 것이다. 이런류의 테스트들은 테스터로 하여금 어떤 조건이 NPC의 어떤 행동을 촉발하는지 이해할 것을 요구하며, 서로 다른 여러가지 환경 하에서 이런 조건들이 어떻게 잘못 동작할 수 있는지 또한 알고 있어야 한다. AI와 게임 디자인에 대한 이해는 이 분야에서의 성공에 필수적인 부분이다. 

멀티플레이어 테스트는 그 자체로 대단한 강적이다. 많은 플레이어들이 게임월드나 컴퓨터가 제어하는 적들, 게임 서버, 다른 플레이어들과 동시에 상호작용한다. 따라서 많은 일들이 잘못될 수 있다. 그리고 멀티플레이어 게임을 테스트하는 일은 종종 테스트팀 전체를 필요로 한다. 여러가지 다른 시나리오하에서 끝나지 않는 테스트를 하고 싶지 않다면, 여러가지 리스크에 기반한 결정들을 내려야 한다. 멀티플레이 게임의 게임 디자인에 대한 이해, 그리고 팀 단위로 테스트하는 경우 어떻게 하면 효율적으로 할 수 있는지 등에 대한 지식이 요구된다. 

매체를 재생하거나 어떤 종류이든 소리를 들려주는 소프트웨어에 있어서 오디오 테스트는 보편적인 것이다. 그러나 게임은 같은 규모의 다른 소프트웨어에는 없는 독특한 측면을 갖는다. 게임 음악은 유저를 게임에 몰입시켜야하며 게임플레이를 강화시켜줘야 한다. 오디오가 끊기거나 빠진 부분이 없는지만을 확인하는게 아니라, 게임플레이와 융화되는지도 확인해야 한다. 오디오 테스트에는 광범한 오디오 스킬 및 게임 오디오라는 매우 특정한 전문영역의 고유한 부분들에 대한 이해가 필요하다. 

많은 최신 3D게임들이 물리엔진을 가지고 있다. 배틀필드나 크라이시스 등의 최신 FPS 및 스카이림과 같은 RPG들에서는 물건을 던지거나 파괴할 수 있다. 물리엔진을 테스트하기 위해서는 물리엔진 자체에 대해서는 물론 이를 바람직하게 적용하는 방법에 대해서도 이해할 필요가 있다. 물리엔진의 복잡도가 증가함에 따라 테스트의 복잡도 또한 증가하고 있다. 

특히 시뮬레이터나 레이싱 게임에서 게임이 리얼하게 느껴지는건 매우 바람직한 일이다. 그러나 많은 다른 게임들 또한 여러 무형 요소들이 리얼하게 느껴져야만 한다. 리얼함을 테스트하기 위해서는 게임과 게임의 구성요소들에 대한 매우 전문적인 영역의 지식이 필요하다. 비행기 시뮬레이터는 비행기에 대한 지식을 요구하며, 자동차, 무기, 인간의 운동과 동물 등도 마찬가지다. 각 요소들마다 살펴봐야 할 부분들이 있다. 

많은 소프트웨어들이 서드파티가 쓸 수 있는 API를 공개하고 있다. 게임에서는 플레이어들이 공개 API를 이용하여 불공정하게 게임상의 이익을 얻으려 시도하는 예들이 존재한다. 이는 우물 바깥의 사고를 요구한다. 모더(modder)들이 어떻게 API를 사용할지, 그들이 어떻게 게임플레이를 크게 바꿔놓을지 고민해야 한다. 모더들의 전체 커뮤니티에 한 발 앞서 생각하는 것은 사실상 매우 벅찬 일이다. 

이런 여러 종류의 다른 테스트에 더해서, 유저들을 분류하는 일도 게임에서는 독자적인 방법으로 행해져야 한다. 우선순위를 어떻게 결정하고 무엇을 테스트 할 것이며 어떤 방법을 취할 것인지가 여기에 관련되어 있다. 이런 분류를 하는 방법은 그 자체로 별도의 글을 써야하겠으나, 게이머들을 종류별로 분류하는 일을 어떻게 해야하는지에 대한 예시를 남기겠다. [7][8]

지금까지 어떤 점들이 게임 테스트의 독특한 부분인지에 대해 다루어보았다. 당연히 뭔가 더 있을거라 믿으며, 내 경험이 쌓여감에 따라 이런 부분들을 발견하게 될 것이다. 

한 가지는 분명하다. 게임 테스트는 매우 복잡하며, 게임이 점점 더 복잡해져감에 따라 테스트 또한 함께 복잡해 질 것이라는 점이다. 풀어나가는 과정에서 선택 가능한 경우의 수가 폭발적으로 증가하는 타입의 문제이며, 매우 영리한 테스트 방법을 통해서만 이들을 다룰 수 있다. 게임을 테스트하는데 드는 노력과 숙련도를 과소평가한다면, 어떤 게임이든 질적 하락을 경험할 수 밖에 없다. 

게임을 테스트하는 테스터들은 많은 종류의 스킬과 방법론, 그리고 프로세스를 마스터해야하며, 자신의 제품에 대해 다른 소프트웨어 테스트의 영역에서는 요구되지 않는 부분까지도 이해해야 한다. 

실로 벅찬 일이다. 

References
[1] BBST

http://www.testingeducation.org/BBST/

[2]The A Word

https://leanpub.com/TheAWord

[3]ISO29119

http://www.softwaretestingstandard.org/

[4]Context-Driven Testing

http://context-driven-testing.com/

[5] How Google Tests Software

http://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027

[6]How We Test Software at Microsoft

http://www.amazon.com/How-We-Test-Software-Microsoft/dp/0735624259/

[7] Game Development Essentials: Game QA & Testing

http://www.amazon.com/Game-Development-Essentials-QA-Testing/dp/1435439473

[8] Game Testing: All on One

http://www.amazon.com/Game-Testing-Second-Charles-Schultz/dp/1936420163/

[9] Artificial Intelligence (Video Games)

http://en.wikipedia.org/wiki/Artificial_intelligence_(video_games)


 

Zerasion님이 수정하였습니다.
0

Share this post


Link to post
Share on other sites

GDF에서는 거의 처음으로 소개된 것 같은 QA 관련 글인 것 같네요.
업계 입문 후 게임 디자이너가 되기 전 수 년간 QA로 종사했기 때문에 상당히 그리운 단어들이 많이 보여 개인적으로는 무척이나 반가운 글인 것 같습니다.
일단 07년산 실라바스를 기준으로 출제된 ISTQB 취득자라 최신 개정판의 정보에는 어두울 수 있지만, 보편적인 기준에서 보면 염려하신 만큼의 단어 오역은 없는 것으로 보입니다. 물론, 다른 현역 테스트 엔지니어 및 QA 분들께서는 좀 더 나은 다른 답변을 주실 수도 있지만요. ㅎㅎ

본문에서 언급되었다시피, Game QA가 전문적으로 연구되기 시작한 것은 S/W QA보다 한참 나중의 일이라고 배웠습니다. 때문에 저 또한 처음 교육을 받던 시절엔, ISTQB를 기반으로 한 개괄적인 S/W Testing 관련 지식을 먼저 배웠고, 당시의 회사에 공통적으로 사용되던 규칙들이나 각 프로젝트별로 사용되던 프로세스 및 도구, 용어 등을 그 위에 얹는 방식으로 학습이 진행 됐습니다.

그래도 요즘에는 S/W QA와 Game QA가 뿌리는 같지만 한 단계 더 나아가면 서로 다른 목적성을 띄고 있다는 데에 직군 종사자 분들이 많은 동의를 하시고, GQA라고 따로 명칭을 나누는 등의 움직임이 있습니다.
그리고 다시 GQA에서도 Functional/Non-Functional QA 또는 T(Technical)QA / F(Fun)QA 등으로 불리는 기능성 테스트와 비기능성 테스트를 구분하고 있고요.

물론 얼마나 많은 조직에서 비기능성 테스트에 비용을 들이고 있는 지는 잘 모르겠습니다.
제가 재직하던 당시의 조직에서도 꾸준히 비기능성 테스트에 시간과 인력을 할애하려고 노력하긴 했지만, 실질적으로 기능성 테스트가 선행된 이후에 비기능성 테스트를 수행할 수 밖에 없고, 전체 개발 프로세스 상 QA 단계는 일정 뒤쪽에 배치되어 릴리즈 일자가 데드라인으로 박혀서 수행할 여력이 없는 경우도 빈번했고요.

그럼에도 불구하고, 비기능성 테스트는 본문 내용처럼 반드시 필요한, 그리고 굳이 S/W QA에서 GQA가 구분되어야만 하는 가장 중요한 핵심 내용이라고 생각합니다.
S/W QA의 기본은 결국 제품이 결함 없이 본래의 목적에 맞게 잘 구현되었는지를 확인하는 것에 있고, 결함이 없는 제품은 일종의 최소 요구 조건이라면, 본래의 목적에 맞는 제품이 최대 요구 조건이라고 볼 수 있습니다.
그리고 Game의 목적은 사용자(플레이어)에게 재미를 주는 것이기 때문에, 게임의 재미를 검증한다는 것은 GQA에서 반드시 필요한 부분이라고 봐야할 것이고요. =)

경력 늅늅의 저는 이 정도에서 발언을 마무리해야할 것 같습니다.
다른 QA 직군 분들의 많은 발언이 이어졌으면 좋겠네요. =)

0

Share this post


Link to post
Share on other sites
이 글을 팔로우하기  
팔로워 0