주석 : 이 가르침들은 기본적으로 큰 뜻을 품은 게임 디자이너들을 위한 것이지만, 여기에서 다루고 있는 많은 개념들은 게임 산업에서 다른 형태로 종사하는 사람들에게도 적용될 수 있다. 이 가르침들은 변경되고 개선될 수 있으며, 독자들의 의견은 환영하는 바이다. 특히, 나는 내가 게임 산업에서 쌓은 20년이 넘는 경력 때문에 다소 “지긋지긋한” 사람으로 인식되는 경향을 극복하기 위해 아직도 노력중이다. 어떤 부분이 너무 부정적인지를 내게 알려준다면, 내가 그 부분을 완화시키겠다. 이 얘기는 이번 과 뿐만 아니라, 앞선 과들에게도 적용되는 말이다.

게임 업계에서 일을 시작하려면 테스터라는 일이 좋다는 말을 분명히 들어보셨을 것입니다. 부정적인 의견도 함께 들으셨을 것입니다. 하지만, 말씀 드리건대 그런 부정적인 말들은 죄다 틀린 것입니다. 물론 테스트는 하위 보조 업무이고, 밑바닥 일입니다만, 매우 중요한 일입니다. 또한 게이머들에게 즐거운 경험을 선사하며, 게임을 빛나게 하는 생명 같은 일입니다.

테스터는 훌륭한 취직의 길이기도 합니다. 이번 글에서 그 이유를 많이 찾을 수 있을 것입니다.

용어 해설 : 테스트팀은 "품질보증(Quailty Assurance)"부서로 불리기도 합니다. QA라는 약어로서 테스트과 관련된 업무나 처리를 나타냅니다. 본문에서 "테스트"와 "QA"가 같이 쓰이고 있습니다.

주석 : 본문의 테스터는 상근직을 지칭합니다(즉 생업으로서 회사에 테스트 결과를 보고하는 고용인). 자원봉사자, 즉 "베타 테스터"(집에서 게임을 해보고 이메일로 보고하는 무급 테스터)는 이 글과 무관합니다. 테스터로 취직하는 것은 게임 업계에 종사하는 좋은 방법이지만, 베타 테스터는 일반인이나 다름없습니다.

최종 단계로서의 테스트

액티비젼(Activision)같은 대형 개발사에서 QA는 프로젝트의 최종 과정입니다. 이런 곳에서 테스터는 게임의 대부분이 완료될 때까지 투입되지 않습니다. 이는 테스터들이 기획 과정에 참여할 수 없고, 관련 사항을 알려주지도 않기 때문에 불행한 일입니다. 하지만, 소규모 회사에서는 개발에 참여하는 팀원이 테스터 역할도 겸합니다. 따라서 그들은 관련 사항에 대해 잘 알고 있으며 프로젝트에 관련된 결정에도 참여합니다.

일반적으로 테스터는 프로젝트의 최종 단계에 투입되므로, 게임의 주요 기획에 영향을 미치지 못합니다. 그러나 게임을 망칠 수는 있습니다. 군사적으로 보자면, 테스터는 병사입니다. 기획/개발팀은 장교입니다. 좀 과장되었지만, 그렇게도 볼 수 있습니다. 그러나 테스터를 하게 될 여러분이 게임 개발 현실에 적용하기에는 무리가 있군요.

전장에서 장군은 모든 병사를 바라보지 않습니다. 병사는 지시 받은 대로 행동해야 합니다. 모든 병사에게 전략을 설명할 시간이 없기 때문이죠. 가능한 저는 게임 제작 과정에서 테스터들과 함께 전략을 공유하려고 합니다. 그러나 모든 기획자나 개발자가 그렇게 하지는 않습니다. 자신의 아이디어를 게임에 반영할 수 없다는 사실을 납득하지 못하는 테스터도 있습니다. 유감스러운 일입니다.


테스트는 정말 중요합니다

기획자 겸 개발자로서, 자기가 만든 게임이 쉽고, 친숙하고, 재미 있다는 점은 중요한 일입니다. 그만큼 단점을 찾는 것도 어렵습니다. 저 또한 테스트 중에 많은 버그를 찾지만, 테스터들이 발견한 버그를 "그건 버그가 아닙니다" 또는 "원래 기획에 있던 것입니다"라고 거절하기도 합니다. 몇 번 거절 당한 테스터는 반감을 갖기도 합니다. 그러나 편을 가르면 안됩니다. QA팀과 저는 같은 목표를 공유하니까요. 즐거운 게임을 만드는 겁니다.

확실하게 재미있는 게임을 만드는 방법은 오로지 꼼꼼한 테스트 뿐입니다. 여러 사람의 눈으로 보고, 여러 사람의 손으로 해보세요. 저의 플레이 방식은 하나 뿐입니다. 하지만 다른 사람은 그 사람만의 방식이 있습니다. 어쩌면 제가 상상도 하지 못했던 방식일 수도 있습니다. 그런 식으로 게임이 출시되기 전에 모든 문제점을 찾아내야 합니다.


테스트는 쉽지 않습니다

어떤 사람은 "테스트"가 온종일 게임만 하는 일이라고 생각합니다. 재미있고 쉬워보이죠.
그렇지 않습니다. 오랫동안 재미 있을 수도 있습니다(재미 있는 일이 될 수도 있습니다). 하지만 업무라고 느끼면 절대 그렇지 않습니다.
게임을 하는 것은 즐겁습니다. 그러나 어렵죠. 게이머에게 물어보세요. 쉬운 게임은 재미가 없습니다.
게임이 재미없다면(균형 잡힌 게임이 아니라면), 계속 반복해서 하기란 정말 고역입니다. 당신의 업무가 테스트라면, 설령 재미없다 해도 계속 해야 합니다. 그래서 정말 어렵죠!

테스트를 반복하다 보면 똑같은 부분을 수십 번 해야 할 때도 있습니다. 게임의 재미는 점점 사라져갑니다.

테스터는 컴퓨터에 능숙해야 합니다. PC 게임을 테스트한다면, 각종 카드(역주: 그래픽/사운드 지원 카드)와 조이스틱, 드라이버를 설치해야 합니다. 설치/제거하는 것이 가능해야 하고, OS를 다시 설치할 수도 있어야 합니다. 플레이스테이션 2, 게임보이 어드밴스 게임이라고 해도, PC로 보고서를 써야 합니다.

테스터는 의사소통에 능통해야 합니다. 회사 내에서 놀라운 능력으로 버그를 찾아낸다 해도 팀원들에게 버그를 어떻게 찾았고, 버그가 무엇이고, 무엇이 발생했고 할 것인지, 코드에서 잘못 돌아가고 있는 것이 생각한 바를 표현할 수 없다면, 전혀 소용이 없습니다.

"녹색 검을 집고 파란 물약을 마시니까 게임이 깨짐" 훌륭한 테스터는 버그를 찾아 보고하는 것으로 끝내지 않습니다. 좋은 테스터는 깊게 파고 들어 갑니다. 게임이 어떻게 돌아가는지는 알고 있고, 이를 바탕으로 버그가 어떻게 발생했는지 고심해봅니다. 그리고 무엇이 정말 잘못되었는지 생각합니다. 다시 "녹색 검을 집고 파란 물약을 마신다"를 하면 버그가 안 나올 수도 있습니다. 다른 요인이 있을 수도 있습니다. 좋은 테스터는 불독과도 같습니다. 끈질기게 버그를 찾아 이빨을 쑤셔 넣으세요. 그 이유를 찾을 때까지 절대 놓치면 안됩니다.

테스트는 재미를 쫓아다니는 미숙련자가 할만한 일은 절대 아닙니다.


현장 학습
테스트 업무는 게임 산업을 배우는 좋은 방법입니다. 여러 가지를 접할 수 있습니다 (직접 그 일에 관여하지 않아도 상관없습니다). 여러 게임에서 테스트를 하면서, 산업 전반에 대해 많이 배울 수 있습니다.


개발 측면
(여기서 쓰는 '개발'은 프로젝트에서 '제작 전 단계'를 지칭합니다. 즉 기획을 언급합니다. '제작'은 프로그래밍, 미술, 음향 등을 만드는 것을 지칭합니다) 테스트를 하는 동안, "왜 이렇게 기획했지?"라는 의문이 떠오를지도 모릅니다. 세부 사항을 구현하는 방법은 여러 가지가 있으며 또한 테스터는 게임을 가장 빨리 접합니다. 테스터는 시시각각 변하는(또는 변하지 않는) 기획의 측면에 노출됩니다.


제작 측면
테스터는 버그를 찾아 보고합니다. 대부분은 수정하고 끝나는 간단한 문제입니다. 그러나 어떤 경우 QA와 제작팀 사이에 토론이 필요한 복잡한 문제일 수도 있습니다. 그 동안, 테스터는 제작팀이 무슨 일을 하는지 파악할 수 있습니다. 그러면서 전체적인 제작 과정에 대한 넓은 시야를 가질 수 있습니다.


마케팅 / 판매 측면
테스터에게 테스트가 전부는 아닙니다. 패키지와 매뉴얼 문구를 살피기 위해서도 불려집니다. 하드웨어 사양은 정확해야 하고, 요구 사항 또한 표기되어야 합니다(특히 게임의 특징이 묘사되어야 합니다). 이런 사항들을 파악하여 실제로 제품을 살 사람들이 어떻게 제품을 보게 될지 식견을 가질 수 있습니다.

선적 기일 같은 끔찍한 최종일자는 버그 수정을 불가능하게 합니다(버그의 우선순위가 낮을 수록). 몇 번의 게임 프로젝트를 거치는 동안, 테스터는 버그의 우선 순위를 정하는 것이 매우 중요함을 알게 됩니다. 회사는 테스터의 월급을 주기 위해서라도 게임을 출시해야 합니다. 언제까지 테스트만 할 수는 없겠죠. 제작 과정에 몇 차례 참여하면서, 이익을 내야 하는 현실을 깨닫습니다. 또한 버그의 우선 순위를 정하는 중요성에 대해서도요.


고객 지원 측면
게임을 면밀히 테스트하는 일은 당연합니다. 그러나 게임이 시장에 출시되었을 때부터 문제가 발생합니다. 고객은 잔인합니다! 게임에서 할 수 있는 방법을 모두 시도해보고 제작이나 QA에서 결코 생각하지 못한 것들도 있습니다. 고객 지원팀으로 전화가 옵니다. 보통 첫번째 고객 지원 전화는 QA쪽으로 연결됩니다. QA팀과 고객 지원팀 간의 관계는 그래서 중요합니다. 할 일을 다했다고 생각한 테스터에게 이제 "이 하드웨어 사양으로 게임을 해보세요. 그리고 무슨 일이 일어나는지 살펴보세요" 하고 서비스 업무 지원 지시가 내려집니다. "어떻게 이걸 놓칠 수가 있습니까?"라며 시비를 걸 수도 있겠죠. 이 방면으로 테스터의 실제 업무는 별로 없지만, 고객 지원 측면의 주요 이슈에 대해 배울 수 있습니다.


생산 측면
생산 또한 게임 제작에 참여함으로써 배울 수 있는 것 중의 하나입니다.

- 프로젝트를 끝마치기 전에 최종 확인을 위해 테스터에게 패키지와 매뉴얼을 줍니다. 명심하세요. CD를 꺼내 실행하는 것보다 박스와 매뉴얼을 찍어내는데 더 시간이 걸린다는 점을요.

- 게임기용 CD라면(PC 용보다 낫습니다), 테스터는 플랫폼을 확인해야 합니다. 그리고 패치가 불가능하다는 점도 잊어선 안되겠죠. 게임기용 CD는 첫 출시 때 잘 작동해야 합니다. 가끔 드물게 생산 과정에서 문제가 발생하기도 합니다. 그러면 테스트를 다시 하는 것은 당연하고 재출시까지 경험할 수 있습니다. 설령 이런 일이 없다 해도 매일매일 겪는 일상을 통해, 게임을 출시하기 위해 겪어야 하는 일들이 얼마나 고통스러운지 느낄 수 있을 겁니다(플레이가 지긋지긋하게 느껴지겠죠).

- 프레스 되는 CD와 골드 CD(CD-R로 만들어지는 CD)는 제작 방법이 다릅니다. 제가 만든 게임 중 하나는, "레드북 스탠다드(redbook standard)"에 따른 자체 음악 트랙이 있었습니다. 테스트할 때는 물론 잘 돌아갔습니다. 공장으로 게임을 보낼 때까지 몰랐지만, 그 CD 제작기는 음악 트랙 사이에 매우 짧은 공백을 넣는다는 것이었습니다. 이런 CD로 게임을 했다면, 아마 모든 음악이 하나의 트랙으로 플레이 되었을 겁니다. CD 헤드가 트랙을 인식하려 할 때마다, 시작 부분을 찾지 못하니까요(다른 곡 시작을 할 때 눈깜짝할 사이에 실패가 발생합니다). 결국 우리는 마스터 작업을 다시 했습니다. 각각의 트랙 사이에 공백을 넣어서 말이죠. 저는 여기서 뭔가 배울 수 있었습니다. 여러분 역시 그럴 거라고 생각합니다.


게임 산업을 배우는 방법에 대해 살펴보셨는지요? 그러나 여러분이 생각하는 테스터는 매일 게임만 하는 사람입니다.


테스트는 디딤돌입니다 ...더 큰일을 얻어내려는 사람들을 위한


좋습니다. 제목에 충분히 설명이 되었습니다. 그렇다고 테스터보다 더 중요한 일을 하기 위해 그만둘 필요는 없습니다. 열심히 일하고 성과가 좋고, 그리고 훌륭한 애사심을 보여주면, 의사를 효율적으로 잘 전달한다면 더 높은 위치로 발전할 수 있을 것입니다.

여러 프로젝트에서 훌륭한 테스트 성과를 올리면, 수석 테스터로서 올라갈 수 있습니다.

여러 프로젝트에서 수석 테스터로서 실적을 올리면, 테스터 팀장이 될 수 있습니다. 또는 개발 스튜디오의 일원으로 참여하길 요청 받을 수도 있습니다. 개발 진행 책임자나 부 프로듀서, 초보 기획자로 말이죠.

그냥 보여주세요. 승진 기준이 될 만큼만 일하지 마세요. 당신은 빛나야 합니다. 다른 사람보다 더욱 활활 불타야 합니다. 거둔 대로 뿌립니다(영원히 승진에서 누락되는 사람들에게 불평을 듣는다 해도).

어디서 들은 지 기억은 나지 않지만 적당한 문구가 있습니다.

"영리한 자는 능력을 발휘하는 방법을 배운다. 행복한 자는 결점을 이해하는 방법을 배운다"

당신에게 재능이 있다면, 게임 산업에서 중요한 역할을 하게 될 테스트 업무를 기꺼이 맡을 것입니다.


QA 용어 해설
'A' 버그 A 버그는 최악의 버그입니다. 이 종류의 버그는 "고치지 않고 출시하면 잊지 못할 끔찍한 화를 불러올 버그"로 설명됩니다. 예를 들어 :
  - 게임 파손
  - 바이러스 감염
  - 명백한 오자
  - 명백한 그래픽 / 오디오 문제
  - 기능(메뉴나 버튼를 사용하여 작동할 수 있는)이 작동하지 않음
  - 저작권 표시가 없을 경우
  - 게임이 재미없을 때
이런 결점을 안고 출시를 한다면, 형편없는 대중의 반응, 언론의 혹평을 얻거나, 심지어 회사가 당신을 고소할 수도 있습니다.


'B' 버그 B 버그는 A 버그보다는 낫습니다. 이러한 버그는 " 게임은 그럭저럭 괜찮지만, 출시하면 안 좋을 평판을 얻게 될" 버그로 요약될 수 있습니다. 재정난 등에 시달려서 게임을 출시해야만 할 때, 고객 지원팀, 판매팀, 마케팅팀, QA팀과 경영진이 모두 동의하면 테스트과 버그 수정을 중지한 채 게임은 작은 오류를 갖고 출시될 수 있습니다. 예를 들면:

  - 게임 플레이를 망치지않는 버그
  - 명백한 그래픽 / 오디오 문제(눈/귀에 띄일만큼)
  - 독창적인 기능 제거(그리고 그에 대해 게임 내에서 언급하지 않음)

B 버그는 잡지 기사에서 언급될 것입니다. 이것들을 고치는 것은 어려운 일입니다 (많은 대가를 치루게 합니다). 게임을 하는 사람들은 이런 문제가 달갑지 않을 테지만 전체적인 게임 진행이 이런 문제로 망쳐지지는 않을 것입니다.


'C' 버그 C버그는 "고치면 게임이 더 나아질" 버그로 요약됩니다. 테스터는 자신이 발견한 문제를 심각히 생각하는 경향이 있습니다. 그러나 회사가 출시의 필요성을 더 강하게 느끼고 저울질한다면, 그 버그는 의사 결정자에게는 중요하게 생각되지 않습니다. 출시하기 위해, C 버그는 포기될 수도 있습니다.(고치기 어려운 문제라면, 그렇게 되겠죠 -- 중요도가 낮은 C버그는 간단히 고쳐질 것 같지만 생각대로 진행되는 일은 없습니다)


'D' 버그 "이것까지 고치면 금상첨화입니다." 테스터 과정에서 늦게 발견되면, D 버그는 수정되지 않을 수도 있습니다.

"모든 버그를 고칠 것" 이상적으로는 옳은 이야기지만 어떤 게임은 너무 크고 복잡해서 수정하는 것이 결코 끝나지 않을 수도 있습니다. 가능한 회사에 있을 때 출시되기 전에 모든 사항을 체크하고 균형을 맞춰야 합니다.


"알파" "알파"와 "베타"라는 용어는 회사마다 달리 쓰입니다. 개발사에서 유통사까지 정의가 다릅니다. 어떤 개발자는 "게임을 할 수 있는 단계"를 알파라고 부릅니다. 그러나 대부분의 유통사(특히 유통사의 QA 부서에서)는 이렇게 정의합니다. "모든 기능이 구현되어 있지만 버그도 있고 균형도 잡아야 하는 상태"

"베타" 어떤 개발자는 베타를 이렇게 생각합니다. "기획한 모든 것이 구현되어있습니다. 그러나 버그가 있고 게임플레이는 주의할 필요가 있습니다" 하지만 대부분의 유통사(혹은 QA 부서)는 베타를 이렇게 언급합니다. "모든 것이 다 되고 개발사가 아는 것과는 달리 버그가 없고 게임 플레이도 완벽히 돌아간다."


"재현 불가" 테스터는 분명 발견했지만, 다시 보여줄 수 없는 버그가 발견될 때도 있습니다. 프로그래머가 디버거를 갖고 코드를 면밀하게 탐색해도 그 문제를 다시 밝혀낼 수 없다면, 수정하는 작업은 불가능할 것입니다. 재능 있는 테스터라면 더욱 끈질기게 노력해보고, 왜 발생했는지 추리해 내야겠죠.

"골드 마스터" CD 또는 DVD로 QA팀을 거쳐 생산되는 제품입니다. 이 디스크는 실행 확인 및 바이러스 검사를 해야 합니다. 더불어 출시하기 전에 상세한 검사 목록을 통과해야 합니다.

"어색함" 테스터에게 최대의 칭찬은 "버그 없음"과 "기획한대로 작업됨"입니다. 때때로 테스터는 게임에 자신이 원하는 바를 삽입하려고 보고서를 임의로 쓸 때도 있습니다. 보고서를 받아본 기획자는 이렇게 답하겠죠. "버그가 아닙니다. 기획한대로 작업된 겁니다. 이게 여기 있는 이유를 말씀 드려보자면..." 라고요. 만일 테스터가 발견한 것이 어색하다는 점을 확신 있게 설득한다면, 바꿔질 수도 있습니다.

"더 많은 정보 필요" 이 문구는 프로그래머에게 버그가 어떻게 반복되는지 충분한 정보를 제공하지 않을 경우 자주 보게 될 겁니다. 또는 테스터가 그걸 버그라고 느낀 이유를 밝히지 않을 때도 마찬가지입니다.

"버그 아님" "어색함" 부분을 보세요.

"비정상 플레이" 이 용어는 합당치 않은 사용자 입력을 이유로 발생되는 문제를 가리킵니다. 예를 들어 "F10, ESC를 한 줄에 30~40번씩 누르면 게임이 깨짐"같은 것입니다 이유 없이 사용자는 이렇게 할 수도 있습니다. 그리고 누구라도 할 수 있습니다. 그리하여 예기치 않은 게임 오류가 발생합니다. 그런 문제가 고치기 어렵고 프로젝트가 막바지에 다다르면, 간단히 논의에서 제외되기도 합니다.


"완성" QA팀은 게임에 사인하고 확인 도장을 찍은 후, 생산하기 위해 게임을 보냅니다.

"선적" 이 말은 테스트 과정의 끝 부분에서 듣습니다. 테스터 팀이 터널의 끝에서 불빛을 보게 될 때이기도 합니다.

  - 테스터: "버그를 찾았어요"
  - 수석 테스터: "어떤 버그인데?"
  - 테스터: "C버그예요. 대단치는 않아요. 비정상 플레이 때 나타나요"
  - 수석 테스터: "무시해!"

완료된 게임(테스트, 품질 확인)은 수송업체(가끔 중요하고 급해서, 직접 나를 수도 있습니다)에 의해 생산 설비로 수송됩니다. 대량으로 생산되어 매장 트럭에 실립니다. "수송"은 게임을 바깥 세상으로 보내고 테스트를 끝마치는 중요함을 보여주는 주문입니다.


"변경(Tweak)" 조정과 같은 뜻

"수정 중지" 시간이 촉박할 때, 작은 버그는 보고되어도, 프로그래머나 기획자, 개발자는 버그 보고서의 이런 모호한 글을 남겨 놓을지도 모릅니다. 하지만, 모든 버그는 게임이 출시 전에 "해결" 되어야 합니다.

"기획대로 작업됨" '어색함'을 보세요(위에 있습니다).


테스터로서 직업을 구하고 싶습니까? 여기 준비하는 방법이 있습니다.

저는 학사 학위를 갖고 테스터에 지원하기를 추천합니다. 그러나 그것 없이도 지원할 수 있죠. 그러나 생각해보세요 -- 당신의 최종 목표는 무엇입니까? 만일 기획자나 프로듀서 혹은 마케팅으로 이동하기를 원한다면, 대학 학위는 명백히 도움을 줍니다. 만일 그냥 테스터가 되고 싶다면(그 이상으로는 아무 목적도 없다면), 그대로 좋습니다. 고등학교 졸업으로 충분합니다. 그러나 테스터가 되기 위해 무엇보다도 먼저 필요한 기술이 무엇인지 추측해보세요.


o 의사소통 능력

* 쓰기. 버그 리포트를 써야 합니다. 그 내용이 분명하고 명료해야만 합니다. 테스터는 충분한 문장력을 갖고 있어야 합니다

* 의사소통 능력. 테스터는 말도 잘 해야 합니다. 그의 말을 다른 사람이 충분히 이해할 수 있어야 합니다. 아래의 두 가지 훈련을 해보면 테스터가 의사소통 능력을 기르는데 도움을 줄 것입니다. 훈련을 통해 어떻게 의사 소통 능력을 향상시킬 수 있을까요? 먼저 아래 연습은 작은 방에서 하는 것이 가장 좋습니다 -- 두 사람이 연습에서 대화하고 쉽게 담화할 수 있는 역할을 맡되 다른 사람이 무엇 하는지 볼 수 없게 해야 합니다.

- 페이퍼클립 훈련 이 훈련에서 테스터는 펜과 종이를 가진 상대에게 임의로 구부러진 페이퍼 클립에 대해 설명해야 합니다. 구부러진 모양대로 듣는 이가 그려내면 성공입니다. 단, 테스터는 "페이퍼클립"이라든가 이 물체가 뭘로 만들어졌고 원래 무슨 용도로 사용되는지 말하면 안됩니다. 다만 페이퍼클립의 지금 상태에 대해 설명하세요. 테스터는 듣는 이가 올바른 페이퍼 클립 모양을 그리도록 설명해야 합니다. 훈련이 끝나면 테스터는 자신의 설명에 대해 생각할 계기가 마련됩니다. 이 훈련은 파이프 청소 도구나 묶인 줄로 가능합니다. 클립은 2차원으로 구부리세요. 2차원인 종이에 그리기 때문에 3차원 모양은 좀 어렵습니다.

- 블록 쌓기 훈련 이 훈련은 닌텐도 아메리카의 직원들과 소속 고객 지원 팀원들을 훈련시키는데 이용했습니다. 제 생각에는 테스트에 필요한 의사 소통 기술을 잘 적용될 것 같습니다. 훈련하는 양 팀은 동일한 나무 빌딩 블록 상자를 가집니다(레고 같은 걸로 해도 됩니다). 테스터는 블록을 이용해 구조물을 쌓고 훈련하는 다른 참가자에게 구조물에 대해 설명합니다. 테스터가 잘 설명한다면, 두개의 구조물은 동일해질 것입니다. 두 개의 구조물이 다르다면, 무엇을 잘못했는지 배울 수 있습니다.


o 컴퓨터 상식. 테스터는 컴퓨터를 분리하고 그것들을 원래대로 하는 방법을 알고 있어야 합니다. 인터넷 탐색하는 법이나 이 메일, 인스턴트 메시징, 채팅룸 네티켓에 대해서도 물론입니다. 또한 인스톨 하다가 발생하는 문제도 해결할 수 있어야 합니다. 드라이버를 다운로드 하거나 바이러스 데이터파일을 갱신하거나 컴퓨터를 업그레이드 지식도 필요합니다. 또한 워드 프로세서나, 이미지 프로그램, 스캐너, 모뎀에 관련된 지식도 필요하죠.

o 게임 상식. 할 수 있는 한 많은 게임을 해보세요. 그리고 그것들의 장단점을 비교해보세요. 게임 잡지를 읽어보고, FRP와 RTS가 뭐가 다른지 알아두세요. 온라인게임, 콘솔 게임, 핸드헬드 게임, 보드 게임, CCG 등에 대해서도요.

이미 말했지만 반복하자면, 게임 산업에 종사하기 위한 최선의 방법 중의 하나는 테스터입니다. 다른 비관론자들이 테스트가 밑바닥 업무라고 해도 무시하세요. 대부분 테스트가 얼마나 중요한지 깨닫지 못합니다. 더불어 게임 제작과정에서도 테스트가 얼마나 중요한지를요.


[원문] http://www.sloperama.com/advice.html
저자 : Tom Sloper

번역 : 이웅주
----------------------------------------------------------------------------------------

아주 잘 정리된 글입니다. QA는 물론 PM이나 PD, 기획자도 한번씩 읽어보면 좋을 듯 싶네요.

나중에 시간이 되면 제 생각도 한번 정리해 볼께요.