효율적인 LQA 테스트로 게임 퀄리티 높이기

LQA 테스트

LQA 테스트는 현지화한 내용이 적용된 게임 빌드가 전달되면 시작합니다. 제일 먼저 빌드를 설치해야 합니다. Xbox, PlayStation 등의 콘솔 플랫폼이라면 특정 폴더에 파일을 복사하기만 해도 게임이 실행되는 경우도 있으니 고객사에서 제공해 주는 설치 가이드에 따라 설치를 진행합니다. 모바일 게임은 전달 받은 파일을 모바일 기기 또는 에뮬레이터에 설치합니다. 설치 방법은 고객사에서 제공하는 가이드를 참고합니다.

 

빌드 설치를 마쳤다면 이제부터 게임을 플레이하며 내용을 점검해야 합니다. 처음으로 번역된 내용을 게임에 덧씌운 빌드이기 때문에 꼼꼼하게 살펴보는 것이 무엇보다 중요합니다. LQA 테스트는 최소 2명 이상을 투입하는 것을 권장합니다. 1명은 UI, 아이템, 스킬 등 즉시 확인할 수 있는 내용의 적절성을 검토하며, 다른 1명은 시나리오를 중심으로 게임을 플레이하며 내용의 적절성을 검토합니다. 고객사에서 치트키(cheat-key)가 제공된다면 적극 활용하는 것이 좋습니다. 실제로 아이템, 스킬은 치트키 없이는 전체 확인이 불가능합니다.

UI, 스킬, 아이템 확인

UI는 게임 화면에서 가장 먼저 노출되는 모든 텍스트라고 생각해 주시면 됩니다. 게임이 시작되었을 때 나타나는 모든 텍스트가 정상적으로 노출되는지, 문장으로 처리되어야 할 부분이 단어로 처리된 곳은 없는지, 같은 부류의 텍스트의 스타일은 동일하게 유지되는지 등을 확인합니다. 오탈자를 비롯하여 텍스트 출력 여부, 불필요한 텍스트(게임 코드 등)가 출력되는지도 확인합니다. 텍스트가 지정된 디스플레이 공간을 벗어날 경우는 없는지도 확인합니다.

 

아이템과 스킬 관련 치트키가 있다면 최대한 활용해서 모든 아이템 및 스킬을 불러내어 확인합니다. 특히 영한 현지화 작업일 경우에는 아이템과 스킬의 이름이 여러 수식어로 이루어진 경우가 많습니다. 그로 인해 조합되어 나타나는 아이템/스킬 이름이 부자연스럽거나 말도 안 되는 것처럼 보이는 경우도 종종 나타납니다. 이러한 내용을 발견하면 반드시 텍스트 담당자에게 알려 정해진 조합 규칙에 따라 수정할 수 있도록 해야 합니다.

 

그 외에도 게임 설정 화면, 캐릭터 인벤토리 화면, 맵 화면, 도감 화면(주로 모바일) 등 게임에 등장하는 모든 텍스트를 확인한다는 마음으로 꼼꼼하게 살펴봐야 합니다.

시나리오 부분 확인

1명의 테스터가 게임 UI 부분을 집중 확인하는 동안 나머지 1명은 게임을 직접 플레이하며 플레이 중에 나타나는 시나리오 텍스트를 확인합니다. 오탈자나 텍스트 범위 이탈 등의 문제는 당연히 테스트가 끝나는 순간까지 계속해서 확인해야 하는 부분이며, 시나리오 텍스트 검토자가 가장 중점을 두어야 할 부분은 플레이 중에 확인하는 텍스트가 게임 진행에 방해를 일으키지는 않는지, 해당 언어 문화권의 문화적 감성에 비추어 문제가 될 내용은 없는지, 게임 내 인물들의 존칭이나 기타 인물 관계상 나올 수 없는 어투가 있지는 않은지 등입니다. 실제로 2018년 출시된 Darksiders III(다크사이더스 3)에서는 인물의 관계를 제대로 정립하지 못해 관계상 존댓말을 써야 할 인물에게 반말을 사용하거나 그마저도 존댓말과 반말을 번갈아 가며 사용하는 등의 오류가 수정되지 않은 채 발매되어 많은 한국 게이머들의 빈축을 산 일이 있습니다. 내가 진행하는 프로젝트에서 이런 일이 발생하지 않도록 단순 오역 여부 뿐만 아니라 각 등장인물의 관계도 주의깊게 살펴보는 것이 좋습니다.

LQA 테스트 보고서 작성

LQA 테스트 과정에서 발견된 버그(bug)는 모두 하나의 보고서 파일에 저장하여 고객에게 제출합니다. 보고서 양식의 제한은 없지만 다음과 같은 내용을 포함하고 있어야 합니다.

 

버그 번호(bug No.)

테스트는 여러 사람이 동시에 진행하기 때문에 각 버그별로 번호를 부여하여 관리하는 것이 좋습니다.

 

텍스트의 고유 번호(string ID)

버그가 발견된 텍스트를 실제 게임 텍스트 파일에서 찾아보면 해당 텍스트를 가리키는 고유 번호(string ID)를 찾아볼 수 있습니다. 이 고유 번호는 모든 텍스트마다 오직 1개만 존재하기 때문에 텍스트를 구분하는 용도로 사용합니다. 실제 작업을 진행하다 보면 번역 내용은 같지만 고유 번호가 다른 텍스트를 많이 볼 수 있습니다. 반드시 고유 번호를 기재해 두어야 이후 확인 과정에서 엉뚱한 추가 오류가 발생하는 것을 방지할 수 있습니다.

 

소스 텍스트의 내용(source text)

버그가 발견된 텍스트의 원본 내용을 기록합니다. 해당 버그가 원문에 대한 오역일 수도 있으므로 항상 원문을 수록하여 수정한 번역문과 비교할 수 있게 준비합니다.

 

현재 타겟 텍스트의 내용(target text)

버그가 발견된 텍스트를 그대로 기록합니다. 버그를 수정한 버전과의 비교를 목적으로 하는 것이니 반드시 수정 전에 복사해서 기록해 두는 습관을 들이는 것이 좋습니다.

수정한 텍스트(revised text)

발견된 버그를 수정한 텍스트를 기록합니다. 문장이 길다면 수정한 부분의 내용을 빨간색으로 표시하여 가독성을 높여 주는 것이 좋습니다.

 

관련 코멘트(comment)

수정한 이유를 기록합니다. 단순 오탈자를 발견하더라도 가급적 코멘트를 남겨 주십시오.

 

오류 범주(error category)

발견된 버그가 어떤 범주의 오류인지를 기재합니다. 일반적으로 분류하는 기준은 오탈자(typo), 태그 오류(tag error), 오역(mistranslation), 스타일(style), 기능(function) 등이 있습니다. 테스트 관계자의 재량에 따라 분류 카테고리를 좀 더 세부적으로 지정해도 괜찮습니다.

 

버그 재확인 방법(repro step)

해당 버그를 발견한 방법을 기록합니다. 테스트 과정에서 발견한 버그는 해당 버그 내용을 수정한 새 빌드가 제공되면 발견할 때와 동일한 방법으로 추적하여 모든 내용이 적절하게 수정/반영되었는지 확인해야 합니다. 따라서, 이 부분을 정확하고 자세하게 기록해 놓아야 버그를 수정한 새 빌드가 나왔을 때 다시 확인하는 과정에서 고생을 덜 합니다.

 

최종 수정일(fixed date)

버그 수정이 제대로 된 것을 확인했다면 확인한 날짜를 기록하여 해당 버그가 수정 완료되었음을 나타냅니다.