Тестирование локализации в играх: зачем и как
Предположим, у вас есть игра. Она может быть большой или маленькой, компьютерной или мобильной, двухмерной или VR, хардкорной или казуальной. Вы почти закончили ее разработку, протестировали все механики, дизайн уровней, квесты, монетизацию, баланс, звук и в конце концов остались довольны. Настолько, что решили: моя игра довольно крутая, пожалуй, игроки в других странах будут от нее в восторге! Отдали в студию локализации на перевод и озвучение, получили переведенные материалы, интегрировали их в билд, отправили на релиз. Через пару недель рассматриваете пользовательские отзывы и недоумеваете: а что это все так ругаются? А, стоп, вы, наверное, не в курсе, что в вашей игре такое:
Тестирование локализации (локализационное тестирование) — это процесс по комплексной проверке локализованной версии программного продукта на его соответствие рынку целевой страны с учётом её культурных, правовых и других особенностей.
Основные виды проверок при локализационном тестировании:
- Правильность перевода основного контента, элементов интерфейса пользователя, системных сообщений и других текстовых материалов
- Корректность отображения текстовых материалов
- Корректность отображения локализованных элементов интерфейса
- Корректность отображения локализованных графических материалов.
Тестирование локализации — один из последних этапов разработки игры. Бывает так, что издатели пропускают этот этап ввиду отсутствия денег, нехватки времени или иных причин. Иногда локализованный продукт поступает в продажу, не пройдя предварительно этап тестирования перевода и озвучки. Из-за этого в нём может содержаться множество багов. Многие знакомы с подобными печальными примерами, особенно в России.
Подготовка процесса
Как правило, перед началом тестирования разработчик высылает локализаторам вспомогательные данные, позволяющие вникнуть в курс дела:
- руководство по игре или дизайн-документ, описывающий уровни, квесты, миссии и основные игровые механики;
- глоссарий и базу текста;
- скриншоты и видеоролики;
- тест-кейсы и подробные инструкции по запуску игры и активации чит-кодов.
Идиллический сценарий, но так, увы, бывает не всегда. В отдельных случаях (когда дело касается больших проектов), разработчик может выслать саму игровую приставку, на которой будет проходить тестирование, а в других — даже не вспомнить про чит-коды.
Менеджеры проектов согласовывают время, выделяемое на тестирование, устройства и платформы, количество тестировщиков, виды тестирования (функциональное, лингвистическое, маркетинговое). Когда все эти детали утверждены, можно приступать к процессу. Чем больше материалов предоставил разработчик, тем проще тестировщикам сориентироваться в новой игре и быстрее обнаружить все ошибки. Разумеется, не стоит надеяться, что всегда под рукой будет дизайн-документ, тест-кейсы или доступ к консоли разработчика — зачастую в игру приходится вникать без подсказок и наводок, разбираясь в деталях с позиции рядового пользователя (тестирование по принципу черного ящика).
Поскольку билд с ранней версией игры, находящейся в разработке, — информация строго конфиденциальная, для его запуска может потребоваться настройка и подключение специальных программ или доступа по закрытой сети, предоставленной заказчиком. На подготовку этого процесса также требуется дополнительное время.
Системы баг-трекинга и баг-репорты
Основное поле работы тестировщика — это система отслеживания ошибок (или баг-трекер). Они бывают разные, но в целом устроены по одному принципу. Баг-трекеры предназначены для занесения отчетов об ошибках (баг-репортов). Такие отчеты направляются напрямую разработчикам и помогают эффективно решить конкретную проблему.
Пример баг-репорта:
Задача тестировщика — обнаружить в игре все возможные неполадки (баги). Требуется максимально сжато и четко передать шаги воспроизведения конкретного бага, вкратце описать проблему и предложить вариант ее исправления, предоставив скриншот или видео, где зафиксирован спорный момент. Также в отчете может быть указана дополнительная информация: версия тестируемого продукта, платформы или устройства, на которых данный баг был замечен, степень воспроизводимости (reproduction rate) и характер критичности бага (low, medium, high, highest).
Похожие материалы
Тренды игровой индустрии в 2022 году
Баги локализации: найти и обезвредить
Что нужно знать о локализации игр
Субтитры или дубляж, что эффективнее
Что делает китайский рынок особенным
Особенности багов локализации
Localization quality assurance (QA) или тестирование локализации — особый вид тестирования. В первую очередь, это косметическая оценка переведенных текстовых элементов игры, осуществляемая визуально. Чтобы все было ровно, никуда не вылезало, друг на друга не накладывалось и не обрывалось. Правильный текст на соответствующем языке локализации должен находиться в положенном ему месте, отображаться корректно, быть читабельным, правильно сокращаться, следовать глоссарию.
В русской локализации слово на испанском? — Баг. Вместо «Закрыть» написано «Закры»? — Баг. Вместо текста — набор непонятных страшных символов? — Баг. В описании юнита шрифт мелкий настолько, что на экране с диагональю 4 дюйма едва видно, что написано? Печальная история: не совсем баг, но требует обязательного занесения в отчет. Либо дизайнеры поменяют шрифт, либо редакторы сократят перевод.
Во-вторых, тестирование локализации подразумевает лингвистическую оценку, то есть полную вычитку встречаемого в игре текста. Опечатки, пропущенные знаки препинания и пробелы, капитализация букв, отсутствие перевода, неправильный перевод, некорректные сокращения, пунктуация и стиль — на все это необходимо обращать внимание. Тестировщик локализации должен быть немного редактором и переводчиком.
В некоторых ситуациях потребность в составлении баг-репортов отсутствует: когда, например, речь идет о грамматических, пунктуационных ошибках, неточностях перевода или посторонних звуках в аудиофайлах. Тогда, в зависимости, от инструментария, которым он располагает (доступ к базе текста или звуковому редактору), тестировщик может сам внести исправления, скоординировав решение с редакторами или звукорежиссерами.
Для локализации характерен ряд типичных багов, рассмотрим их подробнее:
Untranslated text (непереведенный текст) — тут все просто. Внезапный английский текст в русской версии программы (где его быть не должно), или испанский — в арабской.
Overlap (взаимное наложение) — один блок текста накладывается на другой, создавая нечитаемый сумбур букв.
Truncation (обрывание) — слово или предложение обрезается элементом интерфейса, иконкой, границей экрана.
Misalignment (неправильное расположение) — блок текста смещен вбок, вниз, вверх. Создает эстетически неприятное впечатление, затрудняет восприятие.
Missing text (пропущенный текст) — текст отсутствует в том месте, где должен быть.
No game no test?
Не совсем так. Тестировать локализацию в игре можно и без непосредственного взаимодействия с игрой. Если дело касается озвучки — то тестировщику предоставляется набор аудиофайлов или видеороликов, в которых необходимо проверить качество звука, наличие возможных шумов и неудачно склеивающихся фраз и попадание реплик персонажей в губы (lip sync). А при тестировании мобильных продуктов, программного обеспечения или сайтов, проверку можно осуществлять по скриншотам различных элементов интерфейса, подготовленных заранее. В этом случае даже необязательно, чтобы подготовку скриншотов выполнял носитель языка перевода.
Взаимодействие с командой
В процессе тестирования локализации принимают участие не только тестировщики. Для достижения успешного результата требуется взаимопонимание всех членов команды.
Тестировщик <> Разработчик: лаконичность и детальность. Необходимо максимально просто и эффективно описать шаги воспроизведения той или иной ошибки, без лишних слов.
Тестировщик <> Переводчик: внимательность и знание контекста. Переводчики не всегда видят то, что переводят. Тестировщик имеет доступ к конечному продукту и может сверить перевод с реальными вещами, которые он отображает, а затем сообщить переводчикам и редакторам необходимую информацию для корректировки перевода.
Тестировщик <> Редактор: редакторы правят переводчиков, но тестировщик должен быть готов поправить редактора. Нужно быть доскональным, но не стоит придумывать ошибки там, где их нет.
Тестировщик <> Менеджер проекта (ПМ): поскольку ПМ — основной посредник в коммуникации между заказчиком и остальными участниками процесса, тестировщику необходимо направлять все пожелания и предложения менеджеру проекта в доступной манере, чтобы тот смог донести эту информацию до заказчика.
Как работает QA локализации видеоигр?
Ответ простой: либо работает, либо — нет. И во втором случае результат налицо. Прежде всего, это зависит от желания заказчика-издателя, от того, как составлен план работы по локализации: считает ли он целесообразным выделить средства из бюджета и время на проверку качества отображения текстов в игре, качества озвучки и т. п. А дальше дело за тестировщиками, редакторами и менеджерами проекта. Поскольку, к тому времени, как подошла пора оценки качества локализации, работа переводчиков, актеров озвучивания, звукооператоров и звукорежиссеров уже, как правило, подошла к концу.
Тестирование локализации — это наведение порядка и «уборка» переведенных в игре материалов. Даже если игра является крупным ААА-тайтлом, прошедшим множество тщательных проверок на разных этапах локализации, нельзя быть уверенными на 100%, что в конечной версии где-нибудь в маленьком каверзном окошке интерфейса не оборвется на полбуквы слово, в техническом описании патча не закрадется пара опечаток, а вместо символа кавычек не будут отображаться жуткие элементы кода. Менеджеры проектов и редакторы тоже иногда устают. Не говоря уже про мобильные игры, где окна для размещения длинных русских слов смешного размера, а дизайн интерфейса (и, соответственно, размер окон) может меняться с каждым новым обновлением.
Пользователи (видеоигр и не только) — весьма придирчивая аудитория. Даже пара таких, казалось бы, незначительных помарок может вызвать у них раздражение и нежелание оценивать дальше локализованную версию. Ведь никто не любит гневные отзывы на форумах и комментарии в соцсетях в духе «За что я деньги плачу?!" или «Локализаторы как всегда…». Одно дело, когда игра переведена настолько великолепно, что сплошь состоит из перлов — тогда ее непременно растащат на мемы. Но другое — если над вашей игрой потрудилась действительно команда профессионалов с большим опытом. Но из-за того, что игра не была в итоге протестирована, в релизную версию просочилась парочка, скажем так, не очень приятных моментов. Вот именно, всего пара мелочей — придирчивой публике этого уже достаточно, чтобы потерять доверие к локализаторам.
Финальная вычитка и проверка уже добавленного в игру перевода — не самая сложная операция, гарантирующая вашей игре достойный вид. Согласитесь, всем будет гораздо приятнее, когда проверку качества локализации контролируете вы сами, а не пользователи, купившие игру? А то и правда, как-то не очень честно получается…