tgoop.com/QA_with_a_spoon/23
Last Update:
Тестирование переводов
Доклад про тестирование переводов, который я подготовила для QA Sisters Conf, доступен на youtube.
Почему только переводов, а не локализаций вообще? Потому что все остальное просто не влезло в установленные 20-30 минут. Когда-нибудь я сделаю доклад-продолжение (но это не точно).
Краткое содержание:
- С точки зрения функциональности важно помнить про определение дефолтного языка и про переключение языков
- Если есть интеграции - уделяем внимание контракту между ними
- Проверки строк текста и right-to-left интерфейса можно сделать с помощью неатомарных тестов на окна (или отдельные состояния конкретных окон)
- В целом все довольно нестрашно, джуны с небольшим опытом справляются. Особенно если на проекте нет неочевидных интеграций
У аудитории были вопросы про автоматизацию, про взаимодействие с программами автоматического перевода и про экономию денег на переводчиках.
Вопрос: пробовали ли автоматизировать?
Я сама не автоматизатор, так что лично не пробовала. Но мнение имею!
- выбор языка по умолчанию - да, имеет смысл автоматизировать. Это тот сценарий, который точно будет использоваться каждым пользователем, и он (почти) точно будет в смоук/санити проверках
- переключение языков - под большим вопросом. Пользователи переключают языки редко или вообще никогда
- переводы строк - нет, нет и еще раз нет. Это будут огромные затраты ради тестов, которые полностью прогоняются не так уж часто и могут устареть между прогонами
Вопрос: проверяли ли вы, как приложение работает с автоматическими переводчиками?
Нет, не проверяли.
Были ли баги?
Да, иногда были. Иногда даже функциональные (например, поле переставало обновляться).
Думаю, если возникает острое желание проверить взаимодействие приложения с автоматическим переводчиком, имеет смысл спросить - а мы это делаем чтобы что? Почему это важно?
С ненулевой вероятностью окажется, что бизнесу важны пользователи, говорящие на определенных языках, и что проще добавить дополнительный язык в приложение и проверить его как обычно, чем ввязываться в тестирование взаимодействия с тем же Google Translate.
Стоимость добавления нового языка (если только это не арабский + RTL с нуля) - максимально понятная трата, в отличие от проверки на совместимость с автоматическими переводчиками.
Вопрос: а что, если использовать неуникальные ключи и таким образом сэкономить на переводчиках (им же платят за количество слов)?
Получается, что тут выбор: экономия на переводах vs экономия времени разработки/тестирования.
Мне самой кажется более предпочтительным потратить дополнительную (понятную, заранее известную) сумму в самом начале применения переводов, чем иметь риск получить затраты неизвестного объема когда-нибудь потом.
Аргументировать метриками не могу:) Чтобы точно это знать, нужно одну и ту же фичу (или две очень похожих) обработать разными способами: для одной сделать максимально неуникальные ключи, для другой - уникальные. В процессе максимально точно затрекать время и потом сравнить затраты. Мы не пробовали так делать, если честно. Если вдруг кто-то пробовала/пробовал, делитесь опытом:)
#qasisconf
BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
Share with your friend now:
tgoop.com/QA_with_a_spoon/23