• 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

[아카이브] 테스터가 개발팀에 통합되어야 하는 이유

3 posts in this topic

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

---

 

 
Why game testers should be integrated into the development teams

아래에 나오는 '복잡한 시스템'은 원문에서 complex system 즉 '복잡계'를 의미하며 실제로도 그런 뜻으로 쓰인 듯 합니다만, 이 용어게 익숙치 않은 분들에게 그냥 '복잡한 시스템'이라고 써도 의미가 통할 것 같고 왠지 더 쉬워보여서 그냥 '복잡한 시스템'이라고 옮겼습니다. 

http://www.gamasutra.com/blogs/JohanHoberg/20140725/221868/Why_game_testers_should_be_integrated_into_the_development_teams.php

------------------------------------


제프 서덜랜드(Jeff Sutherland)는 최근 애자일이란 분리된 테스트팀을 없애는 것이라는 내용의 글을 썼다. 그는 마이크로소프트에서의 툴 개발이 테스터를 개발팀에 통합함으로써 어떻게 30000개였던 버그가 3000개로 줄어들었는지에 대해 얘기한다.[1] 

물론 테스트팀이 분리되어야만 하는 예, 또는 최소한 분리되어도 괜찮은 예를 언제든 찾을 수 있을 것이다. 필수 합격 판정 테스트 (mandatory customer acceptance test) 또는 확인 테스트가 그 예이다. 로컬라이징 테스트도 또다른 예가 될 수 있을 것이다. 그러나 이 글에서는 이런 경우는 다루지 않겠다. 

자 그럼 왜 테스터는 분리된 팀으로 존재해서는 안될까? 왜 거의 모든 게임 테스터들이 개발팀으로 통합되거나 최소한 개발 과정의 일부가 되어야 할까? 짧은 답은 "복잡성"과 "조합 확산(combinatorial explosion)" 때문이다. 적어도 이 주제에 대한 내 의견은 그렇다. 

거대한 게임 월드, 멀티플레이, AI, 예측불가능한 유저들, 그리고 그 외 많은 요소들이 게임의 복잡성을 더하며, 이는 다른 소프트웨어에서는 보기 드문 일이다. 게임은 예측불가능하며 때로 아무런 이유없이 무작위로 동작하는 것처럼 느껴질 때도 있다. 뭔가를 바꿨을 때 그 영향과는 아무 관계 없어보이는 분야 또는 요소에서 버그가 발견되곤 한다. 복잡한 시스템 (complex system)[2] 이기 때문이다. 

게임 테스터들이 분리된 팀에 앉아 있으며 개발 과정에서 능동적 역할을 하지 않는다면, 이는 그들이 게임이라는 복잡계가 어떻게 동작하는지에 대한 적은 통찰만을 가지고 있음을 의미한다. 그들에게 이 복잡한 시스템은 더더욱 예측불가능하고 무작위적으로 느껴진다. 여기에 게임 테스터들은 일반적으로 다른 분야의 테스터들에 비해 덜 명확한 요구사항을 전달받는 점이 더해진다.[3] 즉 뭔가 바뀔 경우 게임 테스터들이 아무것도 잘못된게 없는지를 확인하기 위해서 모든 것을 회귀 테스트해야한다는 말이 된다. 대부분의 최신 게임들이 점점 더 커지고 점점 더 다른 소프트웨어와 연계되어 가면서, 경우의 수는 점점 더 커지고 있다. 뭔가가 바뀔 때마다 해야하는 테스트는 조합확산[4]으로 증가한다. 

테스트팀이 분리되어 있을 경우 이는 그들이 테스트해야하는 일의 가짓수가 게임 컨텐츠의 증가에 따라 지속적으로 (심지어 선형적이지도 않게) 커진다는 의미이다. 이는 다시 테스트팀 자체가 커져야하며, 선행기간 또한 증가하거나 아니면 모든 것을 테스트하지는 못한다는 얘기가 된다. 분리된 테스트팀이 다루는 것이 복잡한 시스템이기에 그들은 무엇을 테스트해야하는지에 대해 아무런 확신도 갖기 어려우며, 무엇을 테스트하지 않아도 되는지 모른 나머지 치명적 버그를 방치하게 될 수도 있다. 

선행기간의 증가 또는 팀이 계속해서 확장되는건 선택가능한 사항이 아니기에, 일을 진행시키는 유일한 방법은 테스트할 부분들을 더 나은 방법으로 선택하는 것 뿐이다. 그리고 내 생각으로는 그렇게 하기 위해서 두 가지가 필요하다. 시스템 전문가(게임 개발자와 시스템 아키텍트)와의 더 나은 커뮤니케이션, 그리고 이 복잡한 시스템에 대한 더 나은 이해가 그것이다. 이를 통해서 예측불가능성과 무작위적으로 느껴지는 현상을 줄일 수 있다. 

이쯤되면 다들 아시겠지만 이에 대한 내 의견은 테스트팀을 개발팀에 통합함으로써 전술한 조건들을 달성할 수 있다는 것이다. 

내 친구와 여기에 대해 얘기하던 중, 친구는 '그렇다면 각각의 테스터들이 각 개발팀에 흩어져있다면 전체 시스템의 테스트는 누가 하는건가? 각기 다른 개발팀에서 만든 변경점들이 모두 함께 잘 동작하는지는 누가 확인하는가? 전체 게임이 실제로 동작하는지를 확인할 시스템 테스트팀이 필요하지 않은가?'하는 질문을 던졌다. 

내 대답은, 시스템 테스트의 필요성과 시스템 테스트 팀의 필요성을 혼동하지 말아야 한다는 것이다. 시스템 테스트는 아마도 가장 복잡한 테스트일테고, 나는 여기에 대한 답이 게임 테스터들로 하여금 개발팀과 커뮤니케이션하는 것을 더 어렵게 만들고, 게임이라는 시스템의 복잡성에 대한 더 낮은 통찰을 주는 것은 아니라고 본다. 

증가하는 복잡성과 조합확산으로 인해 우리는 테스트를 더 영리하고 효율적으로 해야만 한다. 이런 난문제를 해결하기 위한 답이 게임 테스터들을 개발 과정에서 더 멀리 떨어뜨리는 것은 절대 아니라고 본다. 

적어도 내 의견은 그렇다. 

References

[1] Agile means get rid of test teams

http://scrum.jeffsutherland.com/2014/07/agile-means-get-rid-of-test-teams.html

[2] Wikipedia: Complex system

http://en.wikipedia.org/wiki/Complex_system

[3] Cowboys, Ankle Sprains, and Keepers of Quality: How is Video Game Development Different form Software Development

http://research.microsoft.com/pubs/210047/murphyhill-icse-2014.pdf

[4]Wikipedia: Combinatorial explosion

http://en.wikipedia.org/wiki/Combinatorial_explosion
 

0

Share this post


Link to post
Share on other sites

최근들어 갑자기 테스팅 관련 글들이 올라와 개인적으론 기쁘게 생각됩니다. ㅎㅎ

그런데 사실 테스트 조직이 개발팀에 통합되는 지 분리되는 지는 어찌보면 중요한 일은 아닙니다.
사실 중요한 내용은 본문에서 말한 것처럼, 정보로부터 고립되느냐 그렇지 않느냐라고 생각합니다.
이와 관련해서는 두 가지 이슈가 있는데요,
하나는 "테스트는 개발 프로세스 초기부터 시작되야 한다"라는 Early Testing이라는 이슈가 있고, 다른 하나는 "테스트 조직은 개발 조직으로부터 멀리 떨어져있을 수록 유리하다"라는 테스트 독립성에 대한 이슈가 있습니다.
테스트 방법론 중에 V 모델이라는 (가장..까지는 모르겠지만) 널리 알려진 방법이 있습니다.

6ffc96b05f1b9423.jpg
출처: [S/W Testing V-Model]
(http://blog.naver.com/josephy74/70018639453)

왼쪽은 Verification이라고 불리는 검토? 확인? 과정인데요(배울 때부터 원문으로 배워서 뭐라 불러야 할 지 잘 모르겠습니다), 정적인 활동(Static Testing)으로 분류되는 초기 설계 단계의 확인 작업입니다.
오른쪽은 Validation이라고 불리는 검증 과정인데요, 설계에 따라 제작된 실제 제품을 확인하는 작업입니다.
그리고 수평선으로 이어진 것은, 각각의 Verification과 Validation이 단계에 따라 1:1로 매칭된다는 것을 의미합니다.
따라서 단적으로 이 모델의 그림만 보더라도, 개발 공정 초기의 Verification은 이르면 이를 수록 더 많은 결함들을 예방할 수 있고, 이는 오른쪽의 Validation이 위로 갈 수록 복잡도가 높아지는 것을 감안하면, 결국 더 효과적이면서 효율적인 결함 감소를 이룰 수 있다는 것을 알 수 있습니다.
테스트 조직의 Verification 시점이 늦어진다는 건, 오른쪽 Validation 단계의 아래쪽에 가까운 테스팅에 한해서만 영향을 미칠 수 있게 되며, 결국 점점 더 적은 단위의 기능 테스트에서밖에 실질적인 영향을 발휘할 수 없게 됨을 의미합니다.

그리고 두 번째로 말씀드린 테스트 조직 독립성의 경우는, 쉽고 단적인 예로 자기가 쓴 글의 오탈자는 눈에 잘 안들어오지만 다른 사람이 봐주면 더 잘 찾을 수 있는 것과 유사한 성격으로 이해하실 수 있을 것 같습니다. 이러한 객관적인 시선을 유지하려면 개발팀으로부터 테스트 조직이 독립적으로 분리되어 있어야 한다는 이론이고요, 이것 뿐만 아니라 사실은 실제 제품을 출시하는 것에 있어 얼마나 강한 영향력을 독립적으로 행사할 수 있느냐하는 권한의 이유와도 연결되어 있습니다. 이것도 쉽고 단적인 예를 들어보자면, 개발실에 실장이 있고 그 아래 QA팀과 팀장이 있다고 했을 때는, 결함율(Fail Rate)이 높아서 또는 치명적인 결함(Critical Incident)이 존재하기 때문에 이 제품은 아직 출시할 수 없습니다라고 QA팀장이 출시를 반대하면, 더 높은 직속 상관인 실장이 "괜찮아 그냥 출시해"라고 할 수도 있겠지만, 독립된 테스트 조직의 수장이 "안돼요"라고 하면 이 때도 똑같이 실장이 "괜찮아"라고 할 수는 없는 정도로 설명할 수 있을 것 같습니다.

이 둘을 절충하기 위해서는, 물리적으로 가까운 거리에 있으면서도 독립성을 인정하고 지켜주는 방법과 물리적으로 먼 거리에 있으면서도 긴밀하게 개발 초기부터 커뮤니케이션 하는 방법 정도가 양립할 것 같습니다.
이 둘 중 각 개발/테스트 조직의 여건에 따라 가능한 방법을 사용하면 되지 않을까하는 생각을 해봅니다.


* PS. (일단 우리나라에서만큼은) QA는 개발조직이다 개발지원조직이다, 즉 게임개발자이다 아니다부터 아직 전체적인 동의의 여론이 확산되지 않았다는 것을 감안해보면, 아예 개발 조직 내부로 흡수해야한다는 본문같은 의견이 더 많아졌으면 좋겠다는 개인적인 생각이 있습니다. 독립성은 그 뒤에 챙겨도 괜찮지 않을까란 생각이 있거든요.

* PS2. 그리고 직종을 변경한 지도 벌써 3~4년 정도 된 것 같아 사실 위 의견에 마구 강려크한 자신감을 갖기는 좀 어렵다는 생각이 듭니다. 따라서 현업 QA 존잘님들께서 찰진 댓글을 아래에 더 남겨주셨으면 좋겠다는 생각이 있습니다! =)
 

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

Share this post


Link to post
Share on other sites

bbjoony 님이 작성하셨던 리플라이의 아카이빙입니다.

---

 

근본적으로 테스트가 가급적 일찍 수행되어야 한다는 Early Testing의 개념에는 일말의 이견없이 동의합니다. 물론 아직 국내에서는 개발자/디자이너/그래픽 담당자를 구하는 스타트업의 구인광고는 많아도 QA를 구하는 구인광고는 보기 힘든데, 아직까지 Early Testing의 개념이 업계 전반에 널리 받아들여지지는 못하고 있는 것 같습니다. 

반면 어떤 스타트업에서는 애자일을 수행한다고 이야기하면서 개발자 테스팅에 의존해 별도의 QA나 테스트 전문 조직을 꾸리지 않는 경우도 많이 보입니다. 이 경우 Early Testing의 개념에는 충실한 듯 보이나 QA/테스팅이 왜 독립적으로 수행되어야 하는지를 잘 이해하지 못하는 경우라고 봐도될 것 같습니다. 

최근에는 2~3명의 소규모라고 해도 개발팀 내부에 QA를 꾸리고, 이후 시스템 레벨 급의 대규모 리소스 투입이 필요한 경우에는 아웃소싱이나 상대적으로 대규모 팀을 운용하는 퍼블리셔에게 이 부분을 의존하는 경우가 늘어나고 있는 것 같습니다. 

아웃소싱 테스트 일을 하다보면 예전처럼 왜 QA가 필요한지를 설명하고 설득해야 하는 경우는 많이 줄었습니다. 그만큼 게임에 있어 품질 관리가 필수적인 요소라는 것은 이제 상식으로 자리잡아 가는 것 같습니다. 반면 최근에는 비용 대 효과를 고려해 언제 어떻게 QA/테스트를 수행해야 하는지를 컨설팅하는 경우가 많아지고 있습니다. 그만큼 국내 게임업계의 품질에 대한 인식 수준이 조금씩 높아지고 있다는 반증이겠지만, 아직도 가야할 길은 멀어 보입니다.  

좋은 글 번역해 주셔서 감사합니다. 
다시 한 번 제가 하는 일과 현재의 트렌드에 대해 고민해 보게 하는 좋은 기회가 되었네요.

감사합니다. :smile: 
 

0

Share this post


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