Кто-то наверняка помнит, что в 2012 году 2ГИС вышел за пределы СНГ и появился в итальянской Падуе. Это был первый релиз нашего продукта за рубежом и не на привычном и родном русском языке.
Поскольку до этого 2ГИС выходил только в русскоговорящих городах, релиз в Италии стал новым опытом практически для всех отделов компании. Нужно было наполнить справочник, нарисовать карту, понять, как продвигать продукт. А разработчики и тестировщики впервые столкнулись с задачей интернационализации приложения.
Команде 2ГИС Онлайн делать предстояло немало:
— Тестировать и разрабатывать параллельно с переводом интерфейса и сбором контента, т.е. не имея готовых данных на итальянском языке;
— научить автоматизированные тесты работать с интерфейсами на новом языке;
— перестроить процессы так, чтобы выпуск новых фич и новых языков занимал минимум времени и человекозатрат;
— в конце концов, выпустить продукт, не сорвав сроки.
Challenge, как говорится, accepted. Забегая вперед, скажем, что всё вышеописанное было выполнено, а полученный опыт и наработки использовались в следующих зарубежных проектах. Позже 2ГИС вышел на Кипре, в Чехии, на подходе еще пара стран. Но сейчас мы вернемся в прошлое и расскажем, как команда тестирования 2ГИС Онлайн решала поставленные задачи.
Каждый тестировщик ежедневно по несколько раз выполняет сборки версий приложения, поэтому важно, чтобы разворачивание пакетов переводов (локалей) занимало минимум времени и усилий.
Поэтому, первое, что сделали тестировщики — согласовали с разработкой требования к установке/добавлению/удалению локалей. И вот как это было реализовано: для добавления новой локали или сборки приложения на нужном языке, достаточно дописать одну строчку в конфиг и запустить одну команду. Все данные переводов складываются в одну директорию, в случае ошибки перевода найти ее причину можно в конкретном месте.
Для перевода продукта был использован Gettext.
Проверка самого приложения состоит из нескольких этапов:
1. Проверить, что переведено всё.
2. Проверить, что переводы текстовых элементов не ломают верстку.
3. Проверить, что приложение понятно иностранному пользователю — тексты согласованы и грамотны.
Убедиться в отсутствии непереведенных элементов можно полным просмотром приложения. Для этого приложение должно быть собрано на языке, отличном от исходного. Самая большая сложность на этом этапе — проверить нужно как можно быстрее, и, как правило, тогда, когда переводов еще нет. Как мы упоминали в начале, процесс перевода текстов идет параллельно с разработкой и тестированием продукта. И вот незадача — тестировать уже нужно, но текстов на нужном языке еще нет. Решение — заменить их чем-нибудь. Поэтому мы использовали псевдолокализацию.
Вот что мы сделали: тестировщики, с помощью разработчиков, собрали новый “язык” из русских переводов — изменили все текстовые элементы, добавив 3 символа в начало, перевернули картинки на 180 градусов, изменили доменную зону в ссылках .ru на .it.
Эта локаль получила название “албанской” и помогла тестированию обнаружить все непереведенные элементы практически сразу. А добавление символов в начало изменило длину текстовых элементов, что позволило заодно проверить влияние возможных изменений текста на верстку.
Итерацию провели в браузерах, где чаще всего возникают проблемы (чтобы не тратить время на многочисленные кроссбраузерные проверки) — в Опере и IE.
Таким образом, за одну итерацию тестирования, используя псевдолокализацию на основе исходных данных и проверяя в “чувствительных” браузерах, мы смогли решить сразу две задачи — найти все места, где пропущены переводы, и найти слабые места верстки.
Третью задачу — проверку адекватности, грамотности, согласованности текстов, как правило, выполняет тестировщик. Но только, если эти тексты не на иностранном языке.
Если в штате нет тестировщика-полиглота, качественнее всех с этой задачей справятся носители языка. К примеру, в 2ГИС Онлайн роль проверяющих выполняет внутренняя группа адаптации международных проектов и иностранные партнеры.
Когда добавляется новая локаль или выпускается новая локализованная фича, в группу адаптации передается черновая версия приложения. Этот этап называется “вычитка” и имеет заранее оговоренные фиксированные сроки.
Задача команды разработки сводится к тому, чтобы своевременно внести исправления текстов и выпустить продукт.
Кроме языковых, для конкретных стран есть много функциональных особенностей (особенности отображения десятичных чисел, дат, и других мер). Эти особенности требуют дополнительного серьезного исследования. Поэтому такие нюансы тоже в зоне ответственности заказчика (группы адаптации). Они реализуются, проверяются и выпускаются как обычные функциональные продуктовые требования.
Какими бы железными ни были договоренности о сроках предоставления переводов, они могут быть сорваны. Даже если все сработали идеально, никто не отменяет вероятности какого-нибудь форсмажора. Поэтому команда должна иметь “План Б” на случай выпуска фичи без переводов. Разработка 2ГИС Онлайн такие недостающие тексты переводит на английский. Если фича большая и переводов должно быть много, принимается решение о переносе ее выпуска.
Задачу адаптации автотестов для проверки локализованных версий мы решали в два этапа. Первый — отладка самих тестов с учетом особенностей функционала локализованных версий. Второй — упрощение работы с входными/выходными данными.
Функционал локализованных версий несколько отличается между собой (на итальянской версии не нужно показывать русские промо-баннеры, или в некоторых странах мы не поддерживаем поиск проезда).
Поэтому первое, что сделали сотрудники команды тестирования — проанализировали весь функционал приложения и выделили две части — общий функционал и специфичный для локали.
Поиск проезда
Все тесты, проверяющие общий функционал, нужно отладить для тестирования иностранных версий. На отличия — дописать тесты, и настроить так, чтобы они запускались только на нужной локали. Для определения, в какой локали должны работать тесты, использовали группирование тестов.
Теперь нужно научить тесты работать с иностранными входными/выходными данными.
Для адаптации входных/выходных данных в тестовом фреймворке нужно выделить уровень абстракции — классы с переводами всех текстов и методами, получающими эти переводы для нужной локали.
Пример теста, работающего на двух локалях:
Тест открывает 2gis.ru, выбирает Новосибирск.
В поле «Что» вводит «Пицца», в поле «Где» вводит «Новосибирск» и выполняет поиск.
Было:
Стало:
Тест:
Переводы берутся из классов:
Язык определяется в конфиге тестов:
Это решение позволяет очень просто расширять тесты для новых локалей. Добавляя новый язык, нужно создать для него “словарь” переводов:
Добавить группу в общие тесты:
И дописать тесты на специфичный для данной локали функционал.
Таким образом, решая задачу проверки первой иностранной версии 2ГИС Онлайн в Падуе, мы научились проверять новые фичи до появления переводов, оперативно выпускать версии для новых стран и адаптировать для их проверки имеющиеся автотесты за несколько шагов.
Сегодня приложение выходит на четырех языках в шести странах. И, благодаря этим наработкам, выпуск каждой новой локали занимает не более 1 недели, а тестирование занимает максимум 2 дня.
Поскольку до этого 2ГИС выходил только в русскоговорящих городах, релиз в Италии стал новым опытом практически для всех отделов компании. Нужно было наполнить справочник, нарисовать карту, понять, как продвигать продукт. А разработчики и тестировщики впервые столкнулись с задачей интернационализации приложения.
Команде 2ГИС Онлайн делать предстояло немало:
— Тестировать и разрабатывать параллельно с переводом интерфейса и сбором контента, т.е. не имея готовых данных на итальянском языке;
— научить автоматизированные тесты работать с интерфейсами на новом языке;
— перестроить процессы так, чтобы выпуск новых фич и новых языков занимал минимум времени и человекозатрат;
— в конце концов, выпустить продукт, не сорвав сроки.
Challenge, как говорится, accepted. Забегая вперед, скажем, что всё вышеописанное было выполнено, а полученный опыт и наработки использовались в следующих зарубежных проектах. Позже 2ГИС вышел на Кипре, в Чехии, на подходе еще пара стран. Но сейчас мы вернемся в прошлое и расскажем, как команда тестирования 2ГИС Онлайн решала поставленные задачи.
Как мы тестировали интернационализацию проекта
Каждый тестировщик ежедневно по несколько раз выполняет сборки версий приложения, поэтому важно, чтобы разворачивание пакетов переводов (локалей) занимало минимум времени и усилий.
Поэтому, первое, что сделали тестировщики — согласовали с разработкой требования к установке/добавлению/удалению локалей. И вот как это было реализовано: для добавления новой локали или сборки приложения на нужном языке, достаточно дописать одну строчку в конфиг и запустить одну команду. Все данные переводов складываются в одну директорию, в случае ошибки перевода найти ее причину можно в конкретном месте.
Для перевода продукта был использован Gettext.
Проверка самого приложения состоит из нескольких этапов:
1. Проверить, что переведено всё.
2. Проверить, что переводы текстовых элементов не ломают верстку.
3. Проверить, что приложение понятно иностранному пользователю — тексты согласованы и грамотны.
Убедиться в отсутствии непереведенных элементов можно полным просмотром приложения. Для этого приложение должно быть собрано на языке, отличном от исходного. Самая большая сложность на этом этапе — проверить нужно как можно быстрее, и, как правило, тогда, когда переводов еще нет. Как мы упоминали в начале, процесс перевода текстов идет параллельно с разработкой и тестированием продукта. И вот незадача — тестировать уже нужно, но текстов на нужном языке еще нет. Решение — заменить их чем-нибудь. Поэтому мы использовали псевдолокализацию.
Вот что мы сделали: тестировщики, с помощью разработчиков, собрали новый “язык” из русских переводов — изменили все текстовые элементы, добавив 3 символа в начало, перевернули картинки на 180 градусов, изменили доменную зону в ссылках .ru на .it.
Эта локаль получила название “албанской” и помогла тестированию обнаружить все непереведенные элементы практически сразу. А добавление символов в начало изменило длину текстовых элементов, что позволило заодно проверить влияние возможных изменений текста на верстку.
Итерацию провели в браузерах, где чаще всего возникают проблемы (чтобы не тратить время на многочисленные кроссбраузерные проверки) — в Опере и IE.
Таким образом, за одну итерацию тестирования, используя псевдолокализацию на основе исходных данных и проверяя в “чувствительных” браузерах, мы смогли решить сразу две задачи — найти все места, где пропущены переводы, и найти слабые места верстки.
Третью задачу — проверку адекватности, грамотности, согласованности текстов, как правило, выполняет тестировщик. Но только, если эти тексты не на иностранном языке.
Если в штате нет тестировщика-полиглота, качественнее всех с этой задачей справятся носители языка. К примеру, в 2ГИС Онлайн роль проверяющих выполняет внутренняя группа адаптации международных проектов и иностранные партнеры.
Когда добавляется новая локаль или выпускается новая локализованная фича, в группу адаптации передается черновая версия приложения. Этот этап называется “вычитка” и имеет заранее оговоренные фиксированные сроки.
Задача команды разработки сводится к тому, чтобы своевременно внести исправления текстов и выпустить продукт.
Кроме языковых, для конкретных стран есть много функциональных особенностей (особенности отображения десятичных чисел, дат, и других мер). Эти особенности требуют дополнительного серьезного исследования. Поэтому такие нюансы тоже в зоне ответственности заказчика (группы адаптации). Они реализуются, проверяются и выпускаются как обычные функциональные продуктовые требования.
Какими бы железными ни были договоренности о сроках предоставления переводов, они могут быть сорваны. Даже если все сработали идеально, никто не отменяет вероятности какого-нибудь форсмажора. Поэтому команда должна иметь “План Б” на случай выпуска фичи без переводов. Разработка 2ГИС Онлайн такие недостающие тексты переводит на английский. Если фича большая и переводов должно быть много, принимается решение о переносе ее выпуска.
Как мы перевели автоматизированные тесты
Задачу адаптации автотестов для проверки локализованных версий мы решали в два этапа. Первый — отладка самих тестов с учетом особенностей функционала локализованных версий. Второй — упрощение работы с входными/выходными данными.
Функционал локализованных версий несколько отличается между собой (на итальянской версии не нужно показывать русские промо-баннеры, или в некоторых странах мы не поддерживаем поиск проезда).
Поэтому первое, что сделали сотрудники команды тестирования — проанализировали весь функционал приложения и выделили две части — общий функционал и специфичный для локали.
Поиск проезда
 |
 |
 |
 |
|---|---|---|---|
| Скрыт | Есть | Есть | Нет |
Все тесты, проверяющие общий функционал, нужно отладить для тестирования иностранных версий. На отличия — дописать тесты, и настроить так, чтобы они запускались только на нужной локали. Для определения, в какой локали должны работать тесты, использовали группирование тестов.
Теперь нужно научить тесты работать с иностранными входными/выходными данными.
Для адаптации входных/выходных данных в тестовом фреймворке нужно выделить уровень абстракции — классы с переводами всех текстов и методами, получающими эти переводы для нужной локали.
Пример теста, работающего на двух локалях:
Тест открывает 2gis.ru, выбирает Новосибирск.
В поле «Что» вводит «Пицца», в поле «Где» вводит «Новосибирск» и выполняет поиск.
Было:
public function testSearchFirms()
{
$this->page->selectCity('Новосибирск');
$this->page->searchForm->send(array('what' => 'Пицца', 'where' => 'Новосибирск'));
}
Стало:
Тест:
/**
* @group ru
* @group it
**/
public function testSearchFirms()
{
// Заменили тексты на параметры, получаем их значение методом getText() $this->page->selectCity($this->locale->getText('popular_city'));
$this->page->searchForm->send(array('what' => $this->locale->getText('firms_request'), 'where' => $this->locale->getText('popular_city')));
}
Переводы берутся из классов:
msg_it.php
<?php
$msg = array();
$msg['popular_city'] = 'Padova';
$msg['firms_request'] = 'Pizza';
return $msg;
?>
msg_ru.php
<?php
$msg = array();
$msg['popular_city'] = 'Новосибирск';
$msg['firms_request'] = ’Пицца’;
return $msg;
?>
Язык определяется в конфиге тестов:
<phpunit bootstrap="bootstrap.php" colors="true" >
<php>
<const name="LOCALE" value="ru"/>
</php>
Это решение позволяет очень просто расширять тесты для новых локалей. Добавляя новый язык, нужно создать для него “словарь” переводов:
msg_<lang>.php,
Добавить группу в общие тесты:
@group <lang>
И дописать тесты на специфичный для данной локали функционал.
Таким образом, решая задачу проверки первой иностранной версии 2ГИС Онлайн в Падуе, мы научились проверять новые фичи до появления переводов, оперативно выпускать версии для новых стран и адаптировать для их проверки имеющиеся автотесты за несколько шагов.
Сегодня приложение выходит на четырех языках в шести странах. И, благодаря этим наработкам, выпуск каждой новой локали занимает не более 1 недели, а тестирование занимает максимум 2 дня.