테스트 이전의 테스트
버그의 탄생
버그 수정을 확인할 때는 항상 수정 지점과 원인을 파악하려고 애쓴다. 여기서 애쓰는 건 수정한 담당자의 답변을 듣기 위해 노력하는 것을 말한다. 그래야 같은 문제를 반복하지 않기 때문이다. 이 원인에 따라 기획서 수정, 기획 변경이 될 수 있다. 또한 버그의 종류를 확장해 보면 이 기획이라는 지점이 선명해진다. 버그 리포트의 타입은 '버그'도 있지만 문의, 피드백(건의, 검토) 등도 있다. 명확하지 않은 기획이 있거나 버그로 보기 애매하거나 또는 피드백이 반드시 반영되는 경우를 말한다. '설계에 대한 기획'은 전자는 게임 기획에 대한 이야기이고 후자는 테스트 준비 단계이다. 바꿔 말하자면 테스트의 시작은 설계 검토이고 테스트를 기획하는 단계다.
설계는 단순한 문서가 아닌 사고 구조
세상에 수많은 기획서는 '어떻게 사고했는가'에 대한 결과물이다. 기획자는 다른 게임의 레퍼런스를 가져오거나 예시 이미지, 영상 등을 첨부해 둔다. 규칙을 상세히 정하고 각 담당자들이 어떻게 개발하면 될지 설명한다. 지금까지 2개 회사에 있었지만 QA가 보기 좋은 기획서는 많이 못 본 것 같다. 그도 그럴 것이 개발에 초점이 맞춰져 있기 때문이다. QA가 설계를 바라보는 관점은 '테스트 가능성'이다.
사고 구조를 정리하기 좋은 방법은 하나의 요약본을 만드는 것이다. 기획서를 그대로 테스트 케이스로 옮기다 보면 적절하지 않을 때가 있다. 예를 들어 미니카 조립 설명서가 여기 있다. 기획자가 조립 방법과 작동 방법을 적어둔 것이다. 일반적으로 이건 개발자가 보고 만들기 위함이다. QA는 이 미니카가 지면 상태에 따라 잘 가는지, 코너링은 어떤지, 다양한 충돌 상황에서는 대응이 되는지 등 확인한다. 그러므로 우린 이걸 테스트에 맞게 변경시킬 필요가 있다. 기획서를 QA 관점에서 재구성하면 테스트에 무엇이 필요하고 빠졌는지 알 수 있다.
QA 사전 검증
Shift Left라는 말이 있다. 꽤 전에도 유행했던 내용인데, QA 관점에서는 보다 앞선 단계에서 검증을 시작한다는 의미다. 정통적으로는 개발이 완료되거나 혹은 그에 가까운 상태에서 QA를 시작한다. 앞서 언급한 개념은 보다 앞에서, 기획 단계에서부터 함께하는 것이다. 이건 이상적으로 바람직하지만 회사 상황에 따라 무조건 적용할 수는 없다. 물론 전 직장도 현직장도 기획팀이 하는 테크 리뷰는 항상 들어가서 들었다. 때에 따라 기대 동작에 대해 질문하곤 했다. 다만 실제로 구현되는 과정에서 얼마든지 상황은 달라질 수 있다. 현실 세상이 의도대로만 흘러가지 않는 것처럼 말이다.
그럼에도 초기에 버그를 잡아낼수록 후반부에 들어가는 시간적, 인적 자원을 줄어든다. 깊이 관여는 하지 못하더라도 기획 및 개발 과정을 추적해야 하는 이유다.
설계는 결국 함께 만드는 일
개발자는 동작을, 기획자는 의도를, QA는 결과를 본다. 같은 화면도 다르게 보인다. 하나의 영화도 라이트 팬과 마니아, 평론가, 배우, 감독이 보면 서로 다른 것들이 보이는 것처럼 게임을 만드는 과정도 그렇다. 결국 하나의 게임은 다양한 사람들이 이해의 간극을 줄여나가는 과정이다. 때론 사용자의 편의가, 때론 개발 구현 과정에서 경제성이, 때론 중요도에 따라 처리되는 과정이 매번 다르다. 이때 여러 사고가 겹치고 나뉘며 합의된다.
질문의 깊이
커뮤니케이션 능력은 여기서 발휘된다. 설계에 대한 기획은 질문으로 시작한다. 본격적인 QA 진행 전 필요한 명령어, 테스트 환경 등 요청하고 명확한 기획 동작, 기획에는 없지만 고려가 필요한 지점을 정리하여 담당자들에게 전달해야 한다. 결국 하나의 게임 설계는 단순한 문서가 아니라 대화 속에서 완성된다. QA는 품질을 지키려는 태도와 그걸 이루고자 하는 사고의 깊이가 중요하다.