Зачем вашему проекту локализационное тестирование

Алексей Мёдов, старший редактор в Inlingo Game Localization Studio делится собственным опытом и опытом коллег по локализационному цеху и рассказывает о локализационном тестировании — как, кем и зачем оно проводится.

 

 

Что такое локализационное тестирование и как его проводить?

Сегодня мы с вами выясним, как работает локализационное тестирование, зачем оно нужно и что там вообще происходит с текстом.

Итак, с места в карьер: что вообще проверяется в рамках локализационного тестирования? Ответом на этот вопрос будет небольшой перечень-классификация  подвидов локализационного тестирования: 

Языковое

Чаще всего подразумевается проверка текста: верный ли он с точки зрения донесения смыслов, фактуры и стилистики с орфографией. Проверяется естественность и нативность перевода, соответствие текста и картинок. Например, в переводе чаша, а на картинке в игре — кубок, или же в английском языке бант перевели как bow, а на другие языки bow стал луком (такое случается со словами-омонимами, особенно, если у переводчиков не было под рукой картинки или описания).

Косметическое

Проверяется интеграция текста в игру: расположение на текстурах, шрифтовое единообразие и так далее. Проверяется правильность используемого шрифта в языке (например, некоторые шрифты не поддерживают диакритические знаки, соответственно, наша задача увидеть проблему и посоветовать клиенту правильный шрифт), влезает ли текст в диалоговое окно (если нет, мы сокращаем текст или расставляем правильные переносы).

Мы можем проводить тестирование как на эмуляторах различных устройств (например, эмулятор iPad, который запускается на ПК), так и на самих устройствах (ПК, устройства на Android, iOS). 

Что нужно для тестирования?

Для того, чтобы сделать тестирование, нам нужен, как минимум, билд с игрой. Но в идеале мы должны получить от разработчика следующий набор:

• Билд

Идеальный вариант для нас — билд с читами, чтобы ускорить процесс прохождения и сконцентрироваться на проверке текстов, не тратя время на фактическую игру. Или же билд с начисленным балансом валюты, чтобы мы легко могли покупать, например, новое оружие, апгрейдить здания и прочее. Если в билде предусмотрено и то и другое, то тестирование проходит легко и интересно. Мы можем полностью сконцентрироваться на задаче и пройти больший объем сюжета за меньшее время.

• Чеклист или тест-план

Список вещей, которые нам требуется проверить (например, интерфейс, диалоги, главы сюжета, коллекции предметов, миссии и многое другое). Тест-план делает тестирование более организованным. Но возможно и тестирование без чеклиста. В таком случае проверяются всевозможные окна и тексты, которые мы встречаем в ходе линейной игры.

• Локкит или файл с игровыми текстами 

Необходим для того, чтобы внести правки в него по итогам тестирования. Также локкит нужен для того, чтобы проверять сомнительные места в игре. Например, бывает так, что в игре по каким-то причинам находятся старые тексты, а в локките уже обновленные, такие вещи мы тоже стараемся ловить.

Некоторые разработчики присылают на проверку скриншоты игры или видео с геймплеем. Это значительно сокращает время на тестирование, но является достаточно трудозатратным способом для самого клиента (много скриншотов не наделаешь). Один из клиентов как-то прислал папку со скриншотами, которая весила более 10 Гб, зачем они нужны, если можно скачать билд, который весит 500 Мб?

Кто делает тестирование?

Им обычно занимаются опытные тестировщики, которые давно знакомы с играми. Они играют в разные жанры, поэтому знакомы со спецификой каждого. Нам встречались тестировщики, которые любили только фермы, а также те, кто отдавал предпочтение только шутерам. Дело вкуса 🙂 Но тестировщики умеют играть во всё. 

Мало быть просто хорошим игроком, чтобы провести локализационное тестирование, нужно еще быть хорошим лингвистом, знать особенности, тонкости и нюансы языка. Конечно, косметические баги смогут найти и не лингвисты, но лучше стремиться к тому, что тестировщик сможет увидеть логические, грамматические, стилистические ошибки. Мы разделяем тестировщиков на две большие категории: носители и не носители. 

Носители-тестировщики — люди, для которых тестируемый язык является родным, а не носители — те, кто выучил нужный язык. Различаются эти люди по ставкам и по глубине проверки языка в игре. Естественно, носитель сможет более глубоко проверить качество перевода и то, как он встал в игру. 

Не носитель может что-то пропустить. Но как показывает практика, некоторые не носители ничуть не уступают носителям, благодаря своим глубоким знаниям языка. Тем не менее, плюс тестировщиков-носителей заключается в том, что он точно знает реалии своей страны и сможет увидеть, если в переводе или в самой игре (в картинках, видеоряде или музыке) используется что-то неподходящее или даже нарушающее ценности жителей этой страны.

В идеале всегда проверять все носителями, но эти исполнители стоят ощутимо дороже — поэтому, если все упирается в бюджет, то лучше выбрать не носителей.

Как проходит локализационное тестирование?

Тестирование проходит следующим образом:

1. Мы получаем задачу на тестирование от клиента (нужные материалы, ТЗ и какие-то дополнительные комментарии, на что нужно обратить внимание). Обговариваем сроки и требуемое время. Зачастую клиент сообщает, сколько часов нужно протестировать, иногда выдается тест-план (в этом случае уже нет фиксированного времени). 
2. Мы собираем команду (носителей или не носителей, иногда бывают смешанные команды).
3. Далее идет непосредственно тестирование, в ходе которого мы создаем отчеты по тестированию и вносим правки в локкит.
4. Если мы переводили этот проект и далее тестируем его, то мы советуемся с переводчиками о валидности найденных правок. Иногда бывает, что мы хотим поправить сомнительный момент в тексте, а на самом деле переводчиком так и было задумано. Например, как-то тестировщики хотели поправить странную речь персонажа, а на самом деле переводчик сделал такую речь специально, так как по задумке авторов персонаж должен говорить странно и казаться не от мира сего.
5. После этого мы сдаем результаты тестирования клиенту. Клиент вносит нужные правки в игру.
6. Далее начинается этап регрессионного тестирования.

Что такое регрессионное тестирование?

Тестирование, которое необходимо на финальных этапах локализации, его цель убедиться перед релизом, что все ранее найденные ошибки исправлены. Это не часть локализационного тестирования, можно сказать, что это отдельный вид. Регресс может делаться как для лингвистического, так и для функционального тестирования. Сначала проводится первый этап тестирования, в ходе которого создаются отчеты и вносятся коррективы в локкит. После этого клиент вносит правки в игру и высылает нам обновленный игровой билд, для которого мы делаем повторное (регрессионное) тестирование и проверяем, все ли ошибки были устранены по результатам первого круга тестирования и не появились ли новые. Например, если в первый круг текст диалогового окна не влезал в плашку, мы его сократили, но в ходе регресса выяснилось, что потребуется сократить еще больше или расставить переносы в других местах, иногда бывает, что какие-то правки по разным причинам не были внесены в билд, наша задача это выловить. Регрессионное тестирование позволяет закрепить результат первого круга и убедиться, что тексты в игре встали правильно. При необходимости этот этап может быть повторен, но чаще всего это не требуется.

Что такое баг-репорт?

Баг-репорт или отчет по результатам тестирования представляет собой форму, в которой мы описываем найденный баг. В отчете указывается следующая базовая информация:

1. Тип найденной ошибки, чтобы было удобно классифицировать баги и передавать на исправление ответственным лицам. Например, косметическая или лингвистическая.
2. Шаги воспроизведения (как найти ошибку в игре) или просто айди текста из локкита.
3. Описание ошибки. 
4. Текущий результат (как выглядит предложение с ошибкой сейчас)
5. Как должно быть
6. Скриншот с ошибкой или ссылка на него
   

Некоторым клиентам требуется документ, в котором оформлен отчет (например, эксель-файл), а у некоторых для этих целей используются специальные баг-трекинговые платформы (например, Jira или Redmine). 

Сейчас покажем пару скриншотов баг-репортов — к сожалению, не наших, потому что у нас проекты под NDA.

Как определить глубину тестирования?

Глубина тестирования — это по сути длительность и тщательность тестирования. И она зависит от целей клиента. Например: 

• Игра очень большая, и проводить полное тестирование игры очень долго и дорого. Тогда клиент просит протестировать первые 3-5 часов игры, чтобы там все было идеально — чтобы на этом этапе зацепить игроков и они не ушли из игры из-за разочаровывающих ошибок. К тому же игроки ставят оценки после первых часов в игре, а к ошибкам и недочетам, встреченным позже относятся более снисходительно.
  
• Клиенту обязательно нужно протестировать игру, например, до 30 уровня. И исходя из этого вычисляются количество часов и сроки тестирования.
  
• Вышел новый апдейт и его необходимо протестировать полностью.
  
• И даже такое: у клиента есть бюджет только на 15 часов тестирования — значит, делаем только 15 часов тестирования. 

В качестве заключения: мы всегда рекомендуем проводить локализационное тестирование носителями языка — хотя бы первые 3-5 часов игры. Это убережет вас от ошибок, которые могли проскользнуть в переводе из-за незнания полного контекста и которые вы могли не заметить из-за незнания языка.