On the role of _Alban in testing
Someone probably remembers that in 2012 2GIS went beyond the CIS and appeared in Padua, Italy . This was the first release of our product abroad and not in the familiar and native Russian language.
Since before that 2GIS was published only in Russian-speaking cities, the release in Italy became a new experience for almost all departments of the company. It was necessary to fill out a guide, draw a map, understand how to promote the product. And for the first time, developers and testers faced the task of internationalizing an application.
The 2GIS Online team had a lot to do:
- Test and develop in parallel with the translation of the interface and the collection of content, i.e. not having ready data in Italian;
- To teach automated tests to work with interfaces in a new language;
- rebuild processes so that the release of new features and new languages takes a minimum of time and human costs;
- in the end, release the product without breaking deadlines.
Challenge, as they say, accepted. Looking ahead, we say that all of the above was completed, and the experience and best practices gained were used in the following foreign projects. Later 2GIS came out in Cyprus , in the Czech Republic , a couple more countries are on the way. But now we will return to the past and tell how the 2GIS Online testing team solved the tasks.
Each tester daily builds versions of the application several times daily, so it is important that the deployment of translation packages (locales) takes a minimum of time and effort.
Therefore, the first thing the testers did was to coordinate with the development requirements for installing / adding / removing locales. And here is how it was implemented: to add a new locale or build an application in the desired language, it is enough to add one line to the config and run one command. All translation data is added to one directory, in case of a translation error, you can find its cause in a specific place. Gettext
was used to translate the product . Verification of the application itself consists of several stages: 1. Verify that everything is translated.
2. Check that translations of text elements do not break the layout.
3. Check that the application is understandable to a foreign user - the texts are consistent and literate.
You can verify the absence of untranslated elements by a full viewing of the application. To do this, the application must be compiled in a language other than the original one. The biggest difficulty at this stage is to check as quickly as possible, and, as a rule, when there are no transfers yet. As we mentioned at the beginning, the process of translating texts goes in parallel with the development and testing of the product. And here's the bad luck - you already need to test, but there are no texts in the right language yet. The solution is to replace them with something. Therefore, we used pseudolocalization.
Here's what we did: testers, with the help of developers, assembled a new “language” from Russian translations - changed all text elements, adding 3 characters to the beginning, turned the pictures 180 degrees, changed the domain zone in the .ru links to .it.
This locale was called “Albanian” and helped testing to detect all untranslated elements almost immediately. And adding characters to the beginning changed the length of the text elements, which allowed us to check at the same time the effect of possible text changes on the layout.
Iteration was carried out in browsers, where problems most often arise (so as not to waste time on numerous cross-browser checks) - in Opera and IE.
Thus, in one iteration of testing, using pseudo-localization based on the source data and checking in “sensitive” browsers, we were able to solve two problems at once - to find all the places where the translations were missed and to find the weak points of the layout.
The third task is to check the adequacy, literacy, and consistency of texts, as a rule, performed by the tester. But only if these texts are not in a foreign language.
If the state does not have a polyglot tester, native speakers will cope with this task most qualitatively. For example, in 2GIS Online, the role of reviewers is played by an internal adaptation group of international projects and foreign partners.
When a new locale is added or a new localized feature is released, a draft version of the application is transferred to the adaptation group. This step is called “proofreading” and has fixed fixed deadlines.
The task of the development team is to make timely corrections of the texts and release the product.
In addition to language, for specific countries there are many functional features (features of displaying decimal numbers, dates, and other measures). These features require additional serious research. Therefore, such nuances are also in the area of responsibility of the customer (adaptation group). They are implemented, validated and issued as normal functional product requirements.
No matter how ironic the arrangements for the timing of the provision of transfers, they can be disrupted. Even if everything worked perfectly, no one cancels the probability of some force majeure. Therefore, the team must have a “Plan B” in case of release features without translations. The development of 2GIS Online translates such missing texts into English. If the feature is large and there should be a lot of transfers, a decision is made to postpone its release.
The task of adapting autotests for checking localized versions was solved in two stages. The first is debugging the tests themselves, taking into account the features of the functionality of localized versions. The second is simplification of work with input / output data.
The functionality of the localized versions is slightly different (on the Italian version you do not need to show Russian promo banners, or in some countries we do not support the search for directions).
Therefore, the first thing the employees of the testing team did was to analyze the entire functionality of the application and identify two parts - the general functionality and the specific one for the locale.
Search for directions
All tests that test the general functionality must be debugged to test foreign versions. The differences are to add tests, and configure them so that they run only on the desired locale. To determine which locale should run the tests, we used grouping of tests.
Now you need to teach the tests to work with foreign input / output data.
To adapt the input / output data in the test framework, you need to highlight the level of abstraction - classes with translations of all texts and methods that receive these translations for the desired locale.
An example of a test running on two locales:
The test opens 2gis.ru, selects Novosibirsk.
In the field "What" enters "Pizza", in the field "Where" enters "Novosibirsk" and performs a search.
It was:
Now:
Test:
Translations are taken from classes:
The language is defined in the test config:
This solution makes it very easy to extend tests for new locales. When adding a new language, you need to create a “dictionary” of translations for it:
Add group to general tests:
And add tests for specific functionality for this locale.
Thus, solving the problem of checking the first foreign version of 2GIS Online in Padua , we learned how to check new features before translations appear, quickly release versions for new countries, and adapt existing automatic tests in several steps to check them.
Today, the app comes in four languages in six countries. And, thanks to these developments, the release of each new locale takes no more than 1 week, and testing takes a maximum of 2 days.
Since before that 2GIS was published only in Russian-speaking cities, the release in Italy became a new experience for almost all departments of the company. It was necessary to fill out a guide, draw a map, understand how to promote the product. And for the first time, developers and testers faced the task of internationalizing an application.
The 2GIS Online team had a lot to do:
- Test and develop in parallel with the translation of the interface and the collection of content, i.e. not having ready data in Italian;
- To teach automated tests to work with interfaces in a new language;
- rebuild processes so that the release of new features and new languages takes a minimum of time and human costs;
- in the end, release the product without breaking deadlines.
Challenge, as they say, accepted. Looking ahead, we say that all of the above was completed, and the experience and best practices gained were used in the following foreign projects. Later 2GIS came out in Cyprus , in the Czech Republic , a couple more countries are on the way. But now we will return to the past and tell how the 2GIS Online testing team solved the tasks.
How we tested the internationalization of the project
Each tester daily builds versions of the application several times daily, so it is important that the deployment of translation packages (locales) takes a minimum of time and effort.
Therefore, the first thing the testers did was to coordinate with the development requirements for installing / adding / removing locales. And here is how it was implemented: to add a new locale or build an application in the desired language, it is enough to add one line to the config and run one command. All translation data is added to one directory, in case of a translation error, you can find its cause in a specific place. Gettext
was used to translate the product . Verification of the application itself consists of several stages: 1. Verify that everything is translated.
2. Check that translations of text elements do not break the layout.
3. Check that the application is understandable to a foreign user - the texts are consistent and literate.
You can verify the absence of untranslated elements by a full viewing of the application. To do this, the application must be compiled in a language other than the original one. The biggest difficulty at this stage is to check as quickly as possible, and, as a rule, when there are no transfers yet. As we mentioned at the beginning, the process of translating texts goes in parallel with the development and testing of the product. And here's the bad luck - you already need to test, but there are no texts in the right language yet. The solution is to replace them with something. Therefore, we used pseudolocalization.
Here's what we did: testers, with the help of developers, assembled a new “language” from Russian translations - changed all text elements, adding 3 characters to the beginning, turned the pictures 180 degrees, changed the domain zone in the .ru links to .it.
This locale was called “Albanian” and helped testing to detect all untranslated elements almost immediately. And adding characters to the beginning changed the length of the text elements, which allowed us to check at the same time the effect of possible text changes on the layout.
Iteration was carried out in browsers, where problems most often arise (so as not to waste time on numerous cross-browser checks) - in Opera and IE.
Thus, in one iteration of testing, using pseudo-localization based on the source data and checking in “sensitive” browsers, we were able to solve two problems at once - to find all the places where the translations were missed and to find the weak points of the layout.
The third task is to check the adequacy, literacy, and consistency of texts, as a rule, performed by the tester. But only if these texts are not in a foreign language.
If the state does not have a polyglot tester, native speakers will cope with this task most qualitatively. For example, in 2GIS Online, the role of reviewers is played by an internal adaptation group of international projects and foreign partners.
When a new locale is added or a new localized feature is released, a draft version of the application is transferred to the adaptation group. This step is called “proofreading” and has fixed fixed deadlines.
The task of the development team is to make timely corrections of the texts and release the product.
In addition to language, for specific countries there are many functional features (features of displaying decimal numbers, dates, and other measures). These features require additional serious research. Therefore, such nuances are also in the area of responsibility of the customer (adaptation group). They are implemented, validated and issued as normal functional product requirements.
No matter how ironic the arrangements for the timing of the provision of transfers, they can be disrupted. Even if everything worked perfectly, no one cancels the probability of some force majeure. Therefore, the team must have a “Plan B” in case of release features without translations. The development of 2GIS Online translates such missing texts into English. If the feature is large and there should be a lot of transfers, a decision is made to postpone its release.
How we translated automated tests
The task of adapting autotests for checking localized versions was solved in two stages. The first is debugging the tests themselves, taking into account the features of the functionality of localized versions. The second is simplification of work with input / output data.
The functionality of the localized versions is slightly different (on the Italian version you do not need to show Russian promo banners, or in some countries we do not support the search for directions).
Therefore, the first thing the employees of the testing team did was to analyze the entire functionality of the application and identify two parts - the general functionality and the specific one for the locale.
Search for directions
 |  |  |  |
|---|---|---|---|
| Is hidden | there is | there is | Not |
All tests that test the general functionality must be debugged to test foreign versions. The differences are to add tests, and configure them so that they run only on the desired locale. To determine which locale should run the tests, we used grouping of tests.
Now you need to teach the tests to work with foreign input / output data.
To adapt the input / output data in the test framework, you need to highlight the level of abstraction - classes with translations of all texts and methods that receive these translations for the desired locale.
An example of a test running on two locales:
The test opens 2gis.ru, selects Novosibirsk.
In the field "What" enters "Pizza", in the field "Where" enters "Novosibirsk" and performs a search.
It was:
public function testSearchFirms()
{
$this->page->selectCity('Новосибирск');
$this->page->searchForm->send(array('what' => 'Пицца', 'where' => 'Новосибирск'));
}
Now:
Test:
/**
* @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')));
}
Translations are taken from classes:
msg_it.php
msg_ru.php
The language is defined in the test config:
This solution makes it very easy to extend tests for new locales. When adding a new language, you need to create a “dictionary” of translations for it:
msg_.php,
Add group to general tests:
@group And add tests for specific functionality for this locale.
Thus, solving the problem of checking the first foreign version of 2GIS Online in Padua , we learned how to check new features before translations appear, quickly release versions for new countries, and adapt existing automatic tests in several steps to check them.
Today, the app comes in four languages in six countries. And, thanks to these developments, the release of each new locale takes no more than 1 week, and testing takes a maximum of 2 days.