NDC Replay

게임QA 실무에 적용할 수 있는 테스팅 기법과 패턴 활용
황우람
넥슨 네트웍스
현재 넥슨 유럽FPS게임 QA업무를 담당하고 있음. <br/>과거 테일즈위버, Ncsoft 웹보드 게임 및 소셜 게임, 마비노기2 프로젝트에 QA로 참여하였음. QA경력은 6년 정도
게임 QA에 적용할 수 있는 다양한 테스팅 기법들을 알아보고 이를 바탕으로 실무에 적용한 사례를 통해 테스팅 이론이 QA업무 성과에 어떤 영향을 줄 수 있는지 고민해본다.<br/>앞서 제시한 사례들은 일정한 패턴이 있음을 발견할 수 있다. 이러한 패턴을 미리 분석하고 테스팅 전략에 반영한다면 보다 효과적인 리스크 예방 활동이 가능할 것이다.
[새 창에서 슬라이드 보기]
먼저 QA 세션에 이렇게 많은 분들이 오실 줄은 정말 상상도 못했는데, 다들 QA 종사자 분들이신가요? 혹시? 이번 주제는 제목만 딱 봐도 너무 재미없을 것 같고, 딱딱한 주제일 것 같은데요. 예상 외로 많은 분들이 오셔서 조금 당황스럽네요. 하지만 25분이라는 짧은 시간 동안 집중해서 들어주면 졸리더라도 아마 하나라도 얻어가는 게 있지 않으실까? 짧은 시간이니까 조금만 참아주시길 부탁 드리겠습니다. 그럼 발표를 진행하도록 하겠습니다. 먼저 오프닝 들어가는데요. 이 그림 혹시 보신 분 계신가요? 보시면 개발자랑 디자이너랑 프로젝트 매니저, 그리고 QA. 이렇게 나와있죠? 제가 QA 직군이다 보니까 시간 관계상 QA에 관련된 것만 보고 넘어가도록 하겠습니다. 개발자가 봤을 때 QA는 뭐든지 다 때려 부시는 사람으로 묘사가 되어 있고요. 디자이너가 봤을 때 QA 한량처럼, 할일 없어 보이는 것처럼 묘사가 되어 있습니다. 그리고 프로젝트 매니저의 경우에는 세관 공사하는 사람처럼 까칠한 인상을 심어주고 있는 것 같고요. QA가 봤을 때 QA는 슈퍼 히어로. 최고죠. 그래서 아마 말이 필요 없는. 이런 식으로 묘사가 되어 있는데, 이 이유가 뭘까요? 제가 생각했을 때 이것은 자기가 갖고 있는 직업관에 대한 로망과 다른 직업관에 대한 편견 때문에 이런 일들이 발생한다고 생각하고요. 이런 게 계속 쌓이게 되면 결국 프로젝트가 성공하기 쉽지 않겠죠. 한번쯤 생각해 보시라고 이런 오프닝을 준비했습니다. 이 세션에서 얻을 수 있는 거를 본격적으로 말씀을 드리면, QA 담당하시는 분들은 이론이 바탕이 된 테스트 기법이나 패턴 도입 예시를 참고하셔서 자기 실제 프로젝트에도 한번 적용해보고 자신감을 획득하셨으면 하는 게 가장 큰 목적이고요. 그 외 다른 직군 분들은 우리 게임에 대한 QA들이 잘 하고 있는가? 이런 기법들을 쓰고 있는가? 이런 패턴에 대해서 알고는 있는가? 정도 아시고, 업무 이해도를 높이고 신뢰도를 확보하는 데 목적을 두시면 될 것 같습니다. 이런 오해는 이제 그만 받았으면 좋겠네요. 오늘 할 이야기는 앞서 말씀 드렸던 내용과 조금 비슷하긴 한데요. 이론이 바탕이 된 실무 적용 사례를 적용하게 되면 설득력과 신뢰도를 높이는 거는 상식이죠. 하지만 아쉽게도 소프트웨어 테스팅 관련 사례는 많은데 게임 QA에 적용된 사례를 찾는 것은 쉽지 않습니다. 그래서 조금 지루할 수도 있는 방법론 및 결함 패턴을 여러 가지 사례를 중심으로 소개하고 함께 생각해 보도록 하겠습니다. 발표자 소개를 잠깐 해드리자면, 이건 제 팀원 분이 그려주신 건데 좀 닮았나요? 영혼이 없는 답변 감사합니다. 제 메일 주소고요. 제가 담당했던 프로젝트를 잠깐 소개 드리자면 Zera 라고 혹시 아세요? 2006년에 BIG3로 주목 받았던 게임. 그리고 테일즈위버. 지금도 아직 서비스하고 있죠. 그리고 NC soft에서 장기, 드래고니카, 캐주얼 RPG 게임, 페이스북 게임까지도 했었고, 이건 다 아시는 게 마비노기2 QA를 담당 했었고요. 아쉽게도 접혔는데… 그리고 작년 3월부터 지금까지는 넥슨 유럽에서 서비스 중인 FPS 게임 QF를 담당하고 있습니다. 목차인데요. 이미 여기까지 진행 했고요. 3번부터 설명 드리자면 테스트 기법 적용 사례 그리고 패턴 분석인데, 이 두 가지가 가장 중요한 핵심이 되는 부분입니다. 졸지 마시고 두뇌 풀 가동하시기 바랍니다. 그리고 성과 및 회의, 마치며, 참고 문헌, Q&A. 아무래도 사례 중심으로 다룬 주제다 보니까 질문이 좀 많이 있을 거 같은데요. 질문 되게 환영하는데 25분이라는 거 아시고 빨리 하셔야 된다는 거. 테스팅 기법 적용 사례 들어가도록 하겠는데요. 총 4가지 기법들이 나옵니다. 동등분할 기법, 경계값 분석 기법, 탐색적 테스팅 접근법, 리스트 분석 기법. 이제부터 바로 진지해질 텐데, 터키 CSO에 적용한 사례인데요. 1레벨부터 10레발까지는 듀얼 베레타를, 11레벨부터 20레발까지는 데저트이글. 21레벨부터 30레발까지는 AWP. 이렇게 되어 있죠. 그리고 최소 레벨은 1이고 최대 레벨은 30. 글이 잘 이해가 안돼서 바로 표로 알기 쉽게 담아 봤습니다. 구간을 나누고요. 3레베링 경우에는 당연히 듀얼 베레타를 받는 거고, 15레벨일 경우에는 데저트이글을 받겠죠? 그리고 24레벨일 경우에는 AWP. 되게 쉬운 내용이죠. 같은 구간 내에서는 어떤 값을 대입하더라도 결국 결과는 같다. 이게 동등분할 기법이고요. 생각보다 어렵지 않고 되게 단순한 내용입니다. 같은 예제를 가지고 경계값 분석 기법을 설명 드리자면, 각 구간 내에 의미 있는 값이 있어요. 1, 10, 11, 20, 21, 30. 이게 가장 의미 있는 값인데, 왜 그러냐면 실제로 이 구간에서 아이템들이 바뀌게 되니까 프로그램을 할 때도 1과 10 관련돼서 그런 숫자를 집어 넣겠죠. 그런데 숫자를 집어넣는 코딩하는 과정에서 오타가 있거나 숫자에 착오가 있어서 다른 숫자를 집어 넣거나 하는 경우가 발생하기 때문에 그런 부분에서, 중간에 결함이 발생할 가능성이 높다. 이거 자체가 경계값 분석 기법이고요. 상당히 쉬운 내용입니다. 이렇게 쉬운 내용이 무슨 기법이냐? 거창하게 얘기하지 마라. 라고 하실 수도 있는데, 사실 1, 10, 11, 20 이런 각 경계가 되는 부분을 경계값 분석 기법을 통해서 테스트 했다고 하는 것은 그 경계값도 마찬가지로 보장을 한다라는 것을 의미하기 때문에 기법이라고 볼 수가 있는 것입니다. 쉽죠? 다들 아마 하고 계실 거에요. QA하시는 분들은. 그런데 만약에 여기서 좀 골치 아픈 문제가 생기죠. 만약 기획자가 이런 얘기를 하죠. ‘레벨 다운을 넣자.’ 또는 ‘특정 기간에만 받도록 하자.’ 보시면 사례를 보더라도 마땅히 떠오르지가 않아요. 아까 말했던 그런 기법들을 바로 적용할 수 있을까? 한번쯤 생각해 봐도 쉽게 적용할 수 있을 것 같지 않죠. 그야말로 혼돈의 카오스입니다. 아이템 중복 수령 여부도 체크를 해야 할 것이고, 레벨이 변경된다거나 그렇게 되면 아이템 받는 게 달라질 테니까요. 그리고 구간을 다시 처음부터 나눠야 된다거나 아니면 전혀 다른 테스팅 기법을 사용해야 한다거나, 아니면 여러 가지 테스팅 기법을 복수로 사용해야 한다거나. 이런 다양한 문제들을 생각해 볼 수가 있습니다. 그래서 단순히 너무 쉽다고 생각할 수도 없는 부분들이 바로 이런 기법의 적용이라는 거 한번쯤 생각해 보시고요. 쉽지 않죠. 다음부터 조금 더 진지해집니다. 탐색적 테스트 접근법인데요. 일반적인 개발과 QA 프로세스는 이렇게 구성이 됩니다. 이 요구 분석. 분석 설계. 상세 설계. 개발 코딩. 이런 식으로 진행이 되고, 마찬가지로 QA도 그에 맞춰서 기획서 확인, 요구사항 분석. 기획서 리뷰, 테스트 계획. 그리고 테스트 설계, TC 작성. 테스트 수행, 결함 리포트, 결과 보고. 이런 식으로 진행이 되는데, 단계적으로 하나씩 진행이 되는 것이 일반적입니다. 물론 다른 모델들도 있죠. 폭포수 모델이라든지, 애자일 개발 모델이라든지 V 모델. 이렇게 여러 가지가 있는데, 시간 관계상 다 다룰 수는 없고 한번씩들 찾아보시고요. 검색하시면 이상한 이미지들이 나오죠. 실제 검색 결과입니다. 폭포수 모델을 치니까 이렇게 나오고. V모델쓰니까 태권V가 나오고. 그리고 탐색적 테스트라고 하면 뭐냐. 일반적인 그런 진행 방식이 아니라 Test Charter랑 Time-Boxing. 그리고 Debrefing. 이 세 가지가 유기적으로 구성이 돼서 계획과 실행을 동시에 진행하는 방식입니다. 설명만 들어서 무슨 말인지 감이 잘 안 오실 것 같은데, 하나씩 살펴보면 이해하실 수 있을 것 같습니다. Test Charter를 먼저 보자면 테스트 목적이 뚜렷해야 하고 테스트 시간이 명확해야 합니다. 그리고 컨텐츠에 대한 추가 설명이나 관련 자료를 기입해도 무방하다고 되어 있는데, 그래서 제가 실제로 CSO 터키에 서비스하기 전에 사용했던 Test Charter를 가져 왔습니다. 그래서 보시면 이런 항목들이 있죠. 계획 세션이라든지 완료된 세션. 그리고 이 자체의 Charter를 구성하는 시간. 그리고 이슈 및 문의, 결함 수. 이런 것들이 다 표기가 되어 있습니다. 그래서 간단하게 charter를 작성하고 목적과 목적을 위한 계획 세션이 있겠죠. 그리고 수행 시간. 70분. 또는 셋업 수행 시간까지 포함된 시간들. 그런 것들 것 나타나 있어야 합니다. Time-Boxing은 쉽게 말해서 몰입 테스트라고 보시면 될 것 같은데요. 그 시간 동안에 집중해서 테스트를 해서 최대한 많은 결함을 발견하는 게 그 목적 중에 하나이기 때문에 다른 업무는 모두 스톱하고 집중해서 테스트를 하는 겁니다. 그래서 전화기도 끄고 한 적도 있고요. 보시면 뒤에 미인이 와있더라도 계속 그냥 시간이 맞춰서 테스트를 진행하는 이런 집중도가 필요한 테스트라고 보시면 될 것 같습니다. 그리고 Debriefing은 그냥 요약 보고인데요. 간단히 말씀을 드리면 Debriefing에 꼭 필요한 요소들은 이런 것들이 있는데, 요소들을 다 충족할 필요는 없고요. 보고 자체는 간단한데 결과를 보고하는 것이기 때문에 이 요소 중에 일부를 채택해서 사용하시면 될 것 같습니다. 그래서 실제로 저희가 썼던 Debriefing의 일부는 이와 같습니다. 그래서 테스트 결과에 대해서 간단하게 언급를 하고, 버그는 어떻게 처리했는가? Defaulting을 하였는가? 그런 것들을 간단하게 설명하고, 그리고 앞으로 수행해야 할 것들, 테스트하지 못한 것들 것 대해서 언급하고 또 넘어가면 되는 것입니다. 그래서 이 자체를 하는 데에 그렇게 시간이 많이 들지 않는 거고요. 요약 보고이기 때문에 요약 보고를 작성하는 시간 조차도 상당히 짧습니다. 2분에서 3분정도면 다 쓰겠죠. 그렇게 탐색적 테스팅 접근법을 사용해서 2주간 테스트를 해봤더니 클랜 시스템 외에 칭호, 난입, 팀전 등 각각 컨텐츠들이 있죠. 그런 컨텐츠들을 테스트할 대상으로 선정하고 반복 숙달을 했습니다. 했더니 명세 기반 테스팅 기법. 앞서 말씀 드렸던 일반적인 프로세스에 진행된 테스팅 기법을 보완하는 역할을 하더라. 라는 것을 깨닫게 되었고, 이것에 대해서 조금 뒤에 성과 및 의의에서 다시 한번 확인하실 수 있습니다. 벌써 졸리시는 분이 계신 것 같은데, 조금만 더 참아주시고 이제 끝판왕이 나옵니다. 기법 중에서 마지막으로 다루는 게 리스크 분석 기법인데요. 먼저 주의사항을 말씀 드리면 제품 리스크 자체에만 초점을 맞췄습니다. 그리고 프로젝트 리스크는 독립적으로 관리하는 것이 좀더 효과적이라서 PM과 협의를 통해서 결정하는 것이 더 좋다. 이렇게 이론 상으로는 나와있습니다. 그리고 리스크 아이템 선정 시 혼재하지 않도록 하는 것이 중요한데, 제품 리스크와 프로젝트 리스크에 대해서 잘 모르시는 것 같아서 간단하게 설명을 드리면, 제품 리스크는 그 제품 자체입니다. QA할 대상. 테스트할 대상으로 말하는 거고, 프로젝트 리스크는 그 대상이 갖고 있는 주로 인력 문제라든지 인원 보충 문제라든지 아니면 개발 노하우나 개발 숙련도라든지. 그런 것들이 프로젝트 리스크고요. 그래서 리스크 분석 기법을 제가 사용한 이것은 제품 리스크에만 집중을 했다. 그렇게 알아두시며 될 것 같고요. 다음에 기회를 주신다면 한번 더 할 수도 있고요. 참고하실 내용은 아무래도 터키 서비스라서 현지인 PM 터키에 있고 룩셈부르크에 있고 그러니까 시간 조율이 상당히 어려워서 직접적인 회의라든지 하는 것도 어려워서 사전 협의가 좀 불가했다는 거를 아시면 될 것 같고. 그래서 QA팀 자체적으로 진행하였습니다. 예시로 공개하는 데이터는, 여기 자세한 수치가 보이지 않긴 하지만, 정말로 그렇게 사용한 거는 아니고요. 예시는 예시일 뿐이니까 오해는 하지 말아주시고요. 방법에 대해서만 확실히 이해하시면 될 것 같습니다. 진행과정은 리스크 식별 단계, 리스크 아이템을 선정하고요. 리스크 분석 단계, 리스크 요소, 스케일 선정, 매트릭스 작성. 그리고 리스크 계획 단계, 리스크 전략 수립 단계. 그리고 리스크 추정 단계. 네 가지 단계가 있는데, 하나하나 설명을 드리도록 하고요. 오늘은 세 가지만 설명을 드리고 리스크 추정 단계는 어느 정도 리스크 기반 테스팅의 노하우가 쌓여서 데이터가 쌓인 다음에 할 수 있는 것이기 때문에 일단은 세 단계까지만 보도록 하겠습니다. 먼저 식별 단계인데요. 터키 CSO의 리스크 아이템들을 골라봤습니다. 여기서 말하는 아이템은 장비 아이템, 이런 아이템이 아니고요. 항목을 얘기하는 겁니다. 그래서 어떠한 항목들이 리스크를 갖고 있는가? 그거에 대한 내용이고요. 제품 리스크만 고려했다는 점 다시 한번 말씀을 드리고, 리스크 아이템은 총 21개를 선정하였습니다. 원래 이론 상으로는 최대 35개까지 이렇게 얘기가 있는데, 그거는 프로젝트마다 조금 다르니까. 35개 이상 넘어가버리면 너무 많아서 분석하는 것 자체가 오래 걸리겠죠. 그래서 21개를 선정하였고요. 이렇게 나타낼 수 있습니다. 캐릭터 성장부터 채팅까지. 이렇게 21의 리스크 아이템을 넣어 뒀고요. 분석 단계로 넘어가도록 하면 리스크 요소를 선정해야 되는데, 리스크 요소라고 하면 이것들이고요. 리스크 스케일. 1, 3, 9 이렇게 나와있는데, 이건 표를 보시고 설명하는 게 조금 더 이해가 빠를 것 같아서. 표를 보시면 장애 발상 가능성과 영향력이라는 것이 있습니다. 이것이 바로 리스크 요소 선정인데요. 3개, 3개로 굳이 나눌 필요는 없고 프로젝트마다 유동적으로 바꿔서 해도 상관 없고요. 용어 자체도 프로젝트마다 맞춰서 조금 더 이해하기 쉬운 단어로 바꿔서 해도 상관은 없습니다. 그래서 이런 식으로 나누고, 리스크 스케일을 선정하는데 1, 3, 9라는 숫자. 왜 1, 5 ,9도 아니고 1, 3, 9일까요? 1, 5, 9로 하게 되면 1과 5 사이에 4라는 숫자가 있죠. 4만큼의 차이가 나죠. 그리고 5와 9사이에도 4만큼의 차이가 납니다. 이렇게 되면 리스크 자체가 변별력이 좀 떨어지게 됩니다. 그래서 변별력을 확실히 높일 수 있는 ‘뭐가 리스크가 더 큰가?’ 가 중점이기 때문에 1, 3, 9라는 스케일로 결정하였습니다. 그래서 전체적으로다 표로 수치를 매기고 표를 만들었고, 그 다음에 할 게 리스크 매트릭스죠. 그 매트릭스 작성을 한번 보도록 하겠습니다. 이렇게 CSO 터키에 리스크 요소들의 각 항목들이 이렇게 나와 있습니다. 하나씩 하나씩 다 있거든요. 작아서 잘 안보이실 것 같은데. 21개가 이렇게 나와 있고. 보시면 제일 우측 상단, 1사분면 쪽이겠죠? 그쪽에 있는 것들이 리스크가 되게 높은 것들이고 반대로 0,0 좌표에 가까운 것들이 리스크가 낮은 것들이겠죠. 그래서 이런 식으로 리스크를 분석해서 결과가 나온 데이터를 가지고, 혹시 다음에 뭐할 것 같습니까? 그 다음에 전략을 짜거나 테스트를 어떻게 할 것인가에 대한 고민을 하겠죠. 그래서 영역별 테스트 강도를 정하게 되는데, 방금 말씀 드렸다시피 1사분면쪽이 가장 테스트 강도가 높습니다. 반드시 테스트 해야 할 항목들이죠. 그 항목들에 뭐가 있는지는 표에 보시면 아실 수 있습니다. 그리고 그 다음 부분들은 2사분면과 4사분면이 테스트 해야 함 영역인데요. 영향 쪽으로 가까이 있는 것들이 비즈니스라고 되어 있고, 장애발생 가능성이 가까운 것들이 tech라고 되어있죠. 그러니까 장애발생 가능성이 높은 쪽에서는 개발 테스팅 중심. 그리고 영향력 높은 쪽에서는 인수 중심으로 테스트를 하게 되어 있습니다. 그 부분은 뒤에서 또 설명을 드리죠. 그리고 FTA. 이 부분은 테스트 하지 않을 수 있음. 또는 시간이 나면 자유롭게 테스트를 해라. 이런 영역이 리스크가 가장 낮은 영역들입니다. 그래서 이런 식으로 다 분류를 하고 전략을 짜게 되면 아무래도 조금 더 근거가 있고 효용성도 있고 그렇게 되겠죠? 잠시 돌발 질문이데요. 각 사분면의 경계, 딱 가운데 걸쳐있는 아이템들에 대해서는 어떻게 하는 게 좋을까요? 시간 관계상 제가 답변을 드리면 유관 부서와 협의를 하는 것이 중요합니다. 왜냐하면 이게 하나만 살짝 위로 올라가게 되버리면 반드시 테스트해야 함이 될 수도 있고, 살짝만 내려가 버리면 테스트 안 할 수도 있는데, 이거에 대해서는 어떻게 하는 게 좋을까요? 라고 같은 유관 부서들끼리 상의를 해서 결정을 하면 개발팀이나 PM분이 테스트 해야 될 것 같습니다. 이렇게 의견이 조율되면 테스팅 반드시 하는 거고 그렇지 않으면 안 해도 된다. 이런 식으로 서로 같이 조율을 하게 되는 그런 게 필요합니다. 이제 리스크 기획 단계인데요. 방금 아까 말씀 드렸다시피 인수 중심 리스크 기반 테스팅 전략 예시입니다. 주로 QA들이 하는 것들이 개발 테스팅보다는 주로 인수 테스팅. 주로 CBT나 OBT 이런 거를 대비해서 많이 테스트를 하기 때문에 예시로 인수 테스팅 중심으로 잡았고요. 돌발 퀴즈2 인데 이것도 시간이 너무 없는 관계로 제가 답변을 드리면 아까 말씀 드린 내용 중에 답이 있긴 하죠. 서로 반대가 되면 됩니다. 1, 2, 3, 4 사분면이라고 했을 때, 2사분면과 4사분면이 서로 교차가 되면 장애 발생 가능성이 높은 쪽이 개발 테스트 중심이기 때문에 이쪽이 높은 수치에 맞을수록 더 테스트 강조를 강화시킨다. 4사분면이 되겠죠. 지금 만약 개발 테스트라고 했을 경우에는. 그리고 그림에서 보다시피 2사분면은 대안 흐름을 포함하고 있는데, 4사분면은 기본 흐름만이라고 되어 있죠. 영향력이 높은 쪽이기 때문에, 더 테스트 강도를 높였기 때문에 대안 흐름을 포함했다. 이렇게 이해를 하시면 될 것 같습니다. 숨가쁘게 달려왔는데요. 4가지 테스팅 기법에 대해서 간단하게 정리를 한번 하고 넘어가도록 하겠습니다. 동등분할 기법, 경계값 분석 기법, 작아서 잘 안 보이시긴 하겠지만 기억나시죠? 그리고 탐색적 테스트 프로세스. 그리고 리스크 분석 기법이고요. 이 총 네 가지, 사실은 이 네 가지만 잘해도 그 프로젝트 내에서 어느 정도 안정성이 확보가 된다고 말씀을 드릴 수가 있을 것 같고요. 그리고 패턴 분석으로 넘어갈 텐데요. 네 가지가 있고요. 이건 저희가 사내에서 개인적으로 팀 단위로 분석을 해서 어느 정도 맨날 발생하는 버그들의 일종의 패턴이더라. 이런 걸 발견하고 categorizing 해서 포함된 것들입니다. 그래서 변수 타입 패턴을 한번 살펴보면, 2의 16승 얼마나 될까요? 계산기 돌리시지 마시고. 프로그래머 분들 계시면 아마 바로 답이 나오실 텐데, 바로 이거죠. 이 숫자는 QA한테 상당히 큰 의미를 갖게 됩니다. 왜냐하면 바로 다음 장을 예시로 보시면 아실 거에요. 수수료가 65536원이 넘어가면 아이템이 복사된다. 또는 체력 버프를 계속 받아서 65536이 넘으니까 클라이언트 크래시가 나더라. 또는 한번에 65536의 경험치를 받았더니 레벨업이 아니라 렙따가 되더라. 또는 경험치를 30000을 받아야 되는데 65599.9999… 이런 식으로 실수 패턴에다 처리를 재대로 안 해서 그런 거죠. 이런 식으로 2의 16승, 실수 패턴처리. 변수 탑에 관한 패턴에 대해서 조사를 했더니 너무 많습니다. 이거만 발표를 해도 40분은 할 수 있을 것 같아요. 그래서 이 정도만 확인을 하고요. 변수 타입 관련 패턴은 테스트할 때 반드시 체크를 하고 넘어가야 된다. 이렇게 생각하시면 될 것 같고요. 오늘도 평화로운 경매장. 이건 루리웹에서 제가 발췌를 한 건데요. ‘데이터베이스 관련학과에서 기초라는 말 아님?’ ‘예외적인 입력을 받았을 때 처리하는 것들 중에 저런 간단한 음수입력은 기초중에 기초라는 말이 아닌가 싶은데요’ 계속 기초라는 얘기가 나오죠. ‘대충 정수 값으로 해서 음수값을 입력해도 정수로 피드백을 보내는듯? 멍청하다 진짜’ ‘보통 애당초 특수문자 입력을 막는데 말이지.’ 되게 비웃고 있죠. 이런 버그가 실제로 일어났습니다. 단순히 음수 값을 경매장에 입력을 하면 그 만큼의 게임머니가 바로 생성이 됩니다. 떼부자가 되는 거죠. 이런 기초적인 실수지만 최근까지도 이런 버그가 발생했다는 사실은 QA 하는 입장에서 상당히 충격적입니다. 그래서 이런 음수 예외 처리는 반드시 체크를 하고 넘어가야 된다. 라는 거는 아시면 될 것 같고요. 접속 종료 = 테스트 시작. 이거는 최근에 발생한 버그 중에 하나고요. 아시는 분은 아실 거에요. 기부금을 낸 후 접속을 종료하면 지불한 기부금만큼 추가로 획득되는 버그. 그리고 PC방에서 재접속 시 무한 골드 획득되는 버그. 두 번째 PC방 관련된 얘기는 저도 참 많이 하는 게임인데 PC방을 못 가서 아쉽네요. 어쨌든 이런 게임들은 이런 버그가 발생하면 유저들 입장에서는 상당히 좋죠. 하지만 이런 것들이 쌓이고 쌓이면 결국 게임 자체에 대한 이미지도 좋지 않고, 결국 그 돈도 다 회수해 가거나 치명적인 버그들은 다 유저의 계정 블록이라든지 그런 조치를 다 취하겠죠. 그래서 접속을 종료했다고 해서 테스트가 끝났다고 생각하지 말고 접속을 종료했을 때 바로 다시 테스트를 해봐야 된다. 이런 것도 한번 염두를 해두시면 좋을 것 같습니다. 그리고 Observer나 Specter가 있는데, 이것은 주로 FPS 게임에서 많이 다뤄지는 이슈인데요. 보통 Host/Guest 핑은 충분히 체크가 되지만 Observer나 Specter는 핑 체크가 잘 안 되는 경우가 있습니다. 이건 하기가 되게 쉽죠. 그래서 클라이언트가 Hang 또는 Freezing 이 발생하는 것을 볼 수가 있습니다. 그래서 그냥 클라이언트가 다운되고 그런 것들. 그런 동기화 관련 패턴도 반드시 체크를 해야 된다. 그렇게 아시면 될 것 같고요. 그리고 리소스 관련. 타사 게임만 계속 애기하는 것 같아서 양심 선언을 합니다. 저희 회사 게임인 마비노기도 이런 일이 있었죠. 보시다시피 체형이 다른 캐릭터가 같은 아이템을 공유하게 될 때는 이렇게 그래픽이 깨져버려서 이상한 모양을 하고 있네요. 이런 식으로 되는 버그가 있었고, 인벤토리 체크 누락. 이거는 말씀을 안 드려도 다들 한번씩은 경험해 보셨을 거에요. 상당히 많이 발생하는 버그죠. 그래서 보상 아이템을 지급했을 때 인벤토리 여유 슬롯 체크를 안 해서 아이템 유실이 발생한다거나. 그래서 다 다시 지급을 해줘야 된다거나, 이벤트를 연장한다거나. 이런 것들. 아주 많아서 더 이상 자세한 설명은 생략하도록 하겠습니다. 그래서 리소스 관련 패턴도 확인을 하고 넘어가야 된다. 아시면 될 것 같고, 프로그래머 분들 또는 개발하시는 분들이 생각해 볼 문제인데요. 이것은 사랑, 아니… 코드… 기억하고 있습니까? 잠시 예문을 드리자면 블리자드에서 QA의 중요성을 개발자들에게 체험시키기 위해서 개발자를 실제 CS업무에 투입한다고 한다. 자신이 잘못 짠 코드로 인해 유저가 어떤 피해를 입는지, 그리고 그것이 CS팀에 어떤 영향을 끼치는지 체험하고, 자신이 만든 코드에 더 신경을 쓰게 된다고 합니다. 되게 의미 심장한 얘기죠. 옆에 보시면 코드 리뷰가 나와있는데, 잘 안 보이실 것 같아서 몇 가지만 읽어드릴까요? 함수에서 리턴으로 나가는 곳에서 모든 에러를 적절히 처리하고 있는가? 모든 exception을 재대로 처리하고 있는가? 할당된 메모리를 모두 해제하고 있는가? 이런 것들에 대해서는 코드 리뷰를 해서 미리 체크를 한다면 앞서 말씀 드렸다시피 그런 패턴과 관련된 버그들은 사전에 다 막을 수 있지 않을까? 생각이 들고 저희 QA하는 입장에서도 훨씬 더 효과적으로 QA를 할 수 있지 않을까? 생각이 듭니다. 그래서 코드 리뷰 잘 하고 계신지 한번 생각해 보시기 바랍니다. 이거는 QA 하시는 분들이 다 생각해볼 문제인데요. 영원한 화두죠. 테스트 자동화 어떻게 할 것인가. 말들이 많죠. 예시를 말씀 드리자면 테스트 자동화 안 했을 때 ‘QA팀은 저번 주말에도 출근했던데?’ ‘네. 주말 반납하고 테스트했더니 버그 많아 잡았네요. 이번 업데이트 대박나겠죠?’ ‘그거 그냥 빼는 걸로…’ 암 걸리죠. 사실 지금 웃으시는 분들 다 한번씩 경험한 것 맞죠? 이런 문제가 생기죠. 만약에 테스트 자동화를 했다면, ‘저번 주말에 출근했던데?’ ‘아뇨. 스케줄 예약하고 A에 대한 결함 패턴 분석한 걸로 자동화 돌렸어요. 잘했죠?’ ‘그거 그냥 빼는 걸로…’ 그러시던가. 내가 하는 거 아닌데. 이런 얘기죠. 그래서 테스트 자동화가 잘 되어 있다면 굳이 주말 반납하고 야근까지 하면서 와서 일일이 다 보고 이런 수고를 좀 덜 수 있지 않을까? 그리고 또 하나 말씀 드리는 건 결함 패턴 아까 말 씀 드렸는데, 결함 패턴들과 테스트 자동화를 조금 엮을 수 있지 않을까? 그런 것들에 대해서 한번쯤 생각해 보시면 테스트 자동화 이미 진행하고 있는 부서라든지 그런 분들께서는 한번쯤 생각해 보시면 좋은 결과 있을 것 같습니다. 이제 대망의 결론입니다. 성과 및 의의에 대해서 말씀 드리도록 하겠습니다. 그래서 어떻게 했다는 거냐? 결과를 말씀 드리면 CSO 런칭 2주동안 QA성과인데요. 먼저 런칭 게임 서버다운 횟수가 평균, 제가 지금 경험해본 프로젝트 한해서, 평균 7번정도의 서버 다운을 갖습니다. 그런데 단 한번도 일어나지 않았어요. 그리고 임시 점검 횟수. 임시 점검도 되게 많이 하죠. 런칭하고 나서는. 그래서 보통 9번 정도 하는 것 같더라. 하지만 한번도 일어나지 않았어요. 상당히 큰 의미가 있죠. 0이라는 숫자. 그리고 커버리지는 65%정도 예상을 했는데, 무려 85%를 달성했습니다. 이 20%의 갭은 앞서 말씀 드린 탐색적 테스팅과 리스크 분석의 결과라고 보시면 될 것 같고요. 충분히 많은 효과를 보았다. 자신 있게 말씀 드릴 수 있을 것 같습니다. 마치도록 하겠는데요. 결론을 짓자면 게임 QA 실무에 소프트웨어 테스팅 기법과 패턴을 적용해서 만족스러운 결과를 얻을 수 있는 것을 확인할 수 있었습니다. 이와 같이 이론이랑 결함 패턴을 적용하는 것 자체가 대단하거나 거창한 것이 아니라 체계적으로 연구하고 프로젝트에 맞춰서 최적화 시킨다면 QA업무 완성도 자체를 한 단계 더 끌어올릴 수 있는 훌륭한 도구가 될 거라고 저는 자신 있게 말씀 드릴 수 있을 것 같고요. 그리고 앞에 내용을 참고해서 QA업무 스킬을 향상시키고, 게임 QA에 대한 이해를 바탕으로 모든 분들과 함께 프로젝트를 성공으로 이끌 수 있도록 하기실 바랍니다. 참고 문헌이고요. 책도 좀 많이 넣었어요. 그리고 대망의 엔딩. 작아서 잘 안보이네요. 질문이 되게 많이 올라왔네요. 아까 제가 메일 주소를 알려드렸는데, 개별적으로 문의 주시면 다 답변을 드리도록 하겠습니다. 시간이 너무 없어서 죄송하네요. 고맙습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
