On the role of Albanian in testing
Someone for certain remembers that in 2012 2GIS went beyond the borders of the CIS and appeared in the Italian Padua . This was the first release of our product abroad and not in the familiar and native Russian language.
Since before 2GIS was released 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 the directory, draw a map, understand how to promote the product. For the first time, developers and testers were faced with the task of internationalizing the application.
Team 2GIS Online had to do a lot:
')
- To test and develop in parallel with the translation of the interface and the collection of content, i.e. not having ready data in Italian;
- 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, to release the product without breaking the deadlines.
Challenge, as they say, is accepted. Looking ahead, we say that all of the above was done, and the experience and achievements gained were used in the following foreign projects. Later, 2GIS came out in Cyprus , in the Czech Republic , on the way a couple more countries. But now we will return to the past and tell you how the 2GIS Online testing team solved its tasks.
Each tester performs several times daily builds of application versions, so it is important that the deployment of translation packages (locales) takes a minimum of time and effort.
Therefore, the first thing testers did was to coordinate with the development of requirements for installing / adding / removing locales. And this 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 transfer data is added to one directory; in case of a translation error, you can find its reason in a specific place.
Gettext was used to translate the product.
Checking the application itself consists of several steps:
1. Check that everything is translated.
2. Check that translations of text elements do not break the layout.
3. Check that the application is clear to a foreign user - the texts are consistent and literate.
You can make sure that there are no untranslated elements by viewing the entire application. To do this, the application must be built in a language other than the original. The biggest difficulty at this stage is to check it as quickly as possible, and, as a rule, when there are no translations yet. As we mentioned at the beginning, the process of translating texts goes in parallel with the development and testing of the product. And the thing is - test is already necessary, but there are no texts in the necessary language yet. The solution is to replace them with something. Therefore, we used pseudolocalization.
Here is what we did: testers, with the help of developers, collected a new “language” from Russian translations - changed all text elements, added 3 characters to the beginning, turned pictures 180 degrees, changed the domain zone in .ru links to .it.
This locale was called “Albanian” and helped testing discover all untranslated elements almost immediately. And adding characters to the beginning changed the length of the text elements, which allowed at the same time to check the effect of possible text changes on the layout.
The 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, for one iteration of testing, using pseudolocalization on the basis of the original data and checking in “sensitive” browsers, we were able to solve two problems at once - to find all the places where translations are missed, and to find the weak points of the layout.
The third task - checking the adequacy, literacy, consistency of the texts, as a rule, performs the tester. But only if these texts are not in a foreign language.
If there is no polyglot tester in the state, the native speakers will cope with this task more qualitatively. For example, in 2GIS Online, the role of inspectors is performed by the internal adaptation team 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 stage is called “proofreading” and it has fixed deadlines in advance.
The task of the development team is to ensure timely correction of texts and release the product.
In addition to language, for specific countries there are many functional features (features display 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, verified and released as normal functional product requirements.
Whatever iron agreements on the timing of the provision of transfers, they can be broken. Even if everything worked perfectly, no one cancels the likelihood of any force majeure. Therefore, the team must have a “Plan B” in case of the release of features without transfers. Development of 2GIS Online translates such missing texts into English. If the feature is large and there should be a lot of translations, a decision is made to postpone its release.
We solved the task of adapting autotests for checking localized versions in two stages. The first is the debugging of the tests themselves, taking into account the features of the functionality of localized versions. The second is to simplify work with input / output data.
The functionality of localized versions is somewhat different between each other (in the Italian version, Russian promo banners are not necessary to show, or in some countries we do not support the search for directions).
Therefore, the first thing that the employees of the testing team did was to analyze the entire functionality of the application and select two parts - the general functionality and locale-specific.
Location Search
All tests checking the general functionality need to be debugged to test foreign versions. The differences - add tests, and configure so that they run only on the desired locale. To determine in which locale the tests should work, test grouping was used.
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 select 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 that works in two locales:
Test opens 2gis.ru, chooses Novosibirsk.
Enter “Pizza” in the “What” field, enter “Novosibirsk” in the “Where” field and perform a search.
It was:
It became:
Test:
Translations are taken from classes:
The language is defined in the test configuration:
This solution makes it very easy to extend tests for new locales. Adding a new language, you need to create for it a “dictionary” of translations:
Add a group to common tests:
And add tests for a specific locale-specific functionality.
Thus, solving the problem of checking the first foreign version of 2GIS Online in Padua , we learned how to check new features before the advent of translations, promptly release versions for new countries and adapt existing auto tests to test them in several steps.
Today, the application is available 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 2GIS was released 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 the directory, draw a map, understand how to promote the product. For the first time, developers and testers were faced with the task of internationalizing the application.
Team 2GIS Online had to do a lot:
')
- To test and develop in parallel with the translation of the interface and the collection of content, i.e. not having ready data in Italian;
- 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, to release the product without breaking the deadlines.
Challenge, as they say, is accepted. Looking ahead, we say that all of the above was done, and the experience and achievements gained were used in the following foreign projects. Later, 2GIS came out in Cyprus , in the Czech Republic , on the way a couple more countries. But now we will return to the past and tell you how the 2GIS Online testing team solved its tasks.
How we tested project internationalization
Each tester performs several times daily builds of application versions, so it is important that the deployment of translation packages (locales) takes a minimum of time and effort.
Therefore, the first thing testers did was to coordinate with the development of requirements for installing / adding / removing locales. And this 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 transfer data is added to one directory; in case of a translation error, you can find its reason in a specific place.
Gettext was used to translate the product.
Checking the application itself consists of several steps:
1. Check that everything is translated.
2. Check that translations of text elements do not break the layout.
3. Check that the application is clear to a foreign user - the texts are consistent and literate.
You can make sure that there are no untranslated elements by viewing the entire application. To do this, the application must be built in a language other than the original. The biggest difficulty at this stage is to check it as quickly as possible, and, as a rule, when there are no translations yet. As we mentioned at the beginning, the process of translating texts goes in parallel with the development and testing of the product. And the thing is - test is already necessary, but there are no texts in the necessary language yet. The solution is to replace them with something. Therefore, we used pseudolocalization.
Here is what we did: testers, with the help of developers, collected a new “language” from Russian translations - changed all text elements, added 3 characters to the beginning, turned pictures 180 degrees, changed the domain zone in .ru links to .it.
This locale was called “Albanian” and helped testing discover all untranslated elements almost immediately. And adding characters to the beginning changed the length of the text elements, which allowed at the same time to check the effect of possible text changes on the layout.
The 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, for one iteration of testing, using pseudolocalization on the basis of the original data and checking in “sensitive” browsers, we were able to solve two problems at once - to find all the places where translations are missed, and to find the weak points of the layout.
The third task - checking the adequacy, literacy, consistency of the texts, as a rule, performs the tester. But only if these texts are not in a foreign language.
If there is no polyglot tester in the state, the native speakers will cope with this task more qualitatively. For example, in 2GIS Online, the role of inspectors is performed by the internal adaptation team 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 stage is called “proofreading” and it has fixed deadlines in advance.
The task of the development team is to ensure timely correction of texts and release the product.
In addition to language, for specific countries there are many functional features (features display 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, verified and released as normal functional product requirements.
Whatever iron agreements on the timing of the provision of transfers, they can be broken. Even if everything worked perfectly, no one cancels the likelihood of any force majeure. Therefore, the team must have a “Plan B” in case of the release of features without transfers. Development of 2GIS Online translates such missing texts into English. If the feature is large and there should be a lot of translations, a decision is made to postpone its release.
How we translated automated tests
We solved the task of adapting autotests for checking localized versions in two stages. The first is the debugging of the tests themselves, taking into account the features of the functionality of localized versions. The second is to simplify work with input / output data.
The functionality of localized versions is somewhat different between each other (in the Italian version, Russian promo banners are not necessary to show, or in some countries we do not support the search for directions).
Therefore, the first thing that the employees of the testing team did was to analyze the entire functionality of the application and select two parts - the general functionality and locale-specific.
Location Search
 |  |  |  |
|---|---|---|---|
| Is hidden | there is | there is | Not |
All tests checking the general functionality need to be debugged to test foreign versions. The differences - add tests, and configure so that they run only on the desired locale. To determine in which locale the tests should work, test grouping was used.
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 select 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 that works in two locales:
Test opens 2gis.ru, chooses Novosibirsk.
Enter “Pizza” in the “What” field, enter “Novosibirsk” in the “Where” field and perform a search.
It was:
public function testSearchFirms() { $this->page->selectCity(''); $this->page->searchForm->send(array('what' => '', 'where' => '')); } It became:
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 <?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; ?> The language is defined in the test configuration:
<phpunit bootstrap="bootstrap.php" colors="true" > <php> <const name="LOCALE" value="ru"/> </php> This solution makes it very easy to extend tests for new locales. Adding a new language, you need to create for it a “dictionary” of translations:
msg_<lang>.php, Add a group to common tests:
@group <lang> And add tests for a specific locale-specific functionality.
Thus, solving the problem of checking the first foreign version of 2GIS Online in Padua , we learned how to check new features before the advent of translations, promptly release versions for new countries and adapt existing auto tests to test them in several steps.
Today, the application is available 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.
Source: https://habr.com/ru/post/215613/
All Articles