Тестирование локализации в 2026 году: как не сломать продукт при переводе на новый язык

На старте локализация кажется простой: перевели строки, переключили язык, посмотрели пару экранов. Именно в этот момент команды недооценивают масштаб. Перевод на новый язык ломает не только текст: он ломает вёрстку, форматы дат и чисел, поиск, фильтры, сортировку, PDF, письма и иногда бизнес-логику.

Локализация проверяет не отдельные слова, а устойчивость всего продукта к новому языку, другой культуре, другому формату данных и другому способу чтения интерфейса.

В этой статье: что тестировать при локализации, где продукт ломается чаще всего, как использовать псевдолокализацию, что делать с RTL-языками и как встроить L10n-проверку в релизный процесс так, чтобы не ловить сюрпризы после релиза.

Почему локализация ломает больше, чем просто текст

Локализация это не перевод. Это адаптация продукта к конкретному рынку: языку, культуре, форматам данных, юридическим требованиям и пользовательским ожиданиям. Когда команда воспринимает её как «задачу для переводчика», большая часть проблем уходит в продакшн незамеченной.

Когда меняется язык, меняется не только длина строки. Меняются правила чтения, форматы данных, порядок слов, правила переносов, склонения, ожидания пользователя и даже смысл привычных кнопок.

• немецкий и финский раздувают длину строк на 30-40% по сравнению с английским;

• арабский и иврит меняют направление всего интерфейса, справа налево;

• даты, валюта и разделители зависят от страны, а не только от языка;

• одна и та же фраза может потребовать разной грамматики в разных контекстах;

• порядок имени и фамилии различается в разных культурах;

• иероглифические языки (китайский, японский, корейский) требуют особого подхода к переносам и пробелам.

Локализация это проверка не словаря, а всей системы отображения, логики и контекста. Перевод лишь видимая часть айсберга.

Именно поэтому тестирование локализации не «проверка перевода», а полноценная проверка устойчивости продукта к новому языку, новому формату данных и новому способу чтения интерфейса.

i18n и l10n: в чём разница и зачем это знать тестировщику

В профессиональном контексте часто используют два термина, которые легко спутать.

i18n (internationalization, интернационализация) это подготовка кода и архитектуры продукта к тому, чтобы он вообще мог быть локализован. Это работа разработчиков: вынести все строки в ресурсные файлы, настроить поддержку разных кодировок, реализовать механизм смены языка, поддержать RTL-режим на уровне CSS и логики. Без правильной i18n локализация либо невозможна, либо превращается в ад хардкодных заплаток.

l10n (localization, локализация) это конкретная адаптация продукта под конкретный язык и рынок: перевод строк, адаптация форматов дат и валют, замена изображений с культурно-специфичным содержимым, учёт местных правовых требований.

Тестировщику важно понимать оба уровня, потому что баги бывают на обоих. Строка может быть переведена правильно, но дата отображается в неверном формате, это баг i18n. Перевод может быть технически корректным, но звучать неестественно или создавать двусмысленность, это баг l10n.

Что проверять в первую очередь

При ограниченном времени важно начать с критичных зон, тех, где баг будет стоить дороже всего для пользователя и бизнеса.

Где продукт ломается чаще всего

На практике самые проблемные зоны почти всегда одни и те же. Команды снова и снова наступают на одни и те же грабли именно потому, что при разработке продукт проектировался под один язык и никогда не тестировался на растяжение строк, смену направления чтения или смешанные форматы данных.

Обрезанные кнопки и заголовки

Самый визуально очевидный класс багов. Кнопка «Войти» в английском 5 символов. «Iniciar sesión» в испанском уже 14. «Anmelden» в немецком 8, но «Abonnement kündigen» уже 20. Большинство интерфейсов, спроектированных под английский, не предусматривают запас для более длинных языков. Результат обрезанный текст, перенос на несколько строк там, где его быть не должно, или кнопки разной высоты в одном ряду.

Сломанная вёрстка таблиц и карточек

Карточка товара с коротким названием выглядит отлично. Та же карточка с немецким составным существительным Versicherungsgesellschaft ломает сетку. Таблица с колонкой «Status» (6 символов) разваливается, когда та же колонка называется «Estado de procesamiento» (22 символа).

Непереведённые строки в нетипичных состояниях

Happy path переведён. Но строка в состоянии загрузки, в сообщении об ошибке 503, в тултипе редкой настройки или в письме о возврате средств нет. Эти строки всплывают только в конкретных сценариях, которые не попали в основной прогон. Пользователь видит смесь языков и теряет доверие к продукту.

Ошибки в форматировании чисел и дат

Числа, даты и суммы форматируются по разным правилам в разных локалях. Один и тот же баг в формате числа может привести к тому, что пользователь введёт 1 000,00 (немецкий формат), а система интерпретирует это как 1 (обрезав до целого), и такие ошибки не всегда видны в интерфейсе.

Смешение языков в одном потоке

Письмо о подтверждении заказа пришло на английском, хотя интерфейс переключён на французский. Системное уведомление на русском, а интерфейс на казахском. Это не только неудобно, это сигнал пользователю, что продукт «не для него».

Самая опасная ошибка: проверить только happy path на главных экранах и считать, что локализация готова. Настоящие проблемы живут в письмах, ошибках, пустых состояниях, фильтрах и административных сценариях, именно туда доходят до релиза реже всего.

Интерфейсные проверки: длина строк, переносы, переполнение

Если продукт проектировался под один язык, новый язык почти всегда проверит его на прочность. Поэтому локализационное тестирование начинается не с филологии, а с вёрстки.

Практический подход: тест на +40%

Хорошее правило для быстрого выявления проблем с длиной строк: возьмите самые длинные строки английского интерфейса и искусственно удлините их на 40%. Это грубая симуляция того, как будут выглядеть немецкий, финский или польский перевод. Если вёрстка выдержала, хороший знак. Если нет, нашли проблему ещё до привлечения переводчика.

Локализация форматов данных

Это один из самых коварных классов багов: пользователь видит знакомый интерфейс, но неправильно трактует дату, сумму или десятичный разделитель. Или, что хуже, вводит данные в привычном для него формате, а система обрабатывает их по другому правилу.

Форматы дат

Один и тот же набор цифр означает разные даты в разных странах. 03/04/2026 это 3 апреля в России и большинстве Европы, но 4 марта в США. Для пользователя это не ошибка, а ожидаемое поведение. Для вашего продукта потенциально серьёзный баг в бронировании, планировании или платёжных документах.

Форматы дат, которые нужно проверить: MM/DD/YYYY (США), DD/MM/YYYY (Европа, Россия), YYYY/MM/DD (ISO, Япония, Китай). Не забудьте проверить отображение дня недели, месяца словом и сокращённых форматов.

Числа и разделители

Десятичный разделитель, точка или запятая, зависит от страны. В России и большинстве Европы это запятая: 1 234,56. В США и Великобритании точка: 1,234.56. Ситуацию усложняет то, что разделитель тысяч тоже различается: пробел, запятая или точка в зависимости от страны.

Обязательно тестируйте: ввод числа пользователем (какой разделитель принимает поле?), отображение числа системой (правильно ли форматируется для локали?), пограничные значения (что происходит с очень большими числами?).

Валюта

Позиция символа валюты различается: $100 vs 100 ₽ vs 100€. Количество знаков после запятой тоже: японская иена не имеет дробной части, большинство других валют два знака, некоторые криптовалюты восемь. Проверяйте отображение как на экране, так и в выгрузках и письмах.

Время

Формат 12/24 часа, отображение секунд, временные зоны и их аббревиатуры (MSK, EST, UTC+3), всё это требует проверки. Особенно внимательно тестируйте интерфейсы с планировщиками, расписаниями и дедлайнами: пользователь из другого часового пояса должен понимать, в котором часу по его времени произойдёт событие.

Типичный дорогой баг: форма принимает число в немецком формате (запятая как десятичный разделитель), а backend интерпретирует запятую как разделитель тысяч. Пользователь вводит 1.234,56, а в базу попадает 1234. В интерфейсе всё выглядит нормально до момента, пока пользователь не замечает расхождение в итогах.

Как готовить тестовые данные для локализации

Чтобы поймать реальные ошибки, нужны специально подготовленные наборы данных. Обычные «короткие и аккуратные» строки из тестовой среды мало что проверяют, они именно такими и задумывались, чтобы всё отображалось красиво.

Длинные строки

Имя пользователя из 60+ символов. Название товара на 100 символов. Адрес из пяти строк. Описание с множеством абзацев. Эти данные проверяют вёрстку там, где она привыкла к аккуратным значениям. Немецкие составные слова отличный источник: Kraftfahrzeughaftpflichtversicherung или Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz.

Специальные символы и диакритика

Умляуты (ä, ö, ü), акценты (é, à, ñ), буквы с диакритическими знаками из польского, чешского, венгерского. Эти символы часто ломают сортировку, поиск и URL. Проверяйте их не только в полях отображения, но и в URL, slug-ах, именах файлов.

Имена и адреса из разных стран

Японские имена, где фамилия идёт первой. Исландские имена без фамилии. Адреса из стран, где порядок строк принципиально отличается от привычного. Многосоставные фамилии с дефисом или пробелом. Отчества и суффиксы (Jr., III). Компания, которая планирует работать на нескольких рынках, должна проверить, что её форма адреса не сломается на нестандартном вводе.

Пустые состояния и граничные случаи

Пустой список с локализованным сообщением. Уведомление об ошибке при вводе некорректных данных. Строка с нулевым значением суммы. Дата в далёком прошлом или будущем. Эти случаи редко попадают в основной прогон, и именно поэтому в них часто живут непереведённые строки.

Хороший подход: создайте в тестовой среде специальных пользователей с именами и данными, которые типичны для каждого целевого рынка. Немецкий пользователь с немецким адресом и немецким форматом телефона даст совсем другую картину, чем «Test User» с нейтральными данными.

Что часто забывают протестировать

Основное тестирование сосредоточено на главных экранах и ключевых потоках. Именно поэтому следующие зоны регулярно выходят в релиз с багами.

Письма и шаблоны уведомлений

Транзакционные письма (подтверждение заказа, сброс пароля, приглашение в команду) часто живут в отдельной системе и попадают в отдельный локализационный пул. Шаблоны могут содержать жёстко зашитый текст, который не был вынесен в ресурсный файл. Проверяйте: язык письма соответствует языку интерфейса, переменные вставляются корректно (имя пользователя, сумма заказа, дата), форматирование дат и сумм соответствует локали получателя.

Push и SMS

Push-уведомления имеют ограничение по длине. Переведённый текст, который умещался в 80 символов английского, может занять 120 символов в немецком, и уведомление обрежется. SMS-шаблоны с кириллицей имеют другой лимит символов (70 вместо 160), что тоже влияет на длину сообщения.

PDF и печатные формы

Генерируемые документы, акты, счета, отчёты, требуют отдельного внимания. Шрифты, используемые в PDF, могут не поддерживать символы нужного языка. Переносы слов в PDF следуют другим правилам, чем в HTML. Даты и суммы должны форматироваться по правилам локали документа, а не локали интерфейса.

Поиск и автодополнение

Поиск по-русски должен находить «Москва», даже если в базе есть «москва» (регистр), «Москвa» (кириллическая «а» vs латинская), или «Moskva» (транслитерация). Автодополнение должно учитывать особенности языка: в немецком составные слова часто ищут по частям, в арабском важна нормализация диакритических знаков.

Сортировка и алфавитный порядок

Алфавитная сортировка зависит от локали. В шведском «Å» стоит после «Z», а не рядом с «A». В испанском «ñ» отдельная буква между «n» и «o». В немецком «ü» сортируется как «ue» в одних контекстах и как «u» в других. Если сортировка реализована простым ASCII-сравнением, она будет давать неожиданные результаты для нелатинских алфавитов.

Аналитика и трекинг событий

Если события в аналитической системе содержат локализованные значения (например, название категории товара на языке пользователя), это ломает сегментацию и отчёты. Одна и та же категория «Электроника» на трёх языках создаёт три разных значения в аналитике. Проверяйте, что трекинг использует инвариантные идентификаторы, а не локализованные строки.

Псевдолокализация: как найти баги до реального перевода

Один из самых полезных приёмов в локализационном тестировании псевдолокализация. Это искусственная замена строк на удлинённые, непривычные или специально изменённые варианты, которые не требуют настоящего перевода, но быстро показывают слабые места интерфейса.

Типичный подход к псевдолокализации: берём каждую строку и заменяем символы на похожие из других алфавитов или добавляем специальные маркеры. Например, «Save changes» превращается в «[Ŝàvé çhàñgés ...]», строка стала длиннее, содержит нестандартные символы и заключена в скобки, по которым легко найти непереведённые фрагменты.

Псевдолокализация не заменяет полноценную проверку на реальном языке, но позволяет найти половину инфраструктурных проблем ещё до того, как переводчики начали работу. Это существенно снижает стоимость исправлений: дешевле починить вёрстку до перевода, чем после.

Тестирование RTL-языков

Если продукт выходит на арабский, иврит, персидский или другие языки с написанием справа налево, объём работы по тестированию значительно возрастает. Команды часто недооценивают масштаб: думают, что RTL это просто direction: rtl в CSS. На практике ломается вся визуальная логика интерфейса.

Что меняется при RTL

• Направление всего layout: то, что было слева, теперь справа. Навигация, боковые панели, хлебные крошки, прогресс-бары, всё зеркалируется.

• Иконки с направлением: стрелки «назад» и «вперёд» должны быть зеркальными. Иконка «играть» (треугольник вправо) становится «играть влево», что выглядит странно. Нужно определить, какие иконки зеркалируются, а какие нет (например, иконка часов не зеркалируется, время идёт одинаково).

• Поля ввода: cursor и выравнивание текста в полях должны работать справа налево. Особенно важно для полей с числами, они обычно остаются LTR даже в RTL-интерфейсе.

• Смешанный контент: интерфейс на арабском, но число или дата слева направо. Правила смешанного направления (bidirectional text) сложны и часто реализованы неправильно.

Что особенно часто ломается при RTL

• анимации и переходы, которые предполагают движение «вперёд», вправо в LTR и влево в RTL;

• тултипы и выпадающие меню, которые открываются в «неправильную» сторону;

• таблицы, где первая колонка должна быть справа;

• формы с несколькими колонками;

• PDF-документы, их нужно генерировать отдельно с RTL-настройками.

Частая ошибка: команда считает, что поддержка RTL сводится к text-align: right. На практике проблема значительно глубже: перестраивается вся логика визуального направления, от расположения элементов на странице до поведения анимаций и жестов.

Как встроить локализацию в релизный процесс

Если локализацию проверяют только «в конце перед релизом», почти всегда становится поздно: времени мало, баги критичные, а исправлять их без регрессий уже трудно. Правильнее разложить проверку по этапам разработки.

Этап 1: До перевода, инфраструктурная готовность

Псевдолокализация и проверка готовности интерфейса к локализации. На этом этапе проверяется: вынесены ли все строки в ресурсные файлы, нет ли жёстко зашитого текста в коде, поддерживает ли вёрстка длинные строки, работает ли переключение языка на уровне приложения.

Этап 2: Во время перевода, контроль качества строк

Контроль терминологии (единый глоссарий для всего продукта), проверка длины строк на технические ограничения (максимальная длина для кнопок, уведомлений), контроль наличия контекста для переводчика (скриншоты, описание места использования строки). На этом этапе QA работает совместно с командой перевода.

Этап 3: Перед релизом, полная проверка

Прогон ключевых пользовательских сценариев на новом языке, проверка всех внешних каналов (письма, push, документы), тестирование редких состояний (ошибки, пустые состояния, граничные случаи), финальная проверка форматов данных.

Этап 4: После релиза, мониторинг

Мониторинг жалоб пользователей, связанных с локализацией. Отслеживание смешения языков в аналитических событиях. Проверка регрессий после обновлений, новые строки легко добавляются без перевода, если процесс не контролируется.

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

Часть проверок хорошо поддаётся автоматизации, это снижает нагрузку на ручное тестирование и позволяет встроить проверки в CI/CD.

Что автоматизируется хорошо

• Проверка полноты перевода: скрипт сравнивает ресурсные файлы разных языков и выявляет отсутствующие ключи. Это можно сделать в pipeline при каждом коммите.

• Псевдолокализация: автоматическая генерация псевдолокализованного варианта строк для интеграционных тестов.

• Визуальное регрессионное тестирование: скриншот-тесты, которые сравнивают отображение на разных языках и сигнализируют при изменениях вёрстки.

• Проверка форматов данных: юнит-тесты на правильность форматирования дат, чисел и валют для каждой поддерживаемой локали.

Что автоматизируется плохо

• Качество перевода и его контекстная корректность, это требует человеческой экспертизы и знания языка.

• Визуальные проблемы вёрстки, которые требуют оценки «выглядит ли это нормально», автоматика может зафиксировать изменение, но не оценить его значимость для пользователя.

• Культурная уместность контента, только носитель языка или культурный консультант может оценить, звучит ли перевод естественно и не несёт ли нежелательных коннотаций.

• Сценарии с нетипичными данными, автотесты работают с заготовленными датасетами, а реальные пользователи вводят то, что предсказать сложно.

Оптимальная стратегия для большинства команд автоматизировать проверку полноты перевода и форматов данных, а всё остальное закрывать ручным тестированием с правильными приоритетами.

Инструменты для локализационного тестирования

Хорошие инструменты не заменяют методологию, но существенно снижают трудозатраты на рутинные проверки.

Lokalise, Phrase, Crowdin платформы управления переводами с поддержкой контекста (скриншот места использования строки), отслеживанием прогресса и интеграцией с репозиторием. Автоматически выгружают новые строки на перевод и импортируют готовые.

i18n-ally плагин для VS Code, который подсвечивает жёстко зашитые строки прямо в коде. Помогает разработчикам не добавлять новые нелокализованные строки в процессе разработки.

Percy, Chromatic, Applitools инструменты визуального регрессионного тестирования. Делают скриншоты интерфейса и сравнивают с baseline. Полезны для отслеживания вёрсточных изменений при смене языка.

ICU, Intl API (JavaScript), gettext стандартные библиотеки интернационализации. Юнит-тесты на их основе автоматически проверяют корректность форматирования дат, чисел и валют для каждой поддерживаемой локали.

Специфика тестирования по языкам

Разные языки требуют разного фокуса. Универсального чеклиста недостаточно, нужно знать типичные проблемы каждого направления.

Немецкий и скандинавские языки. Главная проблема длина строк. Немецкие составные существительные могут быть очень длинными и не разрываются по пробелу. Умляуты (ä, ö, ü) и буква ß требуют проверки в сортировке и URL.

Романские языки (испанский, французский, португальский). Длиннее английского на 20-30%. Акцентированные символы, проверяйте кодировку и отображение. Испанский для Испании и для Латинской Америки отличаются, убедитесь, что выбрана правильная локаль.

Восточноевропейские языки (польский, чешский, венгерский). Богатая диакритика. Сортировка нетривиальна, в чешском «ch» считается отдельной буквой после «h». Падежи создают сложности в динамических строках с именами пользователей.

Азиатские языки (китайский, японский, корейский). Иероглифы компактнее латиницы по ширине, но выше по высоте. Нет пробелов между словами, переносы строк работают по другим правилам. Проверьте шрифты: не все поддерживают полный набор иероглифов.

Как QA-команде не утонуть в объёме проверок

Одна из самых частых проблем попытка проверить всё одинаково подробно. В результате команда либо выгорает, либо проверяет поверхностно и всё равно пропускает критичные зоны. Локализация требует приоритизации, а не тотального хаотичного обхода.

1. Сначала: главные пользовательские сценарии на новом языке. Если ломается логин, оплата или основной рабочий процесс, всё остальное неважно.

2. Потом: критичные форматы данных и внешние каналы. Письма, push, PDF, всё, что пользователь видит вне интерфейса.

3. Затем: редкие состояния, документы, поиск и сортировку.

4. В конце: косметические проблемы вёрстки и незначительные несоответствия.

Такой порядок значительно полезнее, чем бессистемный просмотр десятков экранов без понимания, где ошибка будет стоить дороже всего.

Полный чеклист локализационного тестирования

ИНТЕРФЕЙС
✓  Главные сценарии проходят на новом языке без ошибок
✓  Нет обрезанных строк на кнопках и в заголовках
✓  Вёрстка не разваливается при длинных переводах
✓  Нет смешения языков внутри одного потока/страницы
✓  Непереведённых строк нет даже в редких состояниях

ФОРМАТЫ ДАННЫХ
✓  Даты отображаются в формате локали (DD/MM или MM/DD)
✓  Числа форматируются с правильным разделителем
✓  Валюта показана с правильным символом и позицией
✓  Часовой формат (12/24) соответствует локали
✓  Форма принимает и корректно интерпретирует данные в локальном формате

ВНЕШНИЕ КАНАЛЫ
✓  Транзакционные письма приходят на языке пользователя
✓  Push-уведомления переведены и не обрезаются
✓  PDF и документы отображаются корректно (шрифты, переносы)
✓  SMS-уведомления учитывают ограничение символов для кириллицы

ПОИСК И ДАННЫЕ
✓  Поиск работает с учётом особенностей языка (регистр, диакритика)
✓  Сортировка использует правила текущей локали
✓  Аналитические события используют инвариантные идентификаторы

RTL (при необходимости)
✓  Layout зеркалируется корректно
✓  Иконки с направлением зеркальны там, где нужно
✓  Поля ввода работают справа налево
✓  Смешанный LTR/RTL контент отображается правильно

Частые вопросы о тестировании локализации

Нужно ли тестировать локализацию на каждой платформе отдельно?

Да, обязательно. Даже при одинаковых строках Android, iOS, web и email часто ведут себя по-разному из-за разных контейнеров, шрифтов и ограничений интерфейса. То, что выглядит хорошо на десктопе, может ломаться на мобильном. То, что нормально в браузере, может некорректно отрендериться в почтовом клиенте.

Достаточно ли вычитать перевод носителем языка?

Нет. Носитель поможет с качеством текста, но не поймает поломку вёрстки, неверную валюту, смешение языков в сценарии и ошибки на уровне форматирования данных. Нужна отдельная техническая проверка, именно то, о чём эта статья.

Нужно ли локализационное тестирование, если язык очень похож на текущий?

Да. Даже похожие языки (например, русский и украинский, испанский и португальский) ломают интерфейс через длину строк, склонения, правила множественного числа и локальные форматы данных. «Похожесть» языков не означает совместимость форматов дат, валют и порядка слов.

Что самое опасное в локализации?

Ошибки, которые не выглядят как баги. Пользователь видит привычный интерфейс и продолжает работать, но данные, деньги или ожидания уже интерпретируются неверно. Такие баги могут жить в системе месяцами, пока не накопится достаточно жалоб или не случится серьёзный инцидент.

Как оценить готовность продукта к локализации ещё до начала перевода?

Запустите псевдолокализацию и посмотрите на три вещи: сколько строк не изменилось (жёстко зашитый текст), насколько разваливается вёрстка при более длинных строках, и есть ли в коде явные предположения о языке (например, сортировка по ASCII или хардкодные форматы дат). Это даст быстрый срез инфраструктурной готовности и, как правило, список задач для разработки до начала переводческой работы.

Сколько времени обычно занимает нормальное тестирование локализации?

Зависит от сложности продукта и количества новых языков. Для первого языка на продукте, который не проектировался с учётом i18n, стоит закладывать не меньше двух-трёх недель полного цикла, включая инфраструктурную подготовку, псевдолокализацию и финальную проверку. Для последующих языков, если инфраструктура уже выстроена, значительно меньше. Попытка уложиться в «пару дней» почти всегда означает неполное покрытие и сюрпризы после релиза.

Итог

Тестирование локализации это не вычитка перевода и не проверка нескольких главных экранов. Это полноценная проверка продукта на устойчивость к другому языку, другим форматам данных и другому способу чтения интерфейса.

Хорошая стратегия не пытаться проверить всё сразу, а двигаться по приоритетам: сначала критичные сценарии, потом форматы данных и внешние каналы, потом редкие состояния. Псевдолокализация сокращает объём сюрпризов на поздних этапах. Встраивание проверок в релизный процесс убирает ситуацию «всё готово, кроме переводов, разберёмся потом».

Чем раньше в процессе разработки начинается работа над локализацией, тем дешевле каждый найденный баг. Исправить контейнер кнопки на этапе псевдолокализации стоит в десятки раз дешевле, чем переделывать вёрстку после того, как переводчики уже сдали работу и продукт уходит в релиз.

Главный вывод: если смотреть только на текст перевода, большая часть реальных проблем уйдёт в релиз незамеченной. Локализация тестируется как система, вёрстка, форматы, внешние каналы, поведение данных и архитектура интерфейса. Именно тогда пользователь на новом рынке получает настоящий продукт, а не его технический перевод.

А лучшие вакансии для тестировщиков (auto и manual) ищите на hirehi.ru