Становление современного информационного общества оказывает существенное влияние на темпы глобализации мировой экономики. В сфере информационных технологий выход на глобальный рынок является весомым показателем востребованности продукта. Интернационализация и локализация являются средствами адаптации программного продукта к различным языкам, региональным различиям и техническим требованиям целевого региона. Интернационализация – процесс создания приложения, которое может быть адаптировано к различным языкам и регионам без технических изменений, в свою очередь, локализация – процесс адаптации интернационализированного программного обеспечения для определенного региона или языка путем добавления компонентов, специфичных для региона, и перевода текста. Локализация, которая потенциально может выполняться неоднократно для различных регионов, использует инфраструктуру, построенную в результате интернационализации, как правило, выполненной единожды в качестве неотъемлемой части долгосрочной стратегии разработки продукта [1]. С развитием процессов информатизации общества ожидаемо возрастает потребность в унификации практик адаптации программных продуктов к различным условиям эксплуатации, причем процесс локализации не ограничивается переводом на другой язык, затрагивая аспекты, обусловленные культурными различиями: принятые форматы дат, адресов, единиц измерения, приемлемые для данной среды изображения, совместимость с популярными продуктами и локализованными операционными системами, представленными на локальном рынке. Немаловажным фактором для выхода на новый рынок является соответствие продукта региональному законодательству: законам, регламентирующим хранение персональных данных, антимонопольному законодательству, налоговой системе. Строгое следование стандартам интернационализации и локализации является обязательным условием проектирования. Документы, регламентирующие процессы локализации программных продуктов, касаются различных аспектов процесса адаптации приложения: требования к услугам перевода, отраслевые стандарты, рекомендации ведущих поставщиков средств разработки. GALA (Globalization and Localization Association) – некоммерческая ассоциация, занимающаяся разработкой адаптационных стандартов и популяризацией проблем локализации в сфере бизнеса, образования и государственного управления. Членами ассоциации являются организации, компании и учебные заведения, ориентированные на глобальный рынок, разрабатывающие технологические решения и программное обеспечение для различных сфер [2]. Стандарт ISO 17100: 2015 содержит требования к основным процессам, ресурсам и другим аспектам, необходимым для предоставления качественных услуг по переводу, которые соответствуют применимым спецификациям [3]. Документ в первую очередь ориентирован на поставщиков и потребителей услуг перевода, упрощая взаимодействие между сторонами за счет объединения терминологии и создания типовой структуры услуг.
Интернационализация и локализация программного продукта
Формирование требований к локализуемому продукту ориентировано в первую очередь на маркетинговую стратегию для каждого из целевых регионов. В качестве примера рассмотрим веб-приложение, ориентированное на российский и китайский рынки. Процесс интернационализации целесообразно начинать с проектирования на английском языке, разработанный интерфейс будет являться базой для последующей локализации, а также является универсальным для выхода на рынки множества регионов. Таким образом, для исходного приложения выбирается, к примеру, англоязычная локаль en_GB, для китайского рынка необходимо поддерживать две системные локали zh_CN – КНР и упрощенные иероглифы, zh_TW – Гонконг, Тайвань и традиционные иероглифы, для российского – локаль ru_RU. Основные требования, предъявляемые к продукту в процессе интернационализации:
1. Следование маркетинговой стратегии. Предоставляемые услуги могут отличаться в зависимости от целевого региона, ввиду региональных особенностей часть функциональности может быть реализована альтернативным способом. В таком случае симметричная структура приложения не отвечает бизнес-требованиям, следовательно, на этапе проектирования оценивается необходимость переработки дизайна и архитектуры локализованной версии продукта,
2. CMS. Построение приложения на базе мультиязычной системы управления контентом позволит предоставить контент-менеджерам интерфейс администрирования на необходимом языке.
3. Контент. Привлечение профессиональных лингвистов позволяет проверить точность и логику перевода пользовательского интерфейса и документации [4], а также соответствия контента требованиям SEO целевого региона.
4. Доступность ресурсов. Необходимо учитывать, что некоторые популярные сервисы, такие как Facebook, Twitter, Youtube, Foursquare, сервисы Google, в Китае недоступны или работают с ограничениями, LinkedIn недоступен в России.
5. Интеграция с местными сервисами. Для китайского рынка необходимо предусмотреть замену популярных сервисов местными: авторизация с помощью аккаунта QQ – сервиса мгновенного обмена сообщениями (замена Facebook, Gmail), Sina Weibo – сервис микроблога (замена Twitter) и Renren – социальная сеть для онлайн-маркетинга. Следует избегать интеграции с международными платежными агрегаторами, для потребителей более удобны местные системы Alipay, Tenpay, PayEase. Для российского рынка характерна интеграция с VK, сервисами Яндекс и другими.
6. Авторские права. Для каждого из целевых регионов необходим заверенный перевод правоустанавливающих документов на контент.
7. Интерфейс. В процессе проектирования интерфейса необходимо учитывать особенности культуры целевого региона, учет опыта интернет-пользователей и качество контента, в то же время локализация продукта не должна мешать узнаваемости бренда.
8. Соответствие правовым нормам. К примеру, в мае 2018 г. все страны Европейского союза (ЕС) перейдут на новые правила обработки персональных данных, установленные Общим регламентом по защите данных (General Data Protection Regulation – GDPR) [5]. Данные правила действуют по экстерриториальному принципу, то есть компании необязательно быть зарегистрированной на территории ЕС. Если компания предоставляет услуги на территории ЕС, то необходимо реализовать логику работы с персональными данными по правилам GDPR. Первая и главная особенность GDPR – это экстерриториальный принцип. Ранее территориальная применимость директивы была неоднозначной и касалась процесса обработки данных в контексте компании. GDPR будет применяться к обработке персональных данных контроллерами и процессорами в ЕС, независимо от того, происходит ли обработка в ЕС или нет. GDPR будет также применяться к обработке персональных данных субъектов данных в ЕС контролером или обработчиком, не установленным в ЕС, где деятельность связана: с предложением товаров или услуг гражданам ЕС (независимо от того, требуется ли оплата) и с мониторингом поведения, которое происходит в ЕС. Предприятия, не входящие в ЕС, обрабатывающие данные граждан ЕС, также должны будут назначить представителя в ЕС. Важно отметить, что правила GDPR применяются как к контроллерам – определяющим цели и средства обработки персональных данных, так и к процессорам – обрабатывающим личные данные от имени контроллера, это означает, что облачные сервисы не будут освобождены от применения GDPR [6].
При корректном проведении интернационализации наиболее распространенными дефектами локализации будут дефекты пользовательского интерфейса и ошибки перевода. Тем не менее могут проявляться и функциональные дефекты, связанные с использованием локальных календарей, различным форматированием данных, единиц измерения, времени в зависимости от региона, также причиной могут служить дефекты кодировки – попытка ввода неподдерживаемых символов в поле поиска или создания логина и пароля, в лучшем случае приведет к ошибке сервера под номером 505, в худшем может привести к прекращению работы сервера. После завершения разработки и функционального тестирования начинается процесс локализации: продукт передается переводчикам для перевода пользовательского интерфейса, документации и сопутствующих файлов, работа может вестись для нескольких языков одновременно. На следующем этапе проводятся исследования, показывающие необходимость изменения продукта в связи с культурными особенностями целевой страны: уточнение формулировок, изменение цветовой схемы, локализация маркетинговых решений.
Адаптационное тестирование
Десять лет назад тестирование локализации приравнивалось к лингвистическому тестированию. Было широко распространено мнение, что адаптационное тестирование должно проводиться носителями целевого языка или специалистами с достаточным языковым уровнем. На сегодняшний день ситуация изменилась, в команду тестировщиков включаются специалисты – носители языка для обеспечения качества локализации проекта. Данные специалисты ответственны непосредственно за перевод интерфейса и документации, остальные участники команды занимаются тестированием функциональности, нагрузочным тестированием и другими видами тестирования. Таким образом производится «сортировка» найденных дефектов: функциональные ошибки передаются разработчикам, ошибки перевода отправляются группе локализации. Процесс адаптационного тестирования должен начинаться не ранее, чем функциональность продукта достигнет достаточного уровня стабильности, в противном случае специалисты по локализации могут столкнуться с дефектами ПО одновременно с их обнаружением группой функционального тестирования, в результате произойдет дублирование задач в баг-трекинг системе, что создаст дополнительную неоправданную нагрузку на тест-менеджмент. Инженер адаптационного тестирования специализируется на проверке точности перевода интерфейса на целевой язык и выполняет тестирование UX, чтобы убедиться, что пользователи из любого из поддерживаемых регионов могут запускать приложение и выполнять основные функциональные задачи [7].
Функциональное тестирование продукта включает в себя проверку следующих сценариев:
– Поддержка целевых локалей всеми модулями приложения.
– Корректная работа приложения в окружении, характерном для целевого региона (аппаратное обеспечение, операционные системы и другое).
– Отображение подсказок и системных уведомлений.
– Ошибки интеграции со сторонними сервисами.
– Ошибки локализации со стороны интерфейса администрирования.
– Путь к системным папкам – часто ссылки на системные папки могут повреждаться во время перевода, и, таким образом, они больше не адресуют к нужным ресурсам. Примером проявления данного дефекта служат неотображаемые «сломанные» изображения.
– Прочие дефекты пользовательского интерфейса. Неподдерживаемые шрифты, неправильные размеры кнопок и выпадающих списков, перенос слов, перевод текста внутри изображений.
Одной из наиболее эффективных практик функционального тестирования локализованного приложения является тестирование псевдолокализации. Данный метод предназначен для проверки локализуемости строк до самой локализации, обычно выполняется в рамках этапа тестирования интернационализации. При псевдолокализации стандартные символы заменяются потенциально проблемными [8]. Псевдолокализованное программное обеспечение может быть протестировано для проверки его общей функциональности, около 70–80 % ошибок обнаруживаются на ранних этапах тестирования с использованием данного метода. Необходимо отметить, что задачи тестирования функциональности и бизнес-логики имеют высший приоритет. Очевидно, что нахождение функциональных ошибок, таких как дефектный алгоритм сортировки или поиск, оказывающих существенное влияние на процесс работы конечных пользователей оказываются важнее проблем, возникших в ходе локализации и интернационализации. Только после того, как все функциональные дефекты будут обнаружены и исправлены, при наличии временных ресурсов и отсутствии других приоритетов можно сфокусироваться на совершенствовании UI/UX – одной из главных проблем локализации. Несмотря на относительно низкий приоритет подобных дефектов, ошибки негативно сказываются на впечатлении о продукте. Проведение бета-тестирования приложения в различных регионах является распространенной практикой. Например в Китае приложение должно быть протестировано представителями различных провинций, поскольку культурные и языковые различия значительно влияют на восприятие продукта пользователями.
Автоматизация адаптационного тестирования
Для сокращения времени, необходимого для добавления новой локализации и выполнения регрессионного тестирования долгосрочных проектов, тестирование локализации может быть автоматизировано. Использование автоматизации в процессе тестирования наиболее оправдано в следующих случаях:
– Стабильность функциональности. Недостатки применения автоматизации в основном связаны с необходимостью поддержки тестовых скриптов. Если специфика проекта предполагает частую смену требований с последующим изменением существующей функциональности, обновление тестов и отладка тестового фреймворка может занимать значительную часть времени. В таком случае экономически выгодно использовать ручное тестирование.
– Длинный жизненный цикл продукта позволяет разработать и отладить тестовый фреймворк и оценить частоту и эффективность его использования. Разработка тестовых скриптов для проекта с непродолжительным жизненным циклом нецелесообразна, так как отнимается время на проведение тестов новой функциональности.
– Автоматизированные сценарии переносимы и могут быть повторно использованы на другой платформе: тестовый фреймворк должен поддерживать кроссбраузерное и кроссплатформенное тестирование, что особенно критично для приложения, построенного с ориентацией на интернационализацию. Если созданные скрипты подходят только для одного языка и одной конкретной платформы, тестовый фреймворк не будет иметь большой пользы для общей стратегии запуска.
Автоматизированное тестирование позволяет решить следующие задачи: 1) сравнение различных версий продукта в рамках регрессионного тестирования; 2) сравнение локализованных страниц приложения с эталоном на исходном языке. В процессе адаптационного тестирования следует избегать использования инструментов записи и воспроизведения сценариев в связи с особенностями построения локализованного приложения: положение элементов отличается от исходного, поскольку большинство языковых строк будет короче или длиннее строк исходного языка. Таким образом, тестовые скрипты, созданные с помощью инструментов записи, требуют постоянной поддержки и могут быть использованы только для тестирования исходного проекта. Рассмотрим основные подходы создания тестового фреймворка для локализованного приложения:
– Стратегии поиска элементов. Некоторые сложности вызывает определение локаторов элемента для тестирования, к примеру, средствами Selenium. Распространенный подход нахождения элемента по тексту оказывается неэффективным при использовании скриптов для локализованного приложения. Для успешного проведения тестирования необходимо выработать единую стратегию определения элемента на странице, что также сказывается на процессе написания тестовых сценариев.
– Поиск элемента по порядковому номеру. Локализации элемента по данному принципу в общем случае следует избегать, так как крайне вероятно изменение структуры страницы, однако для локализованного приложения положение элемента в DOM не должно меняться при переводе приложения на другой язык. Вместо поиска элемента по тексту ссылки, локатор должен учитывать положение элемента в родительском контейнере. Разумеется, данный подход не является идеальным решением и может быть применен для относительно стабильных участков функциональности, например, в навигационном меню.
– Поиск элемента по id. Наиболее простым и надежным способом нахождения элемента является поиск по атрибуту id, однако далеко не все элементы страницы могут содержать данный атрибут.
– Создание файлов ресурсов. После создания тестовых скриптов для приложения на исходном языке, производится замена литералов на константы, хранящиеся в файле ресурсов. Затем создаются соответствующие файлы ресурсов для целевых языков, назначая локализованные термины константам, созданным на предыдущих шагах. Для создания файлов ресурсов обязательно использование систем машинного перевода, в противном случае сверка данных займет продолжительное время.
– Применение инструментов автоматизации тестирования верстки сравнением скриншотов.
Заключение
Работа над локализацией приложения не ограничивается переводом интерфейса и включает в себя подробный анализ исходного продукта, состояния рынка информационных технологий и опыта пользователей целевого региона. Зачастую локализация подразумевает в том числе переработку интерфейса приложения и добавление новой функциональности. Процесс тестирования должен быть организован таким образом, чтобы разделить работу по обнаружению функциональных дефектов и ошибок локализации, что позволяет наиболее эффективно приоритезировать работу над обнаруженными недостатками, применение различных средств автоматизации позволяет оптимизировать процесс регрессионного тестирования.
Библиографическая ссылка
Ананченко И.В., Распопа Е.А., Хаджиев И.В. ПРАКТИКИ ТЕСТИРОВАНИЯ В СФЕРЕ ЛОКАЛИЗАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Современные наукоемкие технологии. – 2018. – № 7. – С. 9-13;URL: https://top-technologies.ru/ru/article/view?id=37070 (дата обращения: 19.04.2024).