Records rather than Memories

기획 의도(명세)대로 게임이 돌아가는지 확인하는 것은 게임QA로서 아주 중요한 일이다. 그런데 때로 게임 내 각각의 시스템들은 기획 의도대로 동작하지만 그것들이 합쳐졌을 때 게임 목적성을 해치게 되는 경우가 있다. 최근 LoL이라는 게임에서 이와 같이 기획 의도의 허점을 파고드는 형태의 플레이 방식이 있다는 글을 보게되어 글을 쓰게 되었다. 사실 LoL에서 일명 '뉴메타'라고 불리며 어느정도 승리 공식처럼 정형화된 플레이 비틀어 새로운 방식으로 챔피언(LoL내 캐릭터)를 사용하는 것이다. 보통 승률에 기반해 챔피언의 효율을 극대화 시킬 수 있는 아이템 선택, 룬 과 같은 최적화 빌드를 사용하게 된다. 즉, 라이엇이라는 회사가 챔피언을 구상할 때 "이런 식으로 사용했으면 한다"와 같은 기획의도가 있는 것이..

미국의 감염병 전문의 Dr. Emily Landon의 코로나 19 관련 연설 코로나 19 사태가 심각해지면서 전 세계적인 문제로 떠오르게 되었다. 여러 코로나 관련 기사를 보다가 한 기자회견에서 전한 연설을 보게 되었다. 많은 사람들에게 중요한 메시지를 전달하려는 자세와 전달력 있는 말이 인상적으로 느껴졌고 몇 가지의 말들은 단순히 코로나라는 문제에만 국한되는 것이 아니라 더 넓은 분야에서 적용될 수 있는 내용이라고 생각하게 되었다. This isn't the life any of us expected and, certainly, there are others who will make much greater sacrifices. And there are many more disappointments to..

개인적으로 여러가지 책과 구글링을 통해 게임 개발에 대한 프로세스와 그 사이에 수 많은 직무들이 결부되고 QA가 어떤 역할을 수행하는 지에 대한 지식을 쌓아왔다고 생각했다. 그런데 게임회사 안에서 알게된 사실 하나는 이러한 것들이 틀린 것은 아니지만 상당 부분 구시대적 유물이된 경우가 많았다는 것이다. 발전하고 있는 게임 프로세스에서 변화가 일어났다. 변화에 따라 프로세스들이 모두 장점만 있는 것은 아니기 때문에 과거 방식으로 돌아갈 수 도 있고 여러가지 방식을 합쳐 새로운 방식이 태어날 수도 있다고 생각한다. 중요한 것은 좀 더 효율적인 방식 즉 비용이 적게 들어가는 방식을 위해 최대한 발전하기 위해 노력하고 있다는 점이다. 워터폴, V-model 등 여러가지 소프트웨어를 만드는 방식에서 한번에 pro..

V-model - 명세화된 기능을 개발자나 시험자 관점에서 검증(Verification)과 유저 관점에서 확인(Validation)을 하는 Test model - 어느 단계에서 발생한 오류인지 추적할 수 있다. - 폭포수 모델의 확장형 - 높은 신뢰성을 요구하는 소프트웨어에 맞는다

블랙박스 테스트(Blackbox Test) - 사용자 관점의 테스트 방법 - 사용자가 소프트웨어, 제품에 요구하는 사항과 결과물이 일치하는 지 확인 Blackbox Test 기법들 Whitebox Test 기법들 - 개발자 관점의 단위 테스트 방법 - 개발자가 코딩 단계에서 로직에 대한 테스트를 수행하기 위해 설계단계에서 요구 사항을 확인 Black Box와 White box 비교

리스크(Risk)는 부정적이거나 기대하지 않았던 결과 혹은 이슈가 발생할 가능성을 의미한다. 고객에게 제품을 제공하는 관점에서 리스크란 해당 고객이 제품에 대한 인식을 경감 시킬 수 있는 모든 문제라고 해석할 수 있다. 테스팅에 있어서 리스크의 수준을 분류하는데 여러가지 방법이 존재한다. - 문제의 발생 가능성(The likelihood of the problem occurring) 복잡성, 개발 정도, 상호관계, 리스크 아이템 크기, 기술 난이도, 개발팀 경험 - 문제로 인한 영향(The impact of the problem should it occur) 유저 취급 중요도, 경제적/안전성 피해, 사용 빈도, 외부적 가시성 리스크 기반 테스팅에서는 이러한 분류를 통해 어느 정도의 테스팅을 수행해야하는지..

spec이란 specification의 줄임말로서 재료, 제품, 디자인, 서비스 등이 만족시켜야 하는 일련의 문서화된 요구사항이다. 즉, 기획서에 적혀있는 요구사항이라고 해석하면 된다. 그렇다면 Sepc in close는 무엇일까? 결론부터 말하면 QA가 발견한 이슈가 명세화된 요구사항 즉, spec에 있으므로 결함으로 여기지 않고 폐쇄한다는 말이다. 명세화된 spec안에 있기 때문에 해당 내용이 글이나 문서화되어 기획서에 기록된다. * spec in close = 기대 결과안에 포함, 해당 예외사항은 허용 spec in close에서 close는 BTS에 등록되는 이슈가 도달하는 최종단계 중 하나이다. 폐쇄된다는 의미인데 일단 이슈로 의심되면 QA는 BTS에 등록하고 이를 관리하게 된다. 즉, 이슈라고..

크게 개발 프로그램 테스트 / 기획 내용 리뷰 다양한 게임 레퍼런스 조사 - 퍼블리셔, 빌드 전달, 마켓 오픈 관련 커뮤니케이션 - 테스트 수행 외에 기획서 리뷰, 테스트 설계, 케이스 작성, 사후 결함 관리, 유지 보수 - 전반적인 게임 개발과 진행과정에 참여 즉, 개발에서 끝나는 것이 아니라 QA까지 완료했을 때 완성 할 수 있다. 1. 런칭전 전반적인 게임 내 컨텐츠와 시스템 확인, 다양한 기종 테스트 2. 일정 구간 버그가 발생한다면 계속해서 확인하는 경우도 있다. 그것을 보고서로 작성한다. 3. 개발 외에 cs쪽으로도 정보 전달 4. 이벤트 혹은 컨텐츠 기획 및 검토 5. 결제확인 테스트 6. 버그 유저를 확인하고 그것이 무슨 버그인지 어떻게 어뷰징 하는 지 발생 조건을 확인 7. 자사 및 타사..