Локализационное тестирование носителями языков

Editor's Notes

1. Добрый день. Меня зовут Николаева Анастасия. Сегодня я хочу вам рассказать о том, как успешно провести локализационное тестирование носителями языков. Я думаю, что не все знают, что это такое, но по ходу доклада мы со всем разберемся. Мой доклад будет интересен всем кто трудится над разработкой игр и тестировщикам работающим над мультиязычным продуктом.
2. Для начала я кратенько расскажу о себе. Опыт работы у меня более 5 лет в ИТ. За это время успела поработать тестировщиком, менеджером локализации и руководителем отдела локализации.
3. Практически весь мой опыт работы я приобрела в замечательной компании G5 Entertainment, которая разрабатывает игры под мобильные платформы. Все наши игры поддерживают 13 языков. Это 4 азиатских, 9 европейских (на слайде аббревиатуры поддерживаемых языков) Мы выпустили более 100 премиум проектов И 14 F2P проектов по которым с регулярностью примерно раз в 40 дней выходят обновления.
4. Итак начнем. Во время локализационного тестирования мы должны удостовериться, что сборка работает стабильно на каждом из поддерживаемых языков. Что это значит? Она не должна падать, она должна быть проходима. В ней должны отсутствовать другие косметические дефекты.
5. Что это значит? Все шрифты должны отображаться корректно. Шрифты могут отсутствовать вовсе, как на скриншоте слева. Либо могут частично не отображаться определенные символы. Что более страшно, так как поймать такой дефект не носителю языка очень сложно.
6. Второй тип графических багов это не помещающийся текст. С одной стороны отловить их не проблема (че там все видно же). А с другой стороны бывают хитрые баги, которые выглядят как будто все помещается красивенько, но части текста нет. Как такой баг поймать – да практически никак, сравнивать каждую строку с локкитом оочень трудно.
7. По сути если тестирует не знающий языки тестировщик, это значит что он делает это визуальное тестирование, в которое должно входить полное сравнение текста с локкитом. Ну и вроде все обсудили и все понятно с тем локализационным тестированием. Но мы забыли о том, что отловить ошибки перевода без знания языка мы, обычные тестировщики, знающие одни-два три языка, не сможем.
8. Почему без тестирования носителями не обойтись. Язык это живая экосистема, которая развивается под влиянием научно-технического прогресса, исторических событий, политических течений, культурных изменений. Для игр крайне важен живой язык, который понятен современному пользователю. Кроме того, язык создает ту самую атмосферу, в которую погружается пользователь начиная играть. Применённый термин не в попад может выбить из атмосферы игры и повлиять на покупательские желания игрока. У нас был очень смешной баг, когда такую знаете пластинку черную для граммофона (старый проигрыватель музыки) назвали СД диском. Абсолютно все переводчики используют разные тулы автоперевода, а потом редактируют полученный текст. У них технология работы такая.
9. Они работают с текстом. В котором далеко не всегда есть отсылка к контексту, как на скриншоте. Зачастую у них простыня таблицы с текстом. Что б понять, что действия игры происходят в 17 веке –и там не может быть СД диска, нужно поиграть в игру. Но они ленятся играть в предоставленный для ознакомления билд и заставить их это сделать – нереально.
10. Обычно это решается с помощью тестирования носителями. Подобная услуга доступна для передачи в аутсорс. На первый взгляд, это кажется очень качественно – кто может найти все ошибки лучше носителя. Кроме того, тестировщики-носители смогут по ходу дела поправить баги о непомещающемся тексте, что соптимизирует фикс багов. Но все не так просто как кажется. Первый и очевидный минус – стоимость. Час тестирования носителем стоит от 30 долларов. Что важнее – этот процесс занимает очень много времени, потому что тестировщики-носители зачастую не технические специалисты. И вам придется мучительно долго объяснять им как использовать консоль для запуска читов или изменить время на компьютере, что б получить маркетинговый квест.
11. Несколько раз мы попробовали провести тестирование носителями на наших проектах. Расскажу об одном их них. К моменту проведения тестирования проект уже некоторое время существовал. Кроме доходов мы получали некоторое количество жалоб на перевод от пользователей и журналистов. Поэтому было принято решение потратиться на тестирование носителями. Как это происходило. Тестирование проводилось с самого начала игры. То есть мы тестировали не одно обновление. А все выпущенные на момент тестирования. Скажем так – это очень большой объем контента. Игра в жанре сити-билдер. То есть тестировщику необходимо было пройти все квесты и построить все имеющиеся здания. Были предоставлены чит-коды. Благодаря которым можно было добавлять энергию, денег и прогресс. Мы подготовили подробную инструкцию о том как увидеть весь контент, как пользоваться джирой, принципы регистарации багов, как запустить эмулятор, как изменить языки, как удалить сейвы, как добавить энергию, деньги, прогресс. Это было без преувеличений страниц 10 текста. 4. Во время тестирования мы провели более 5 созвонов и написали неисчисляемое количество писем с пояснениями.
12. По окончанию работ мы получили пул багов и исправленный локкит. После анализа написанных багов мы поняли, что часть контента была не покрыта. Так как тестировщики, пошли по определенному сценарию, упустив часть контента. Причем каждый отдельный тестровщик упустил разную часть контента. Для того, что б это исправить, нам пришлось, проанализировать все баги и понять где и что было упущено. После чего написать инструкцию, как вернуться к упущенному месту. В начеле доклада я говорила, что мы поддерживаем несколько платформ. iPhone4, iPad. У них отличаются разрешения, поэтому несколько другие интерфейсы. Из-за этого необходимо тестирование проводить отдельно на каждой платформе. И зачастую, что в одном не помещается – в другом будет помещаться или будет не помещаться по другому. Мы как бы надеялись, что тестирование будет проводить один тестер на обоих платформах, таким образом, что б синхронизировать правки в локкит. ЭНо нет, синхронизировать правки они не смогли и проводить тестирование одним набором исполнителей так же не захотели. Предложили подготовить два набора локкитов, но для нас этот вариант был не приемлем с технической точки зрения. Так как значительно увеличивал бы вес билда и работу над последующими обновлениями. В итоге мы тестировали только iPhone. Так как все лютые сокращения обычно делаются для него. iPad мы протестировали по старинке своими силами после того, как протянули исправленный локкит. Наша ошибка была в том, что мы не обсудили этот момент перед стартом работ. Тестировщики писали очень странные баги. Они даже предлагали вообще отказаться от идеи их писать. Потом было предложение писать их в таблице экселя. 4. Думаю и так понятно, что все эти телодвижения привели к срыву дедлайна. Что очень не устроило руководство.
13. Но тестировать нам все равно нужно. Поэтому пришлось изобретать велосипед, который вроде ничего работает уже больше года. По статистике с огромной вероятностью, если есть ошибки перевода в первом часе игры, то и дальше они будут повторяться. А что нам нужно? Нам нужно найти несколько примеров, предоставить их переводчику и потребовать исправления по всему объему текста.
14. Мы готовим тест план, согласно которому тестер-носитель языка проходит час игрового времени, готовит нам отзыв с примерами найденных ошибок. Отзывы мы передаем переводчикам. По языкам с негативными отзывами мы требуем провести исправление переводов после чего повторяем тестирование часа игрового контента (но не того же что проверялся в первый раз). По языкам без замечаний мы стартуем визуальное тестирование.
15. Я хочу подробнее остановиться на тест плане. Кстати, если вы все же захотите провести полное тестирование носителями,мои рекомендации так же будут полезны. Это должна быть подробная, пошаговая инструкция, которая будет понятна не техническому специалисту. Тест план должен охватывать все типы нового контента. Например в игре есть какой-то объем диалогов, квестов, ХОГ локация, коллекции и достижения. Так вот тест план должен быть написан так, что б каждый из типов этих текстов проверяющий мог оценить. В принципе часа обычно достаточно. Но если мы работаем над новым f2p проектом, либо по каким-то косвенным признакам предполагаем, что с переводами есть проблемы (например использовали нового контрагента) мы даем больше времени. При планировании задачи и ее бюджета не забудьте заложить время на написание отзыва и подготовку к работе. Чаще всего хватает 30 минут.
16. Теперь по порядку рассмотрим, что в себя должен включать тест-план. Думаю и так понятно, но все же проговорю – тестплан должен быть написан на английском языке. Найти носителя языка, который может обеспечить кросс платформенное тестирование совершенно нереальная задача. Поэтому для того, что б провести тестирование носителями разработке придется попотеть над подготовкой эмуляторного билда. Который должен будет легко запускаться на компьютерах от win7 и выше. Билд должен быть в достаточной степени удобен в использовании и запуске. Он так же не должен весить три гигабайта, потому что далеко не у всех есть доступ к скоростному интернету. В вашем тест плане должна быть инструкция по запуску эмулятора. То есть информация как запустить билд на каждом из тестируемых языков. Где удалить сейвы. Как помочь себе если билд не запускается. То есть ссылки на драйвера видео карт, либо какой-то другой необходимый софт. Вам понадобятся чит коды. На это так же придется потратить время разработке. Обычно это либо особое имя пользователя, либо комбинация особых действий. Помним – что все должно быть в достаточной степени юзабилити. Что в себя должны включать чит коды: В Ф2П играх обычно идет длинный туториал, который во время обновления например не нужно проходить повторно много раз, ведь нас интерисует исключительно новый контент. Так вот – чит для скипа данного туториала очень необходим. Чит на увеличение уровня, валюты, энергии – и так понятно. Чит на запуск нужного квеста. Самый удобный в итоге вариант – введение ИД в определенное поле. В тестплан нужно выбрать квест, который приведет к новой локации, в которой в итоге вы найдете коллекционный предмет и попадете в меню коллекции. То есть, подобрать квест нужно так, что б по результатам его прохождения можно было пройти все типы новых текстов 4. Как завершение очень желательно иметь список окон, которые должен был проверить носитель. Это нужно для того, что б в конце работы можно было прикинуть все ли было проверено. Элементарно – так, квест был, диалог был, новая локация была, новую страницу дневника прочитал. Предмет коллекции получил. Все проверил – молодец, и пошел писать отзыв.
17. Для того что б подготовить тест план нам нужно от 1 до 2х часов. На проведение теста 2 дня потому что, у нас разные часовые пояса с каждым из носителей. На исправление возникших замечаний – по разному. В самом благоприятном прогнозе от 2х дней. Но это зависит от ваших объемов теста и найденных проблем.
18. Для нас это регулярная и обязательная проверка, без которой мы не подтверждаем окончание работ (соответственно его не оплачиваем). И наши переводчики привыкли к тому что их халтура будет найдена. Они будут оштрафованы и обязаны будут исправить весь объем переводов. И не факт, что на следующем обновлении после найденных проблем мы у них сделаем заказ. В общем они стараются не допускать явных косяков. Соответственно мы уверены в качестве выполненной работы. После введения подобного рода тестов у нас значительно снизилось количество негативных отзывов на сторах. Мы получаем живой фидбек от пользователей, который помогает нам делать наши игры лучше. Ну и приятный бюнус – уменьшение стоимости тестирования. Примерно в 18 раз по сравнению с полным тестированием носителями.
19. Спасибо за внимание. Готова ответить на ваши вопросы тут или в кулуарах