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

     
   
QA와의 협업을 중요시하게 여기는 역량 있는 시스템 기획자와 함께한 모바일 게임 그랜드 론칭 실무 이야기
글쓴이 : Jio QA Life 날짜 : 19-09-01 01:06 조회 : 1401


소프트 론칭 이후 20번의 폴리싱, 버그 픽스, 신규 콘텐츠 추가를 위한 패치&업데이트가 진행되었고 최근 그랜드 론칭 업데이트가 마무리되면서 다음 주면 전 세계 140여 개국으로 개발팀과 사업 팀의 그간 노력이 세상에 공개되는 순간이 다가왔다.


​지난 6개월을 돌이키며 가장 인상 깊었던 점은 QA 팀과 긴밀하게 소통을 해오고
QA와의 협업을 중요시하게 여겼던 기획자의 모습이었다.


​그분이 개발팀에 합류하게 된 이후 우연치 않게 퇴근길이 같은 방향이라 같은 지하철에서 이런저런 얘기를 나눴던 기억이 떠오른다.
형식적인 얘기들만 오가겠지 하며 대수롭지 않게 이야기를 이어가던 도중
QA 직군과 기획 직군의 업무 Role에 대한 얘기를 주고받게 되었다.


과거에 서로 해왔던 업무들에 대한 에피소드를 주고받던 도중 형식상 하는 얘기가 아닌 진심으로 QA 팀이 진행하는 업무들에 대해 높게 평가하며 더 잘 될 수 있도록 적극적인 액션을 취하겠다는 그의 얘기들은, 실무를 진행하면서 당시 나에게 얘기했던 모든 것들이 속된 말로 그냥 하는 얘기가 아닌 진심으로 해왔던 얘기라는 것을 알게 되었다.


이후 나는 이분이라면 QA로서 내가 이루고자 하는 것들에 대해 긍정적인 스탠스를 취할 것이라는 판단에 솔직한 포부를 개인적으로 밝혔으며 남들이 알게 모르게 서로 메신저를 주고받으며 소통을 하게 되었다. 어쩌면 이분과 함께라면 리스크 기반 테스팅을 실무에 도입하는 것이 보다 수월해지지 않을까라는 기대감에 차올랐던 순간이기도 했었다.


첫 번째 에피소드는 16년도 1월에 입사하여 현재까지 테스트 케이스 설계에 필요한 기획서가 이렇게나 깔끔하고 테스트 준비에 용이하게 작성된 기획서는 이분이 작성한 기획서가 처음이었다.


나는 기획에 대해서 잘 모른다.
하지만 명세 기반으로 진행되는 테스트 준비 업무에 대해서는 그간 경험해오며 학습해온 것들이 있었고 담당 서비스의 콘텐츠 파악이 테스트 준비에 지장 없을 정도로 되었다는 전제하에 기획서를 받게 되면, 해당 기획서가 테스트 준비에 용이하게 작성된 기획서인지 아닌지를 기능 동작 플로에 따른 세부 액션, A 액션 이후 발생되는 동작 처리 조건 등을 통해 판단이 가능하다. 그것이 내가 해야 할 일이고 테스트 준비에 필요한 기획서 분석의 기초 역량이기 때문이다.


그런데 기획이 수시로 변경될 수 있는 UI 처리 조건 이외에는 기능적인 처리 조건에 대해서는 이분께서 과거에 QA를 해왔나 싶을 정도로 테스트 준비에 용이하게 작성이 되어 있었다. 그림, 텍스트 굵기, 글씨 폰트, 색상 등, QA가 테스트 준비를 원활히 할 수 있도록 고심하며 작성했던 흔적이 그대로 녹여져 있었다.


너무 고마웠다.


소프트웨어 테스트는 결함을 찾고 제품 품질을 개선하는 행위이다.
크게 Positive Testing, Nagative Testing 두 가지로 나뉘는데 나는 개인적으로 Positive Testing 항목들을 케이스화하여 진행을 할 시간에 케이스화를 안 하더라도 Navative Testing을 탐색적 테스팅이나 애드 혹 테스팅을 통해 진행하는 것을 선호한다. 실제로 경험상 시간 대비 결함 중요도 및 개수로 비교하였을 때 더 많은 이점을 남겼기 때문이다.


지난 과거를 돌이켜보면 명세의 불명확성, 불완전성이 파생되는 리스크는, 때로는 상상하기 싫은 나비 효과를 불러일으켰다. 명세가 불명확함으로 인해 빌드 기준으로 테스트 준비를 극도로 싫어하지만 불가피하게 그렇게 해야만 하는 상황들이 놓이는 경우가 있다. 나는 인 게임 기준으로 진행되는 테스트 준비 활동을 상당히 싫어하고 그렇게 해야 하는 순간이 놓이면 마음 한구석에 걱정이 가득했었다. 현재까지의 내 역량과 경험이 이 정도밖에 안되기 때문일 수도 있지만, 내가 통제할 수 있는 부분과 없는 부분 중에 없는 부분에 해당하기 때문이다.


QA라는 직군은 이슈가 결함이 되고 결함이 장애가 되는 것을 사전에 예방하고 방지하는 데에 주력하는 직군이다. 리스크가 있다는 것을 뻔히 알고서 현실과 타협하며 해야 하는 상황 자체가 걱정이었고 적어도 내가 생각하는 올바른 테스트 준비를 하고 있는 것인가에 대한 의구심을 들게 하였다.


"기획서 준비가 아직 안 되었는데 빌드는 배포가 되었으니 빌드 기준으로 기능들 보면서 준비해주시겠어요?" 과거에 외부 고객사에게 요청받았던 얘기이고 이러한 상황이 지금도 수도 없이 있을 거라 생각한다. 다양한 상황에서 유연하게 대처하는 것이 서비스 정신이고 악조건 속에서도 해내는 것이 QA의 역량이다라고 생각을 해왔지만 이제는 아닌 것 같다.


최근에 Airtest라는 자동화 툴을 통해 스크립트 작성 후, 실무에 부분 적용을 하며 내가 배운 것은 인 게임 기반으로 작성되는 테스트 준비는 되도록이면 최소화하자이다.(어디까지나 테스트 수행 간에 발생되는 결함의 유형, 개수를 척도로 판단하는 얘기이며 대부분의 Full TC의 전체 케이스 대비 60% 이상은 Positive Case라 생각하기에 필요 없다는 얘기를 하는 것은 아니다. 인력 Pool, 향후 QA 팀의 방향성에 따라 활용도는 높고 필요하다.)


결함이 발생하기 힘든 조건과 스텝으로 작성된 Positive Case는 개수가 많으면 많을수록 다양한 유형의 결함을 파악하는 데에 소요되는 시간이 줄어들게 된다. 테스트 준비에 소요되는 시간보다 수행 시간이 더 빠르다면 Major 이상의 결함을 발견해야 하는 상황에서는 문서 준비를 최소화하고 수행 중심의 테스팅이 될 수 있도록 하는 것이 효율적이라 생각한다. 이렇듯 현재 내가 속한 프로젝트는 Positive Case 설계로 인한 이점보단, Major 이상의 결함을 Live 배포전 빠르게 잡아내는 것이 더욱더 중요한 프로젝트이다.


이러한 상황에서 Navative Case를 조금 더 직관적으로 생각해낼 수 있고 그것을 케이스화 시키기에 용이하게 작성된 기획서는 나에게 있어서 큰 힘이자 버팀목이 되어줬다.


최소한의 문의 사항만을 남긴 채 테스트 준비를 원활하게 이어갈 수 있었고 준비에 따른 리소스가 줄어든 만큼 유니티 에디터에 반영된 내역들을 미리 체크해보며 빌드 마감 전 기능 동작이 어떤 식으로 구현되었는지에 대한 사전 체크에 할당되는 리소스가 많아졌기에 실제 빌드에 반영되고 나서 테스트 수행하는 데에 필요한 기능 처리 조건에 대해 보다 빠르게 이해가 가능하였다.


두 번째 에피소드는 꽤나 볼륨이 큰 신규 콘텐츠가 추가되는 시기였는데
기존 콘텐츠와 상호작용되는 부분이 많았던 기능이었고 새롭게 도입되는 기능들 또한 사용자에게 이슈화될 시 리스크가 큰 영역이었기에 강도 높게 테스트가 필요했던 부분이었다. 기본기능과 상호작용되는 부분이 많았기에 전체 기능에 대한 리그레션 테스트를 진행해야 했고 해당 콘텐츠가 추가됨에 따라 연관성이 있고 과거에 발생했던 이슈들에 대한 좁은 범위의 리그레션 테스트가 필요했었다.


그런데 QA 팀에게 주어진 빌드 마감 일정과 정식 QA 일정은 늘 그렇듯 여유롭지 못하였다. 사전 조건과 스텝, 테스트 환경 세팅이 다소 뎁스가 있었던지라 새롭게 추가된 콘텐츠에 대한 Positive 케이스를 마무리하는 것에만 꾀나 많은 시간이 소요됐었고 다수의 계정을 통해 다양한 상황을 지켜봐야 했었는데 QA 팀에서만 검증하기엔 꾀나 어려움이 있었다. 모바일 기기 5~6대, PC, 개인 노트북을 통해 자동화 스크립트가 돌아가고 있는 예뮬 레이터 2개로 다양한 테스트 시나리오를 생각하여 진행하였지만 내가 생각하기에 이 정도 수준으로는 예외 케이스 검증이 불가능하다고 판단이 되었기에 고민이 많았었다.


시간적으로 여유롭지가 못하였던 순간에 시스템 기획자분께서 이러한 고민을 알아챘는지 신규 시스템에 대한 전사 테스트를 주도적으로 진행해줬었고 다행히도 내가 확인하고 싶었던 상황들에 대한 검증이 이 기간 때에 완료가 되었었다. 물론 테스트 전략을 수립할 때에 강도 높게 테스트가 필요했다면 체계적으로 테스트 시나리오를 구성하여 QA 팀에서 주도적으로 미리 전사 테스트를 해볼 수도 있었겠지만 그러한 상황을 만들기가 쉽지가 않았었다.


이후 라이브 오픈 간에 큰 장애는 발생하지 않았고 내 실수로 인해 놓친 기획이 발생하여 선택적 업데이트가 진행된 것 빼고는 순조롭게 마무리되었다.


이외에도 자동화 테스팅 툴을 활용한 스크립트 준비에 필요한 리소스, 잘 작성된 기획서를 바탕으로 Positive 케이스를 포함한 Navative 케이스를 작성하는 데에 소요되는 리소스 분배에 있어서 큰 도움을 받았었다. 작년 이맘때쯤 현 조직에 입사하여 이 조직에서의 테스트 레벨을 자동화 스크립트 설계 준비와 실행 계획을 세우면서 아래와 같이 정의했었다.


단위 테스트(미적용)
=> Airtest와 적합하지 않으므로 논외.

​​통합 테스트(적용)
=> 통합 테스트 레벨은 아래와 같이 정의한다.
전체 모듈을 모두 통합한 이후 진행되는 빅뱅 접근법보다는 점진적 통합을 진행하고 있기에 2개 이상 모듈에 대한 단위 테스트가 끝나고 DEV&QA 에디터에 수정&추가된 스펙들이 2개 이상 적용된 시점으로 정의. 해당 레벨에 대해 모든 유관부서가 서로 합의되었던 공식적인 검증 프로세스가 있는 건 아니지만 Input>Output 기반의 블랙박스 테스트는 시스템 기획자분께서 진행하고 있음.

​시스템 테스트(최소한으로)
=> DEV 유니티 에디터와 DEV 빌드에서 통합 테스트가 완료되고 디버깅>빌드 마감 후 정식 QA 첫 빌드가 배포되는 시점으로 정의함. ARM, x86 빌드도 리소스를 고려하여 해당 시점부터 테스트 진행(유동적)

​인수 테스트(최소한으로)
=> Live 배포 전 Live와 유사한 환경에서 Airtest를 사용하긴 하지만 Risk가 있으므로 크로스 체크용으로 사용.​


여기서 가장 인상 깊었던 점은 시스템 기획자분께서 기획한 기능들에 대해 되도록이면 예외사항까지 고려한 채 QA 팀으로 넘겨준다는 점이었다. 적어도 자신이 기획한 기능에 대해서는 당시의 테스트 조건과 스텝으로는 버그가 발생하지 않았는데 정식 QA 빌드가 배포되면 꼼꼼히 한 번 더 체크해달라는 뜻을 내포하기라도 한 듯, 자신이 만들어낸 기획에 대해서 최소한의 검증을 해주셨었다.


그분과의 물리적인 거리가 그리 멀지 않았던 위치였던지라 조용한 사무실에 울려 퍼지는 딸깍딸깍 소리가 너무나도 인상 깊었다. 그 소리는 나에게 내가 이렇게 열심히 테스트해줬는데 업데이트 이후에 버그 발생하기만 해봐라라고 다가오지 않았고 제가 미리 테스트를 해봤는데 일단 문제가 없었다. 그렇지만 QA의 전문적인 스킬과 경험으로 꼼꼼하게 체크 부탁드린다는 얘기를 전해주는 것만 같았다.(실제로도 그랬다.)


품질은 QA 팀만이 책임질 수 없는 영역이고 게임 개발에 참여하는 모든 사람이 함께 짊어져야 할 이슈라는 것을 직접 보여주셨던 중년의 시스템 기획자 로건, 이산호님. 덕분에 QA로 지내오면서 많은 힘이 되었고 비록 제가 하는 일이 결함이 없음을 증명하지는 못하지만 결함이 존재함을 "사전"에 밝히는 데에 더욱더 힘을 써야겠다는 생각이 많이 들었던 순간이었습니다. 로건과 함께 팀워크를 맞춰 볼 날이 얼마나 남았을지는 모르겠지만 QA로 살아가면서 늘 기억하겠습니다.




​여러분들께서도 QA로 살아가면서 인상 깊었고 기억하고 싶으신 분들이 있으신가요?
부족한 글이지만 긴 글 읽어 주셔서 감사드립니다.
다양한 도메인에서 활동 중이신 QA분들, 늘 파이팅입니다! ^^

nanumie 19-09-06 12:32
좋은 글 잘 봤습니다. 읽으면서 고민하고 있는 부분에 대해 공감되었네요. ^^
Jio QA Life 19-09-06 21:11
재밌게 읽어주시고 공감해주셨다니 감사드립니다^^
13호 태풍이 북상중인데 주말에 아무 탈 없이 평안한 한주 마무리하시길 바라겠습니다.
파스쿠치 19-09-17 02:15
좋은 글 잘 봤습니다. 비슷한 환경인지라 '나는 어떻게 했을까' 에 대해 다시 한 번 더 생각하게 되네요.
Jio QA Life 19-09-21 16:02
감사합니다^^