X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

     
   
게임 개발사에서의 테스팅 및 QA 경험
글쓴이 : Jio QA Life 날짜 : 19-04-06 16:12 조회 : 2265
안녕하세요! 이제 막 4년 차에 접어든 게임 QA입니다.
부족한 지식과 경험으로 작성한 글이지만 재밌게 읽어주셨으면 좋겠습니다^^

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

첫 개발사 QA로 업무를 시작하게 되었다.
현장의 경험이 제일 중요하다고 생각하기에 개발 프로세스를 직접 눈으로 보고 느낄 수 있는 환경에 오게 되어
너무 기쁜 순간이었다.

“팀장님, 저희는 어떤 개발 프로세스와 문화를 가지고 있나요?”
“음.. 딱히 어떤 개발 프로세스를 가져보자 하며 기반을 다지면서 성장한 조직은 아니고, 현재 인력 Pool과
구성원들의 퍼포먼스를 고려해서 개발을 하다 보니 현재는 LAB제 방식의 개발 프로세스로 기반을 잡아가고 있어요”

나는 더 이상 질문하지 않았다.

그래서 LAB 제 방식의 개발 프로세스가 무엇이냐고 여쭤보고 싶었지만
어차피 내가 곧 경험하게 될 일들이었고 팀장님께서 처음에 1달 정도는 실무에 집중하는 것보단
각 유관부서들 간의 커뮤니케이션 방식이라든지, 전체적인 개발 방식과 조직 문화를 파악하고 적응하는 데에 힘을 써달라고 하셨고 그렇게 해야만 QA 프로세스를 잡는 데에 수월하실 것 같다는 말씀에..

커뮤니케이션 채널은 슬랙을 사용했었다.
사업&운영/QA/아트/기획/개발 채널에 순차적으로 초대가 되었고
앞으로 어떤 얘기들이 오갈지 너무 궁금해졌던 순간이었다.

그렇게 시간이 흘러 나는 어떠한 방식의 개발 프로세스를 가지고 있으며
개발프로세스 안에 QA 프로세스를 어떻게 녹여낼지에 대한 대략적인 그림이 그려졌다.

당시에 요구분석->설계->디자인->코딩->개발 순으로 순차적으로 이어지는 워터폴 모델도 아니었고,
워터폴 모델의 확장된 형태 중 하나인 V모델도 아니었다.
테스트 활동이 모든 개발이 완료된 이후에 이루어진 것도 아니었으며
각 개발 단계에 테스트 레벨을 부여하여 Early testing을 적극 활용하려는 V모델인가 싶었지만
각 개발 단계마다 상세한 문서화를 통해 작업을 진행하는 방식이 아니었고
무엇보다 문서화를 최소화하고 빠른 피드백과 긴밀한 소통이 주를 이루어 빠르게 결과를 받아보고
아니다 싶으면 빠른 피드백을 통해 즉각 대응하는.. 그런 방식이었기에 워터폴과 V모델은 확실히 아니었다.

문서보다는 작동하는 소프트웨어, 고객의 피드백, 변화에 유연하게 대처하고 개인과의 상호작용을 중요시하게 여기는
애자일 사상을 따르는 것 같다는 생각이 들었다.

이후 처음에 팀장님께서 말씀 주셨던 LAB제 방식의 개발 프로세스에 QA 프로세스를 녹여내달라는 미션을
하나씩 시작하게 되었는데 몇 가지 협의와 결정의 이슈가 생기게 되었다.

첫 번째로 LAB 제 방식의 개발 프로세스는 각 LAB(업데이트 스펙) 별로 관리하는 담당자가 있었는데
담당자로 지정이 되면 업데이트까지 책임감을 가지고 주도적으로 구현될 기능에 대해서 리뷰하고
아젠다를 정하여 지속적인 소통을 해야 하는 상황이었다.
그런데 각 LAB 별로 QA 부서가 아닌, 다른 부서에서 랩 담당자가 지정이 되는 경우도 있어서
해당 랩에서 진행되고 있는 사항에 대한 QA 준비에 상당히 어려움을 겪었었다.
물론 랩에서 진행되고 있는 사항에 대해서 주기적으로 업무 채널을 통해 공유를 하긴 하지만, 문서화를 최소화하고 히스토리를 적극적으로 남기려는 상황이 아니었고 일단 빠르게 만들어서 결과물을 보고서 판단하려는 상황이었기에 요구 사항 변경에 대한 추적 관리가 어려워지게 되었다.

하지만 어차피 상황에 따라 기획이 수시로 변경되는 게임 QA 특성상, 오히려 빠르게 결과물을 볼 수 있었기에
테스트 설계 시간을 최소화하고 경험 기반을 활용하여 테스트 수행 기간에 시간 할애를 더 많이 할 수 있어서 장점도 많은 상황이었다. 더군다나 샌드박스형 MMORPG 인지라 테스트케이스로 잡아낼 수 있는 결함의 종류에는 한계가 있었고 실제로 리포팅되었던 대부분의 결함들은 Ad-hoc 과 탐색적 테스팅을 통해 발견이 되었다.

기획서가 배포되면 요구 사항을 분석하여 테스트 설계를 하고 테스트 수행 기간에 기획서가 업데이트되면
TC 혹은 CL도 업데이트해주며 진행하는 방식에 익숙했었던 나로서는 색다른 경험이었다.

두 번째로는 QA 기간에 테스트 수행을 DEV 서버에서 하고 있었던 상황이었는데 Git의 GUI 형태인 소스 트리에서 Pull을 받고 클라를 재실행하면 작업 중인 내역들이 다 딸려들어가는 바람에 이게 결함인지, 작업 중인 건지.. 즉 Pass 결과에 대한 판단이 애매모호해지는 상황이며 DEV 서버에서 정식 QA를 진행하는 것은 발생할 수 있는 Risk가 크고 프로세스적으로도 맞지 않다고 판단이 되었기에 개발 PM분께 DEV와 QA 서버를 독립적으로 분리해달라고 요청을 드렸었다.
이후 QA 서버가 세팅이 되면서 BAT와 함께 리그레션 테스트 및 업데이트 스펙에 대한 요구 사항 검증은 모두 QA 서버에서 이루어지게 되었다. QA 빌드가 되기 전에는 DEV에 접속하여 개발자분들과 함께 작업 중인 내역에 대한 테스트를 같이 진행했었고 얼굴을 마주 보며 소통이 가능했던지라 이상한 점이 발견되면 빠른 피드백과 대응이 가능하였다.

개발사에 오게 되면서 기획 초기부터 회의에 참가하여 예상되는 문제, 테스트 준비에 있어서 필요한 내용들을 파악하고 공유하며 테스트 수행 기간에 보다 효율적인 테스팅을 위한 어드민 커맨더 추가 개발 요청 등, 큰 틀은 동일하나 세부적으로 진행되는 업무들 모두가 새롭게 느껴졌기에 경험치가 쑥쑥 올라가는 느낌이었다.
경험해보지 못한 업무들을 새롭게 해보는 것은 큰 축복이자 성장하는 데에 있어서 나의 무지를 일깨워주는
중요한 순간이라 생각하기에 만족스러웠다. 또한 당시 근무했던 개발팀분들께서 QA를 대하는 인식이 너무나도 좋았고 실제로 개발/기획/아트 쪽 분들과 업무 관련 커뮤니케이션을 할 때엔 피부로 와닿게 느껴질 만큼
QA를 대하는 인식이 너무나도 좋았기에 퇴사를 한 지금까지도 가끔 그때의 분위기가 생각이 난다.

시간이 흘러 나는 신규 론칭을 준비하는 모바일 게임 개발사로 입사하게 되었고
이전 개발사와는 또 다른 경험을 하게 되었다.
관리자가 아닌 실무자를 원하는 조직이었는데 테스트 준비>수행>마감 활동에 필요한 것들에 있어서 수많은 프로젝트를 접해왔기에 잘 해낼 자신이 있었고 다시 초심으로 돌아가서 새롭게 배워보고 싶다는 마음이 컸던지라 예정된 업무 Role에 있어서 큰 거부감은 없었다.

입사했을 당시, 소프트 론칭을 앞두고 첫 QA 빌드가 배포될 예정이었다.
게임 QA는 게임 기획자만큼이나 담당 게임에 대한 이해가 높아야 한다고 생각하기에 첫 주는 DEV 빌드를 받아서 콘텐츠 파악에 주력했다. 3~5일간 마인드맵을 사용하여 콘텐츠를 하나씩 쪼개어 나가면서 기능 분석을 진행하였다. 전체 기능에 대한 기획서가 정리된 것이 없었기에 빌드 기준으로 예상 결과와 기대 결과를 유추해나가며 시스템 구조에 대해 파악을 하였으며 연출적인 부분을 제외하고 콘텐츠 간 상호작용되는 기능들에 대해서는 테스트 수행에 지장이 없을 정도로 파악이 되었다.

이후 차수별 기능 QA 진행 간에 필요한 산출물(테스트 계정, 체크리스트, 테스트케이스, 요구 사항 분석, 웹툴 가이드, 결과 보고서, 테스트 전략 및 플랜 등)들을 하나씩 정리하였고 GameBench 툴과 네트워크 예뮬레이터를 통해 비기능적인 부분들에 대한 체크와 함께 차수별 총 2번의 개발 QA, 2번의 호환성 QA, 2번의 론칭 QA를 진행하고서 얼마 전 소프트 론칭을 하게 되었다.

총 6번의 차수별 기능/비기능 QA와 함께 600건 이상의 결함이 발견되어 Conformation test와 리그레션 테스트를 거쳐서 세상에 공개된 게임은 마치 자식 같았으며 이전까지는 느껴보지 못한 감정들을 느낄 수 있게 되었다. 소프트 론칭을 하고서 가장 먼저 라이브에서 확인했던 기능은 설정>Credits 이었다.
내 이름이 적혀있었다. 문득 16년도에 처음으로 프로젝트 리딩을 맡았던 데스티니 차일드 신규 콘텐츠 기능 QA가 떠올랐다. 데스티니 차일드 기능 QA 리딩 이후 나는 정규직으로 전환이 되었고 지금 생각해보면 정규직 전환의 기점이 되었던 프로젝트가 아닐까 생각된다.
다른 것도 아닌 정규직 전환의 기점이 되었던 게임의 엔딩 크레딧에 내 이름이 적혀있었고
슬럼프 극복과 함께 나에게 있어서 아주 뜻깊은 순간이었다.
아마 그러한 기억이 있었기 때문에 가장 먼저 라이브에서 설정>Credits을 확인했던 것 같다.

현재는 팀장님의 가르침을 받으며 그랜드 론칭을 준비 중에 있고
돌이켜보면 이곳에 와서 보고 듣고 느끼는 매 순간이 소중한 경험이라 생각한다.
개발사로 오기 전에는 다뤄보지 못했던 Git의 GUI 형태인 소스 트리, 게임 제작에 필요한 엔진 중 하나인
유니티 등과 같이 접해보지 못하였던 Tool을 다뤄보는 것과 개발사 내부 QA 진행 프로세스 등과 같은 부분들은 경험에서 나오는 것이라 생각하기에 열심히 배워야 하고 그것을 내 것으로 만들어야 한다.
그랜드 론칭이 끝나고 게임이 어느 정도 안정화가 되면 개발사에 와서 하고 싶었던 일들을
협의하에 하나씩 해볼 예정이다.

가장 먼저 해보고 싶은 것은 작년에 내가 운영하고 있는 QA 관련 페이스북 페이지에 기재한
리스크 기반 테스팅 프로세스 도입이다.
https://www.facebook.com/ljwqalife/posts/435227213586441?__tn__=K-R

두 번째로는 단순 반복적인 데이터 검증이나 기능 검증에 대한 자동화 도입을 해보는 것인데
작년부터 시작한 프로그래밍 언어 공부와 함께 다양한 자동화 Tool 들에 대한 레퍼런스를 찾아보고 있으며
현재 가능할 것 같은 자동화 구간을 파악 중에 있다.
이를 도입했을 때 실제 효과가 어느 정도인지는 모르겠지만 시도를 해본 것과 안 해본 것은
큰 차이가 있기에 개인 시간을 할애하여 꾸준히 공부하여 실무에 적용해 볼 예정이다.

끝으로 나의 경험은 제한적인지라 앞서 얘기한 게임 개발사에서 리스크 기반 테스팅 프로세스 도입과
모바일 게임 QA 부분 자동화에 대한 것들을 경험이 많고 훌륭한 인사이트를 가지고 계시는 분들께서 많은 조언을 해준다면 앞으로 성장하는 데에 큰 도움이 되지 않을까 생각하며

비슷한 고민을 하며 살아가는 업계 QA분들 모두, 즐겁고 행복한 일들만 가득했으면 좋겠다^^

하늘소금 19-04-08 07:32
저도 예전에 게임 분야 테스팅 리더를 제안 받았었는데 제가 게임을 별로 좋아하지 않아서 안갔거든요 글을 읽어보니 게임분야도 재밌었겠다는 생각이 드네요^^
노랑이 19-04-08 09:20
좋은 글 감사합니다. 게임 QA를 희망하고 있는데 많은 도움이 될 것 같네요 :)
Won님 19-04-14 18:23
귀한 게임 분야의 경험을 상세히 설명해 주셔서 감사해요~
흥미롭게 잘 읽었고 도움됐습니다~!
koykorea 19-07-04 14:39
좋은내용 잘 봤습니다
장군yi 19-07-19 15:36
생상한 경험이군요. 감사합니다.
jjjjj 19-10-27 20:59
좋은 글 감사합니다.