Тестирование локализации что это
Тестирование локализации что это
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова
Если ваше приложение используется в других странах, то, скорее всего, у него есть какая-то локализационная стратегия. Многие полагают, что локализация – это просто перевод на другой язык, но это не так. Вот примеры локализации, которая может использоваться в вашем приложении:
Язык: в разных странах говорят на разных языках, однако это верно не только для стран, но и для регионов. Например, в канадской провинции Квебек говорят в основном по-французски, а в прочих провинциях – по-английски.
Правописание: даже когда две области говорят на одном языке, они могут писать по-разному. К примеру, цвет пишется как «color» в США, но как «colour» в Канаде и Великобритании.
Слова и идиомы: они могут различаться даже в пределах одного языка. В Великобритании грузовик – lorry, а багажник – boot. В США, глагол «table» применительно к теме разговора означает, что этот разговор нужно отложить, а в Великобритании и Канаде – что на эту тему нужно немедленно начать говорить, полная противоположность США!
Форматы даты и времени: в США даты пишутся как месяц/день/год, а в Великобритании – как день/месяц/год. В США, как правило, используют AM и PM, обозначая время, но во многих странах используется 24-часовое время, и 1:00 PM в США превратится в 13:00.
Системы мер и весов: в США, как правило, используются единицы измерения традиционной американской системы – фунты для веса и футы с дюймами для длины. В большинстве прочих стран применяется метрическая система. Большая часть стран также измеряет температуру по Цельсию, а в США это делается по Фаренгейту.
Индексы и номера телефонов: очень сильно различаются в разных странах. См. мои статьи про международные телефонные номера и индексы.
Изображения: картинки, возможно, придется менять в зависимости от страны, принимая во внимание определенные моменты. К примеру, если приложение будет использоваться повсеместно, то изображение здания с американским флагом – возможно, не очень хорошая идея. А если приложение предназначено для религиозных стран, то лучше убрать фотографию человека в безрукавке.
Тестирование локализации
Первый шаг в тестировании локализации – это определение, что именно планируется локализовывать. Ваша компания может решить локализовать дату и время, индексы и телефоны, но не язык. Или, к примеру, мобильное приложение будет использовать только языки, установленные в устройстве – текст приложения будет на определенном едином языке, а кнопки – на пользовательском.
Если ваше приложение будет использовать несколько языков, составьте список всех текстов, нуждающихся в проверке. Скажем, если у вас есть пункты меню «Домой», «Поиск», «Ваш профиль» и «О нас», а ваше приложение будет переводиться на французский и испанский, узнайте, как должны выглядеть эти пункты меню на французском и испанском. Безусловно, переводчик должен посоветоваться с носителем языка, чтобы убедиться, что перевод верен.
Затем приступите к тест-плану. Простейший способ – это сделать табличку, где в левой колонке будут типы локализации, которые нужно тестировать, а в первой строке – страны. Вот простенький пример:
После создания матрицы прогонять тесты очень просто. Полезный совет для мобильных тестировщиков: переключая устройство на другой язык, убедитесь, что вы точно знаете, как переключить язык назад, если вы не знаете языка, к которому переходите. Когда я тестировала китайскую локализацию, это было особенно важно, так как я совершенно его не знаю. Я абсолютно не понимала, что написано в меню, поэтому просто запомнила порядок пунктов, чтобы знать, куда нажать, чтобы переключиться на английский.
Другой важный момент – убедиться, что переведенный текст хорошо выглядит в приложении. К примеру, кнопка Save может отлично смотреться в английской версии, но в немецкой она будет выглядеть так:
Завершив тестирование локализации, вы, возможно, захотите его автоматизировать. Это можно сделать при помощи инструментов автоматизации на уровне интерфейса – например, Selenium. Можно сделать отдельный набор тестов для каждого языка, где шагом установки будет выбор нужной страны в браузере или устройстве, а каждый тест будет проверять один аспект локализации – к примеру, верный язык текста на кнопках или возможность ввести индекс в формате выбранной страны. Полезно также использовать инструмент вроде Applitools для валидации правильного отображения кнопок или иконок национальных флагов.
Локализация – сложное дело, и ее так же сложно совершенствовать, как и ПО. Но если вы и ваша команда четко знаете, что вы хотите локализовать, и методично подходите к тестированию, вы можете быть уверены, что большая часть пользователей будет довольна.
Тестирование локализации что это
Предположим, у вас есть игра. Она может быть большой или маленькой, компьютерной или мобильной, двухмерной или VR, хардкорной или казуальной. Вы почти закончили ее разработку, протестировали все механики, дизайн уровней, квесты, монетизацию, баланс, звук и в конце концов остались довольны. Настолько, что решили: моя игра довольно крутая, пожалуй, игроки в других странах будут от нее в восторге! Отдали в студию локализации на перевод и озвучение, получили переведенные материалы, интегрировали их в билд, отправили на релиз. Через пару недель рассматриваете пользовательские отзывы и недоумеваете: а что это все так ругаются? А, стоп, вы, наверное, не в курсе, что в вашей игре такое:
Тестирование локализации (локализационное тестирование) — это процесс по комплексной проверке локализованной версии программного продукта на его соответствие рынку целевой страны с учётом её культурных, правовых и других особенностей.
Основные виды проверок при локализационном тестировании:
Тестирование локализации — один из последних этапов разработки игры. Бывает так, что издатели пропускают этот этап ввиду отсутствия денег, нехватки времени или иных причин. Иногда локализованный продукт поступает в продажу, не пройдя предварительно этап тестирования перевода и озвучки. Многие знакомы с подобными печальными примерами, особенно в России.
Подготовка процесса
Как правило, перед началом тестирования разработчик высылает локализаторам вспомогательные данные, позволяющие вникнуть в курс дела:
Идиллический сценарий, но так, увы, бывает не всегда. В отдельных случаях (когда дело касается больших проектов), разработчик может выслать саму игровую приставку, на которой будет проходить тестирование, а в других — даже не вспомнить про чит-коды.
Менеджеры проектов согласовывают время, выделяемое на тестирование, устройства и платформы, количество тестировщиков, виды тестирования (функциональное, лингвистическое, маркетинговое). Когда все эти детали утверждены, можно приступать к процессу. Чем больше материалов предоставил разработчик, тем проще тестировщикам сориентироваться в новой игре и быстрее обнаружить все ошибки. Разумеется, не стоит надеяться, что всегда под рукой будет дизайн-документ, тест-кейсы или доступ к консоли разработчика — зачастую в игру приходится вникать без подсказок и наводок, разбираясь в деталях с позиции рядового пользователя (тестирование по принципу черного ящика).
Поскольку билд с ранней версией игры, находящейся в разработке, — информация строго конфиденциальная, для его запуска может потребоваться настройка и подключение специальных программ или доступа по закрытой сети, предоставленной заказчиком. На подготовку этого процесса также требуется дополнительное время.
Системы баг-трекинга и баг-репорты
Основное поле работы тестировщика — это система отслеживания ошибок (или баг-трекер). Они бывают разные, но в целом устроены по одному принципу. Баг-трекеры предназначены для занесения отчетов об ошибках (баг-репортов). Такие отчеты направляются напрямую разработчикам и помогают эффективно решить конкретную проблему.
Задача тестировщика — обнаружить в игре все возможные неполадки (баги). Требуется максимально сжато и четко передать шаги воспроизведения конкретного бага, вкратце описать проблему и предложить вариант ее исправления, предоставив скриншот или видео, где зафиксирован спорный момент. Также в отчете может быть указана дополнительная информация: версия тестируемого продукта, платформы или устройства, на которых данный баг был замечен, степень воспроизводимости (reproduction rate) и характер критичности бага (low, medium, high, highest).
Похожие материалы
Особенности багов локализации
Localization quality assurance (QA) или тестирование локализации — особый вид тестирования. В первую очередь, это косметическая оценка переведенных текстовых элементов игры, осуществляемая визуально. Чтобы все было ровно, никуда не вылезало, друг на друга не накладывалось и не обрывалось. Правильный текст на соответствующем языке локализации должен находиться в положенном ему месте, отображаться корректно, быть читабельным, правильно сокращаться, следовать глоссарию.
В русской локализации слово на испанском? — Баг. Вместо «Закрыть» написано «Закры»? — Баг. Вместо текста — набор непонятных страшных символов? — Баг. В описании юнита шрифт мелкий настолько, что на экране с диагональю 4 дюйма едва видно, что написано? Печальная история: не совсем баг, но требует обязательного занесения в отчет. Либо дизайнеры поменяют шрифт, либо редакторы сократят перевод.
Во-вторых, тестирование локализации подразумевает лингвистическую оценку, то есть полную вычитку встречаемого в игре текста. Опечатки, пропущенные знаки препинания и пробелы, капитализация букв, отсутствие перевода, неправильный перевод, некорректные сокращения, пунктуация и стиль — на все это необходимо обращать внимание. Тестировщик локализации должен быть немного редактором и переводчиком.
В некоторых ситуациях потребность в составлении баг-репортов отсутствует: когда, например, речь идет о грамматических, пунктуационных ошибках, неточностях перевода или посторонних звуках в аудиофайлах. Тогда, в зависимости, от инструментария, которым он располагает (доступ к базе текста или звуковому редактору), тестировщик может сам внести исправления, скоординировав решение с редакторами или звукорежиссерами.
Для локализации характерен ряд типичных багов, рассмотрим их подробнее:
Untranslated text (непереведенный текст) — тут все просто. Внезапный английский текст в русской версии программы (где его быть не должно), или испанский — в арабской.
Overlap (взаимное наложение) — один блок текста накладывается на другой, создавая нечитаемый сумбур букв.
Truncation (обрывание) — слово или предложение обрезается элементом интерфейса, иконкой, границей экрана.
Misalignment (неправильное расположение) — блок текста смещен вбок, вниз, вверх. Создает эстетически неприятное впечатление, затрудняет восприятие.
Missing text (пропущенный текст) — текст отсутствует в том месте, где должен быть.
No game no test?
Не совсем так. Тестировать локализацию в игре можно и без непосредственного взаимодействия с игрой. Если дело касается озвучки — то тестировщику предоставляется набор аудиофайлов или видеороликов, в которых необходимо проверить качество звука, наличие возможных шумов и неудачно склеивающихся фраз и попадание реплик персонажей в губы (lip sync). А при тестировании мобильных продуктов, программного обеспечения или сайтов, проверку можно осуществлять по скриншотам различных элементов интерфейса, подготовленных заранее. В этом случае даже необязательно, чтобы подготовку скриншотов выполнял носитель языка перевода.
Взаимодействие с командой
В процессе тестирования локализации принимают участие не только тестировщики. Для достижения успешного результата требуется взаимопонимание всех членов команды.
Тестировщик <> Разработчик: лаконичность и детальность. Необходимо максимально просто и эффективно описать шаги воспроизведения той или иной ошибки, без лишних слов.
Тестировщик <> Переводчик: внимательность и знание контекста. Переводчики не всегда видят то, что переводят. Тестировщик имеет доступ к конечному продукту и может сверить перевод с реальными вещами, которые он отображает, а затем сообщить переводчикам и редакторам необходимую информацию для корректировки перевода.
Тестировщик <> Редактор: редакторы правят переводчиков, но тестировщик должен быть готов поправить редактора. Нужно быть доскональным, но не стоит придумывать ошибки там, где их нет.
Тестировщик <> Менеджер проекта (ПМ): поскольку ПМ — основной посредник в коммуникации между заказчиком и остальными участниками процесса, тестировщику необходимо направлять все пожелания и предложения менеджеру проекта в доступной манере, чтобы тот смог донести эту информацию до заказчика.
Как работает QA локализации видеоигр?
Ответ простой: либо работает, либо — нет. И во втором случае результат налицо. Прежде всего, это зависит от желания заказчика-издателя, от того, как составлен план работы по локализации: считает ли он целесообразным выделить средства из бюджета и время на проверку качества отображения текстов в игре, качества озвучки и т. п. А дальше дело за тестировщиками, редакторами и менеджерами проекта. Поскольку, к тому времени, как подошла пора оценки качества локализации, работа переводчиков, актеров озвучивания, звукооператоров и звукорежиссеров уже, как правило, подошла к концу.
Тестирование локализации — это наведение порядка и «уборка» переведенных в игре материалов. Даже если игра является крупным ААА-тайтлом, прошедшим множество тщательных проверок на разных этапах локализации, нельзя быть уверенными на 100%, что в конечной версии где-нибудь в маленьком каверзном окошке интерфейса не оборвется на полбуквы слово, в техническом описании патча не закрадется пара опечаток, а вместо символа кавычек не будут отображаться жуткие элементы кода. Менеджеры проектов и редакторы тоже иногда устают. Не говоря уже про мобильные игры, где окна для размещения длинных русских слов смешного размера, а дизайн интерфейса (и, соответственно, размер окон) может меняться с каждым новым обновлением.
Пользователи (видеоигр и не только) — весьма придирчивая аудитория. Даже пара таких, казалось бы, незначительных помарок может вызвать у них раздражение и нежелание оценивать дальше локализованную версию. Ведь никто не любит гневные отзывы на форумах и комментарии в соцсетях в духе «За что я деньги плачу?!» или «Локализаторы как всегда…». Одно дело, когда игра переведена настолько великолепно, что сплошь состоит из перлов — тогда ее непременно растащат на мемы. Но другое — если над вашей игрой потрудилась действительно команда профессионалов с большим опытом. Но из-за того, что игра не была в итоге протестирована, в релизную версию просочилась парочка, скажем так, не очень приятных моментов. Вот именно, всего пара мелочей — придирчивой публике этого уже достаточно, чтобы потерять доверие к локализаторам.
Финальная вычитка и проверка уже добавленного в игру перевода — не самая сложная операция, гарантирующая вашей игре достойный вид. Согласитесь, всем будет гораздо приятнее, когда проверку качества локализации контролируете вы сами, а не пользователи, купившие игру? А то и правда, как-то не очень честно получается…
Что такое локализационное тестирование и почему пропускать его — плохая идея
Пренебречь тестированием локализации (LQA — Localization Quality Assurance) всегда кажется очень заманчивой идеей — зачем тратить время на дополнительную проверку, когда всё и так вроде бы в порядке? Команда Inlingo расскажет, почему не стоит пропускать этап LQA, каким образом он влияет на количество установок и как подготовиться к тестированию, чтобы провести его максимально эффективно.
Что такое локализационное тестирование?
Это проверка качества локализации, которая помогает выявить ошибки до того, как их обнаружат игроки. LQA можно разделить на две большие группы: языковое и косметическое тестирование.
Языковое тестирование — это общая проверка текста. В первую очередь нужно убедиться, что в нем нет смысловых, стилистических, фактических и любых других ошибок. Также на этом этапе оценивается естественность, или нативность, перевода и его соответствие реалиям игры.
Например, важно следить, чтобы из-за нехватки контекста чемпионский кубок не превратился в чашу, а безобидный бант — bow — не стал в итоге луком. Такое часто случается, если у переводчиков под рукой нет изображения или описания предмета.
Языковая ошибка во времени глагола. Видим «Did something happenned?» вместо «Did something happen?».
Косметическое тестирование проверяет, насколько гармонично текст интегрирован в игру: здесь оцениваются переносы, расположение строк на текстурах, шрифтовое единообразие, отображение текста в диалоговых окнах. Важно не только выявить соответствующие ошибки, но и предложить подходящую замену — к примеру, сокращенный вариант текста под интерфейс или новый шрифт, поддерживающий диакритические знаки.
Одна из строчек в речи персонажа не переведена с японского на английский — это косметический дефект.
Языковое тестирование
Косметическое тестирование
Языковое и косметическое тестирование повышают качество конечного продукта. Обычно на игровую локализацию никто не обращает внимания, но стоит появиться первым проблемам, как вы тут же ее заметите. Такие проблемы запросто могут завалить выход на глобальный рынок, поэтому обращать внимание на качество текста и его отображение в игре просто необходимо.
Тестировать игру нужно еще и потому, что это повышает шанс попадания в фичер или рекомендации Google Play и App Store. При должном везении у вас появится возможность увеличить количество установок в разы. Это ли не аргумент?
Какие материалы нужны для тестирования?
Чтобы провести локализационное тестирование, нужен как минимум билд самой игры. В теории этого, может, и достаточно, но для повышения эффективности проверки разработчикам следует прислать дополнительные материалы. Вот универсальный набор, который поможет тестировщикам как следует проверить игру.
Идеальный вариант — билд с читами или начисленным балансом валюты. Так тестировщики смогут полностью сконцентрироваться на задаче и пройти больший объем сюжета за меньшее время.
Чек-лист или тест-план
Список вещей, которые требуется проверить. Например:
Локкит или файл с игровыми текстами
Необходим, чтобы сверяться с остальными текстами при обнаружении в игре сомнительных мест. По итогам тестирования в локкит вносятся финальные правки.
Ниже приводим пример чек-листа, с которым наиболее комфортно работать. Здесь тестировщики отмечают, какие моменты в игре в полном порядке, а где обнаружены баги:
А еще делимся кусочком локкита. На примере он собран в Google Sheets, но можно сделать такую же таблицу в Excel, Strings и в любом другом формате:
(источник скриншота)
Некоторые разработчики присылают на проверку скриншоты игры или видео с геймплеем. Это значительно сокращает время тестирования, но для самого клиента довольно трудозатратно — много скриншотов не наделаешь.
Кто занимается тестированием?
Обычно игры тестируются опытными специалистами, которые давно знакомы с индустрией. Но быть прокачанным игроком недостаточно — нужно хорошо разбираться в лингвистике, знать особенности и нюансы языка. Здесь есть два варианта: тестирование носителем или неносителем.
Проверка игры носителем имеет свои плюсы, но обойдется недешево:
Преимущества
Недостатки
При тестировании неносителем языка плюсы и минусы следующие:
Преимущества
Недостатки
Наш совет — проверять всё носителями. Конечно, выбор зависит от бюджета, но на исполнителях экономить точно не стоит.
Что именно нужно тестировать?
Здесь всё зависит от ваших возможностей, запроса и формата игры. Варианты следующие:
Первые 3-5 часов игры
Если игра очень большая, полное тестирование обойдется дорого и займет много времени. Поэтому клиент может попросить протестировать только первые 3-5 часов проекта — на этом этапе очень важно зацепить игроков, чтобы надолго вовлечь их в процесс.
К тому же игроки обычно ставят оценки после первых часов в игре, а к ошибкам и недочетам, которые встречаются позже, относятся более снисходительно.
Ограниченное количество часов
Зависит от бюджета клиента: если он рассчитан только на 15 часов тестирования, ровно столько времени и отводится на проверку игры.
Обязательный объем
К примеру, если клиенту обязательно нужно протестировать игру до 30 уровня, количество часов и сроки тестирования рассчитываются исходя из этого требования.
Новые апдейты
При выходе обновления его также необходимо полностью протестировать.
Мы всегда рекомендуем проводить локализационное тестирование носителями языка — хотя бы первые 3-5 часов игры. Это убережет вас от ошибок, которые могли проскользнуть в переводе из-за отсутствия контекста и которых вы могли не заметить из-за недостаточного знания языка.
Как проходит локализационное тестирование?
Что такое регрессионное тестирование?
Это тестирование проводится для того, чтобы убедиться, что все правки после первого теста внесены, а все ошибки исправлены верно и точно не попадут в релизную версию. В идеале процесс тестирования должен выглядеть так:
Регрессионное тестирование позволяет закрепить результат первого круга оценки и убедиться, что все тексты в игре встали правильно. При необходимости этот этап может быть повторен, но в большинстве случаев одного раза достаточно.
Мы можем проводить тестирование как на эмуляторах различных устройств (таких как эмулятор iPad, который запускается на ПК), так и на самих устройствах: ПК, планшетах и смартфонах на Android и iOS.
Как выглядит результат тестирования?
Результатом тестирования является баг-репорт — это отчет, по которому разработчики в дальнейшем вносят правки в игру. Чаще всего он выглядит как стандартная форма, в которой описывается каждый найденный баг. Указывается следующая базовая информация:
Итоги
Локализационное тестирование — действительно важная процедура. Она поможет вам отшлифовать текстовую составляющую проекта и грамотно поместить ее в интерфейс. Пренебрегать LQA не стоит, иначе высок шанс нарваться на негативные отзывы игроков. После релиза они найдут все баги за вас, снизят оценку игры в сторах и уменьшат количество скачиваний.
Итак, если вы решили протестировать игру: