‘테스트 케이스’로만 테스트하면 안되나요?

안전하고 안심할 수 있는 게임을 만들고 싶어

게임은 소프트웨어 프로그램 중에서도 특히나 여러가지 요소가 유기적으로 작용하는 아주 복잡한 콘텐츠다. 그만큼 엮어진 부분들이 많기 때문에 버그도 많이 발생하는 편이다. 슬프게도 테스트를 통해 찾는 버그도 매우 많지만 그만큼 찾지 못하는 버그도 꽤나 많다. **‘버그가 없는 것이 아니다. 다만 발견하지 못했을 뿐이다.’**라는 말이 있듯이, 게임과 버그는 떼려야 뗄 수 없는 애증의 관계가 아닐까 싶다.

개인적으로 가장 행복한 상황을 생각해 본다면 모든 기능이 정상 동작하는 것과 CS 버그리포트가 들어오지 않는 것이다. 하지만...

테스트할 땐 문제없더니 프로덕션에 릴리즈 하기만 하면 버그가 빵빵 터지는 빌드도 있고 갑작스러운 서버 이슈, 데이터 누락 같은 예상 못한 문제가 왕왕 발생한다. 심지어 어떻게 한거지 싶을 정도로 기상천외한 버그 사면초가에 빠진 CS 리포트를 보면서 ‘아, 완벽한 테스트는 거의 불가능하구나…’ 라는 것을 느낀다.

하지만 현실이 이렇다고 해서 게임 서비스를 포기할 수는 없다. 그러므로 우리가 게임을 통해 유저들에게 좋은 경험을 선사하려면 QA팀은 항상 일정 수준의 품질을 보증해야 한다. 그래서 나는 우리가 유저들에게 **“우리 게임은 안전합니다! 안심하고 플레이하십시오!”**라고 자신있게 이야기하는 방법에 대해서 한번 고민해 보려고 한다.

완벽한 문서들로 구원받을 수 있을까?

게임 콘텐츠는 기획을 통해 만들어진다. 예를 들어 새로운 쿠키를 출시하기 위해 기획팀이 기획서를 만든다고 가정하자. 다양한 세부 기획까지 만들어야 하기 때문에 몇날 며칠을 열심히 기획한다. 일주일 후에 잔짜잔!! 드디어 부족하거나 넘치는 부분도 없고 누락된 곳도 없는 완벽한 기획서가 탄생했다. 기획팀이 뿌듯한 마음으로 기획서를 프로젝트 팀 내부에 공유해 준다.

그러면 기획서가 완벽하게 나왔으니 QA팀이 일할 차례다. 이 기획서들을 바탕으로 테스트 케이스(Test Case, TC)를 꼼꼼하게 작성한다. QA 엔지니어가 몇일 동안 신나게 테스트 케이스를 작성하고 수백개의 항목이 나열된 TC를 보며 흐뭇한 미소와 함께 나지막이 혼자 말한다.

크~ 완벽한 기획서로 만든 꼼꼼한 테스트 케이스니까 케이스 수행만 정확하게 하면 완벽하게 테스트 되겠네. ㅎㅎㅎ

답은 그렇지 않다이다.

음? 완벽한 기획서랑 테스트 케이스가 있는데 왜 테스트 결과는 완벽하지 않을까?

그건 우리가 Happy Path의 오류를 범하고 있기 때문이다.

‘행복’의 위험성

먼저 Happy Path Testing이라는 개념을 조금 짚고 넘어가야 할 것 같다. 직역하자면 행복 경로 테스팅이다. 이 개념은 테스트 결과가 반드시 통과이거나 통과할 것이라 예상하는 기능을 테스트하는 것인데 정상적인 결과값이 반드시 나와야 하는 핵심 기능에 대해 테스트할 때 이 개념이 사용된다. 한번쯤은 들어 봤을 All-Pass Scenario, Positive Testing과 비슷하다.

어쨌든 말만 들어서는 왠지 좋은 의미 같아서 문제 없을 것 같은 느낌이 든다.

그런데 이 개념은 무시무시하게도 다음과 같은 가정을 깔고 시작한다.

단, (환경, 조건, 입력 값, 사용자) 등의 변수가 가장 이상적인 상태일 때만

그렇다. Happy Path Testing이란 **‘모든 외부 변수나 조건들이 정상인 상태에서, 기능들이 정상적으로 동작하는지를 확인하는 것’**이다. 여기서 정상적인 상태란 이해관계자들과 유저, 그리고 기획팀이 설정한 이상적인 기준을 의미한다. 쉽게 예를 들자면 기획, 개발, 서버, 데이터, 밸런스가 누락 및 실수 없이 우리가 생각한대로 100% 잘 반영되고 게임 외부의 환경이 완벽한 상태에서 테스트를 진행한다는 것이다. 이렇게 완벽한 상태라면 버그가 있을수 없다.

그래서 QA팀이 집중적으로 테스트가 필요한 순간에 이런 생각을 가지고 테스트하면 매우 위험하다. 이는 Happy Path Testing이 다음과 같은 위험성을 내포하기 때문이다.

1. 게임 외부 환경 변수를 무시한다.

• 모바일 디바이스는 그 종류와 성능이 매우 다양하다. 만약 성능이 너무 낮거나 특정 칩셋에 오류가 있다면?

• 각 나라별로 서비스하는 통신사의 통신망은 속도와 환경, 품질이 천차만별이다.

• 유저가 사용하는 디바이스의 용량이 부족해서 오류가 생길 수도 있다.

• 각 OS별로 발생하는 알려진 이슈(Known-Issue)를 파악하지 못했다.

2. 예측하지 못한 유저의 사용 패턴 및 반응을 고려하지 않는다.

• 모든 유저가 게임 내 기능을 우리 의도대로 사용하지 않는다.

• 게임 외적으로도 그렇다. 모바일 게임이지만 모바일 디바이스로 플레이 하지 않는다면?

• 기능상 허점을 이용해서 어뷰징(Abusing), 크래킹(Cracking)을 하는 못된 유저들도 존재한다.

• 우리가 좋다고 생각한 기능이 유저들에게 항상 좋은 결과를 가져다 주는 것은 아니다.

3. 사람이 항상 완벽하게 일을 처리할 것이라 가정한다.

• 코드에 오타가 생겨 버그가 생길 수도 있다.

• 데이터 작업 시 빈 값, 엉뚱한 값을 넣을 수도 있다.

• 깜빡하고 데이터를 반영시키지 않을 수도 있다.

• 실수로 잘못 눌러서 반영하면 안되는 데이터가 반영될 수도 있다.

• 파일 이름을 잘못 설정해서 값을 불러오지 못할 수도 있다.

일반적인 테스트 케이스는 기획서를 기반으로 재현 조건과 기대 결과를 도출하여 기대 결과가 정상적으로 출력되는지 확인하는 Positive Test에 가깝다. 그렇기 때문에 정상 범주 밖에서 발생하는 버그에 대해서는 테스트 케이스로 보증하지 못한다. TC 자체가 Happy Path의 위험성을 그대로 가지고 있다는 뜻이다.

물론 일부러 비정상적인 상황들을 케이스화 하여 테스트하는 Negative Test 같은 반대되는 테스팅 기법도 존재한다. 하지만 비정상 상황은 너무 다양하기 때문에 모두 케이스화 하는 것은 현실적으로 불가능하다. 또한 게임처럼 잦은 업데이트가 필연적인 콘텐츠는 이런 케이스를 만들기에 인적, 시간적 여유가 부족하다.

“그러면 테스트 케이스를 더 상세하게 쓰면 되는 거 아니에요? ㅇㅅㅇ?”

안타깝게도 기획서와 요구사항은 완벽하지 않을 가능성이 높다. 이건 기획팀이 열심히 일하지 않아서가 아니다. 똑똑하고 꼼꼼한 사람도 복잡한 게임 내 요소들을 전부 고려하기는 힘들다. 그리고 개인 컨디션에 따라 작은 실수도 종종 하기 마련이기 때문에 기획은 허점이 생기고, 허점이 있는 기획을 보고 쓴 테스트 케이스는 그만큼 구멍이 생길 수 밖에 없다.

그리고 테스트 케이스는 쓰는 것만 시간이 드는 것이 아니라 테스트를 수행하는 데에도 시간이 걸린다. 테스트 케이스가 상세하면 상세 할수록 테스트 시간이 오래 걸리고, QA 엔지니어의 피로도가 높아진다. 바쁜 일정 중에 사소한 케이스 수행을 위해서 많은 시간을 할애한다면 테스트 케이스는 충실히 실행했을 지 몰라도 효율성 측면에서는 빵점이다.

그러므로 우리는 시각을 좀 바꿔볼 필요가 있다. 테스트 케이스의 바깥을 한번 살펴보는 것이다.

활발히 개발중인 프로젝트 내 소속된 QA팀의 임무는 ‘잠재적 위험을 제거하여 소프트웨어에 대한 일정 수준의 품질을 보증하고, 사용자에게 최고의 경험을 선사한다.’이다. 잠재적 위험은 TC 바깥의 미지의 세계에 도사리고 있다. 우리가 안전하고 안심할 수 있는 게임을 만들기 위해서는 마음을 굳게 먹고 TC 바깥 세상으로 떠나야 한다.

테스트 케이스에서 탈출하기

테스트 케이스안에서 발생하는 버그의 비율은 과연 얼마나 될까? 대략 0.5% 안팎으로 발생한다. 쿠키런 오븐브레이크 프로젝트는 한 번 업데이트에서 대략 200건 안팎의 버그가 발생하는데 그 중에서 TC로 확인한 버그는 1~2건이 채 안된다. 게다가 이런 버그들은 대부분 빠르게 수정이 가능해서 프로덕션 환경까지 버그를 가지고 가는 경우는 극히 드물다.

이는 대부분의 버그가 테스트 케이스 바깥에서 발생한다는 것을 반증한다. 그렇기 때문에 만약 QA팀이 TC안에서만 웅크리고 있다면 게임을 온실속의 화초처럼 키우는 꼴 밖에 안된다. 바깥세상은 험하고 냉혹한데 세상물정 모르고 자란 게임이 바깥에 나가면 탈이 날 수 밖에 없다.

그러면 TC밖으로 떠나야 한다는 것은 알겠는데, 어떻게 떠나야 할까? 예전에 내가 공유받은 재미있는 이야기가 있다. TC밖으로 떠난다는 게 어떤 건지 쉽게 알 수 있다.

한 QA 엔지니어가 술집에 들어왔다.

먼저 맥주를 주문한다.

그 다음 0개의 맥주를 주문해본다.

999999999999개의 맥주도 주문해본다.

맥주 대신 도마뱀도 주문해본다.

-1개의 맥주도 주문해본다.

'ㅕ댜츄ㅏ너옹'도 주문해본다.

드디어 진짜 첫 손님이 술집에 들어와서 이렇게 물었다.

“화장실이 어디에요?”

그러자 술집이 불에 휩싸여 모두가 죽고 말았다.

우리가 TC를 떠난다는 것은 맥주를 주문하는 기능에서 도마뱀을 주문해보는 생각을 의미한다. 그러나 위 엔지니어는 그럼에도 불구하고 손님이 “화장실이 어디냐”고 묻는 상황까지는 생각하지 못해서 안타깝게도 술집이 불타고 말았다.

이 이야기를 통해 우리가 알 수 있는 것은, 게임의 잠재적 위험을 최대한 많이 제거하기 위해서 우리가 최대한 많이 비정상적인 상황을 생각해야 한다는 것이다. 적어도 내가 테스트 케이스에 적힌 상황 말고 다른 상황도 생각해봐야 하지 않을까? 하는 마인드라도 가져야 한다.

하지만 준비없이 케이스 밖의 상황을 테스트하는 것은 심각한 비효율을 야기한다. 목적 없이 같은자리만 뱅뱅 돌면서 “여기는 문제없음! ㅋ” 이라고 결론을 내리는 실수를 저지를 수 있다. 그래서 TC 밖으로 잘 나가려면 준비를 잘 해야 한다.

QA팀 = 미운 4살

QA직군이라면 탐색적 테스팅(Exploratory Testing)에 대해서 한번쯤은 들어봤을 것이다. 테스터의 경험과 인지능력(Heuristic)을 최대한 활용하여 테스트를 수행하는 것을 의미한다. 일각에서는 ‘기획서와 TC없이 마구잡이로 테스트하는 것’과 같은 부정적인 인식도 있지만 알아차리기 힘든 영역의 버그를 찾는데 매우 유용하다.

탐색적 테스팅을 효과적으로 수행하기 위해서는 ‘목적’이 있어야 한다. ‘내가 어떤 콘텐츠의 어떤 부분에 대한 이슈를 최대한 찾겠다.’와 같이 먼저 목적을 설정해 두고 테스트를 해야 짧은 시간에 질 높은 테스트 결과가 도출된다. 하지만 프로젝트에 처음 들어온 신입 QA 테스터라면 해당 프로젝트의 스펙도 잘 모르고 업무 프로세스도 아직 숙지하지 못한 상태다. 이런 경우에는 어떻게 하면 될까? 아주 간단한 방법이 떠올랐다. 바로 미운 4살 방법이다. 엄마아빠말을 지지리도 안 듣는 4살 아이처럼 모든 케이스에 반대되는 행동을 해보면 된다. 예를 들자면 이런 식이다.

케이스 1 : 튜토리얼 도중 점프 버튼 터치 가이드 출력 시, 점프 버튼을 터치

미운 4살 : 반대로 슬라이드 버튼을 터치

케이스 2 : 튜토리얼 도중 슬라이드 버튼 터치 가이드 출력 시, 슬라이드 버튼을 터치

미운 4살 : 버튼을 터치하지 않음

케이스 3 : 당근푸딩 트램폴린 보물의 능력발동 쿨타임 완료 후 구멍에 빠지기

미운 4살 : 쿨타임 완료 전 구멍에 빠지기

미운 4살 : 쿨타임 완료 후 구멍에 빠지지 않기

케이스 4 : 다이노사워 쿠키 능력발동 시 상단에서 생성되는 고기 젤리를 획득

미운 4살 : 고기젤리를 일부러 획득하지 않음

이렇게 각 케이스마다 반대되는 행동을 하는 것이, 탐색적 테스팅의 방향성을 설정할 수 있는 가장 쉬운 방법일 것 같다. 물론 모든 케이스에 반대되는 행동이 존재하는 것은 아니지만 TC 바깥으로 벗어나는 첫걸음으로서는 나름 간편한 것 같다.

그럼 미운 짓을 좀 해보았으니 더 미운 짓을 해볼 차례다. 바로 테스트할 때 트롤링(Trolling)을 해보는 것이다. 트롤링은 게임의 진행을 일부러 방해하거나 의도와 반대되는 행동을 하는 것을 의미한다. 선량한 게이머들에게는 치가 떨리는 행동이지만 버그와 예외상황을 찾는 데에는 유용하다. 다만 이 트롤링이라는 단어가 테스팅과는 좀 어울리지는 않는 개념이라 약간의 거리감이 있지만 쉽게 이해하기 위해서 적절하다고 판단된다. 마찬가지로 몇 가지 예를 들어보자.

튜토리얼이 너무 길어 짜증나서 게임을 껐다가 켜본다.

튜토리얼 중 지정된 터치영역을 제외하고 나머지 영역을 전부 눌러본다.

상품결제 직전에 급하게 취소버튼을 누른다.

버튼 2개를 동시에 눌러본다.

로비와 게임 리스트 화면을 빠른 속도로 왔다갔다 해본다.

핸드폰 용량을 꽉 채운 상태에서 게임을 다운로드 해본다.

다운로드 도중에 Wifi에서 LTE로 변경해 본다.

게임에서 트롤링의 악의성이 짙지만, 테스팅에서 트롤링은 악의성보다는 다양성에 중점이 맞춰져 있다. 내가 현재 테스트하고 있는 기능에서 최대한 다양한 비정상 상황을 연출해 내는 것이다.

또 다른 방법으로 페르소나(Persona)를 이용하는 방법이 있다.

단어가 참 거창하지만 그냥 역할놀이라 생각하면 쉽다.

야자 시간에 몰래 게임하는 학생이라면?

일이 너무 바빠 게임을 켜두고 일하는 직장인이라면?

성격이 너무 급해서 1초 이상 못 버티는 사람이라면?

아무거나 눌러보는 어린 아이라면?

시간, 돈, 신분 등의 요소들은 유저에게 영향을 끼치기 때문에 각 사용자들은 다양한 사용 패턴을 가지고 있다. 따라서 페르소나를 씌워 **'내가 저런 상황에 처했다면 어떻게 행동했을까?'**에 대해 생각해보면 놀랍게도 생각지도 못한 다양한 상황들을 머릿속에 그려내 볼 수 있다. 다만 QA 엔지니어가 모든 상황을 전부 설정할 수 없다는 한계점은 분명히 인지해야 한다.

마치며 : 그렇다고 테스트 케이스를 버리지는 말자

지금까지 테스트 케이스 외 영역을 탐색해야 하는 이유에 대해 알아 보았다.

하지만 테스트 케이스는 여전히 중요한 문서다. 이는 테스트 케이스가 상위 방향성을 가리키는 나침반이자 기준점 역할을 하기 때문이다.

기획서는 “우리는 이쪽 방향으로 나아갑시다!” 같은 지침서다. 우리가 올바른 방향으로 나아가고 있는가를 검토하기 위해서는 이 지침서로 만든 테스트 케이스가 필요하다. 따라서 게임이 아닌 일반 소프트웨어의 경우에는 고객 또는 이해관계자의 요구사항인 인수 기준(Acceptance Criteria)이 제품에 제대로 반영되었는지 확인하는 인수 테스트 절차를 밟기도 한다.

또한 테스트 케이스 없는 테스트는 테스트가 미궁에 빠질 확률을 높인다. **‘테스트 케이스 바깥’**이라는 표현을 쓰는 것은 기본적으로 테스트 케이스가 있어야 한다는 것 의미한다. 그래서 기대 결과 값을 기준으로 기대하지 않은 결과를 판단할 수 있다. 테스트를 통해 무언가 결과값을 얻었어도 이게 맞는건지 틀린건지 알 수 없다면 테스트 결과의 신뢰도가 매우 하락할 것 이다. 이 밖에 TC는 새로 프로젝트에 합류한 신규 QA 엔지니어에게 세부 스펙을 알려주는 교육의 기능과 정량적인 테스트 결과를 도출할 수 있게 해주는 도구로도 사용된다. 이처럼 순기능도 많기 때문에 테스트 케이스를 멀리 하는 것은 옳지 않다.

테스트 케이스를 사용하는 것과 테스트 케이스를 벗어나는 것은 어떤 방법이 더 옳은가를 판단하는 것이 아닌, 각자가 사용되는 영역과 기능이 다름을 알고 시작해야 한다. 이 두가지를 적절히, 조화롭게 사용하면 우리가 그토록 바라던 **‘안전하고 안심할 수 있는 게임’**을 만들어 유저들에게 최고의 경험을 선사하게 될 것이다.