Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Доклад на hotcode.org о инструментах и методиках которые помогают нам повышать и следить за качеством PHP кода.
Среди затронутых тем:
- Стандарты в коде
- Средства для статического анализа кода.
- Git хуки
- Непрерывная интеграция
- IDE
- Code review
Докладчик:
Александр Сапронов
Описание:
Язык Python отлично подходит для прототипирования: простой синтаксис, множество батареек, много готовых решений. Это отлично для бизнеса и для разработчика.
Но давайте снимем розовые очки и озвучим негатив, который вас ждет, когда вы возьмете Python для проекта.
Видео:
https://www.youtube.com/watch?v=YE9Q78QlZiE
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Доклад на hotcode.org о инструментах и методиках которые помогают нам повышать и следить за качеством PHP кода.
Среди затронутых тем:
- Стандарты в коде
- Средства для статического анализа кода.
- Git хуки
- Непрерывная интеграция
- IDE
- Code review
Докладчик:
Александр Сапронов
Описание:
Язык Python отлично подходит для прототипирования: простой синтаксис, множество батареек, много готовых решений. Это отлично для бизнеса и для разработчика.
Но давайте снимем розовые очки и озвучим негатив, который вас ждет, когда вы возьмете Python для проекта.
Видео:
https://www.youtube.com/watch?v=YE9Q78QlZiE
Стремление каждого разработчика ПО — писать код. Всё, что от этого кода требуется — работать без ошибок и соответствовать задумке. Не секрет, что для более-менее сложного продукта требуется объединить несколько программистов в одну команду и заставить их работать вместе... И вот тут начинаются проблемы: каждый пишет по-своему и затрудняется понять код коллеги. Что в итоге? Падает эффективность, снижается качество продукта, увеличивается время вхождения для новых разработчиков.
Решить эти проблемы помогает контроль за стилем кода. В этом докладе я расскажу про то, какие практики вам могут пригодиться на выбранном пути и какие средства для этого есть в экосистеме Python.
Алексей Турчаников и Николай Сидоренко выступят с докладом об опыте внедрения автоматизированного тестирования через интерфейс (Web и десктоп) в их проекте: как проходили через целый лес организационных и технических "граблей" и в конце-концов добились своей цели.
В обзоре: SOAP UI, TestComplete, Ranorex, Cucumber, SpecFlow, Robot Framework + RIDE, Selenium WebDriver (Java & C#), White.А также: как не стоит нанимать тестировщиков-автоматизаторов, какой процент тестировщиков не начнет писать тесты, чем ценны тестировщицы-девушки.
SECON'2016. Бартунов Олег, Карьера в Open SourceSECON
Я расскажу про то, как устроен современный Open Source на примере проекта PostgreSQL и про те возможности, которые дает Open Source разработчику, в частности, в реализации себя как творческой личности и карьерного роста, а также достижения свободы и независимости. Open Source в условиях цифрового равенства позволяет разработчику жить и работать в привычных условиях без обязательного перемещения в неудобный для жизни мегаполис, и при этом быть членом большого международного сообщества, принимать участие в его жизни и влиять на развитие проекта.
Александр Сербул. Прикладное XP в «1С-Битрикс»: как развивать продукт более 1...ScrumTrek
В компании «1С-Битрикс более 10 лет успешно используется плеяда Agile методологий как для управления продуктом, так и для развития технологической платформы: от XP до Model Storming и Story Mappings, от глубокого проникновения всех «бойцов» общими командными целями и интенсивных визуальных коммуникаций без ТЗ, до выполнения топ-менеджерами компании интегрирующих ролей Scrum Master/ProductOwner, вплоть до парного программирования с генеральным директором. Самобытное и глубокое проникновение в культуру команды принципов Agile Manifesto, уважение клиента, возведенное в культ, с искренним желанием решить его технологические задачи, практическое стремление к техническому совершенству. Мы расскажем об этом, поделимся собственным опытом и инструментами, расскажем что работает лучше и когда, а что не взлетает ни при каких условиях. Особое внимание уделим особенностям применения Agile к задачам, требующим глубокого системного анализа и проектирования.
Евгений Джамалов. Agile в условиях мульти-вендорности и распределённых команд.ScrumTrek
Мы запустили 12 команд за 9 месяцев. У нас дружат 7 вендоров. Разрабатываем 4 больших продукта. Люди разбросаны по 7-ми локациям. В команде может быть до 4 представителей вендоров. Как минимум, по 1 человеку от другого вендора в команде. Сказка? Этот доклад о том, как мы их "дружили" и синхронизировали. Мой опыт и доклад интересны тем, что я столкнулся с проблемой, которой не было найдено никакого решения в свободном доступе. Мне хотелось бы в формате сказки, поделится с вами тем, как именно мы строили нашу работу и отношения для достижения результата, а так же рассказать, как и почему мы оказались в такой ситуации. К сожалению, много придётся оставить за кадром... так что - спрашивайте!
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Стремление каждого разработчика ПО — писать код. Всё, что от этого кода требуется — работать без ошибок и соответствовать задумке. Не секрет, что для более-менее сложного продукта требуется объединить несколько программистов в одну команду и заставить их работать вместе... И вот тут начинаются проблемы: каждый пишет по-своему и затрудняется понять код коллеги. Что в итоге? Падает эффективность, снижается качество продукта, увеличивается время вхождения для новых разработчиков.
Решить эти проблемы помогает контроль за стилем кода. В этом докладе я расскажу про то, какие практики вам могут пригодиться на выбранном пути и какие средства для этого есть в экосистеме Python.
Алексей Турчаников и Николай Сидоренко выступят с докладом об опыте внедрения автоматизированного тестирования через интерфейс (Web и десктоп) в их проекте: как проходили через целый лес организационных и технических "граблей" и в конце-концов добились своей цели.
В обзоре: SOAP UI, TestComplete, Ranorex, Cucumber, SpecFlow, Robot Framework + RIDE, Selenium WebDriver (Java & C#), White.А также: как не стоит нанимать тестировщиков-автоматизаторов, какой процент тестировщиков не начнет писать тесты, чем ценны тестировщицы-девушки.
SECON'2016. Бартунов Олег, Карьера в Open SourceSECON
Я расскажу про то, как устроен современный Open Source на примере проекта PostgreSQL и про те возможности, которые дает Open Source разработчику, в частности, в реализации себя как творческой личности и карьерного роста, а также достижения свободы и независимости. Open Source в условиях цифрового равенства позволяет разработчику жить и работать в привычных условиях без обязательного перемещения в неудобный для жизни мегаполис, и при этом быть членом большого международного сообщества, принимать участие в его жизни и влиять на развитие проекта.
Александр Сербул. Прикладное XP в «1С-Битрикс»: как развивать продукт более 1...ScrumTrek
В компании «1С-Битрикс более 10 лет успешно используется плеяда Agile методологий как для управления продуктом, так и для развития технологической платформы: от XP до Model Storming и Story Mappings, от глубокого проникновения всех «бойцов» общими командными целями и интенсивных визуальных коммуникаций без ТЗ, до выполнения топ-менеджерами компании интегрирующих ролей Scrum Master/ProductOwner, вплоть до парного программирования с генеральным директором. Самобытное и глубокое проникновение в культуру команды принципов Agile Manifesto, уважение клиента, возведенное в культ, с искренним желанием решить его технологические задачи, практическое стремление к техническому совершенству. Мы расскажем об этом, поделимся собственным опытом и инструментами, расскажем что работает лучше и когда, а что не взлетает ни при каких условиях. Особое внимание уделим особенностям применения Agile к задачам, требующим глубокого системного анализа и проектирования.
Евгений Джамалов. Agile в условиях мульти-вендорности и распределённых команд.ScrumTrek
Мы запустили 12 команд за 9 месяцев. У нас дружат 7 вендоров. Разрабатываем 4 больших продукта. Люди разбросаны по 7-ми локациям. В команде может быть до 4 представителей вендоров. Как минимум, по 1 человеку от другого вендора в команде. Сказка? Этот доклад о том, как мы их "дружили" и синхронизировали. Мой опыт и доклад интересны тем, что я столкнулся с проблемой, которой не было найдено никакого решения в свободном доступе. Мне хотелось бы в формате сказки, поделится с вами тем, как именно мы строили нашу работу и отношения для достижения результата, а так же рассказать, как и почему мы оказались в такой ситуации. К сожалению, много придётся оставить за кадром... так что - спрашивайте!
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Я убеждена в том, что грамотность и оформление текста в интерфейсе приложений напрямую влияют на качество приложений.
Поэтому на последней встрече QA Club Minsk затронула эту тему в 4 аспектах:
1. Соблюдение единого стиля оформления текста
2. Пунктуация в заголовках (названиях) и пояснительном тексте
3. Важность кавычек
4. И, безусловно, общая грамотность.
Забыла в презентации упомянуть, что чаще всего наш пользователь – это не технический специалист. Поэтому общаться с ним нужно простым человеческим языком. Наибольшая беда с этим обычно в настройках, сообщениях об ошибках или других уведомлениях.
Перепроверьте текст в своих интерфейсах. Понятен ли он простому человеку?
Построение систем автоматического протоколирования Си/Си++ кодаTatyanazaxarova
Иногда единственным методом отладки является использование протоколирования событий приложения. К недостаткам протоколирования (логирования) можно отнести большой объем кода, который приходится писать вручную для сохранения всей необходимой информации. В статье рассматривается методика, позволяющая построить систему автоматического протоколирования кода на языке Си/Си++.
Функции аналитика в Agile-команде, как его "встроить", нужен ли он, как быть с кросс-функциональностью. Презентация - см. http://www.slideshare.net/biBIGine/agile-sef09?type=presentation
19.06.19 - MAD SEO Conf v.2.0 by Govitall - SEO-адаптация продуктов для выход...Vladislav Morgun
19 Июня 2019 года выступил на мини конференции MAD SEO Conf v.2.0 by Govitall где рассказал о том как работать с другими языками, которых вы можете даже не знать.
Локализация - как делать глобальный проект?Alconost
Философия глобального проекта. Как делать так, чтобы перевод не тормозил релиз? Грамотное управление локализацией проекта. Лингвистическое тестирование. Кейсы и полезные советы по локализации проектов от профессионалов перевода Alconost Translations.
- Особенности разработки PhoneGap-приложения
- Сложности и подводные камни: к чему нужно быть готовым и что держать в голове
- Подготовка материала для разработчика ― style guide и шрифтовые иконки
User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
Рассмотрю с практической стороны создание своего предметно-ориентированного языка. Продемонстрирую почти готовое решение возникшей задачи и расскажу, в каких случаях может потребоваться внедрение DSL.
Докладчик: Михаил Воротынцев (AgoraDoxa)
Видео: https://www.youtube.com/watch?v=Qf0TjcBG1oI
Similar to Тестирование Локализации и Интернализации (20)
2. Когда продукт, который вы разрабатываете тестируете, выходит на мировой
рынок, рано или поздно встает вопрос о локализации. Тут начинается самое
интересное...
Для начала давайте определимся с терминами Глобализация, Интернализация
и Локализация.
Глобализация, в большей степени, отражает стратегию бизнеса в целом,
нацеленность на мировой рынок сбыта. Интернализация – это подход к
разработке, при котором создана база для последующей адаптации работы
приложения на различных языках (разделение кода и локально-зависимых
составляющих). Локализация – это и есть сам процесс перевода и
тестирования адаптации приложения на различные языки.
Я намеренно разделила понятия Интернализация и Локализация. Конечно,
при правильной разработке, интернализация включает в себя локализацию.
Но бывают иные случаи – приложение растет, развивается постепенно,
претерпевает изменения и в какой-то момент становится ясно – надо
локализовать продукт, хотя изначально об этом никто и не помышлял. В этом
случае происходит именно локализация, а интернализация – это изначально
известное стратегическое будущее проекта.
Если решение воплотить локализацию пришло «внезапно», то это несет в
себе дополнительные риски, и на тестирование такой локализации
необходимо выделить больше времени, т.к. в процессе обычно выявляется
незрелость продукта к таким изменениям, требуется доработка –
соответственно, дополнительное время. Так же не сразу выявляются
ненужные зависимости ресурсов, что приводит к дополнительному раунду
фиксов. Вывод: если локализация нагрянула неожиданно – накиньте
процентов 30% в план – пригодится.
В связи с открывшейся перспективой «говорить» приложению на нескольких
языках, появляется множество задач и вопросов:
• делать локализацию собственными силами или привлекать аутсорсинг
или комбинировать собственные силы с аутсорсингом.
2
3. • определить список поддерживаемых языков (очень важно, будет ли
среди поддерживаемых языков китайский, корейский, японский,
арабский).
• использовать или нет псевдолокализацию как предварительный шаг
локализации.
• осуществить перевод пользовательского интерфейса.
• адаптация к различным форматам данных.
• осуществить перевод системных сообщений и ошибок.
• осуществить адаптацию графики, звуков, анимации.
• осуществить перевод help и сопутствующей документации.
• проверка правильности перевода в контексте данного приложения.
• проверка локализованных приложений на разных языковых
платформах.
Псевдолокализация
Решение о принятии этапа псевдолокализации может быть связано с
желанием стабилизировать теоретическую локализацию, если достаточно
много языков локализации.
Что же такое псевдолокализация?
Путем хитрых научных исследований выяснилось, что при локализации
длина строки увеличивается в среднем на 30%. Именно этот показатель
используется для псевдолокализации.
Утверждается спец символы начала и конца строки, например *** как начало
строки и +++ как конец строки. Таким образом, псевдолокализованная строка
может выглядеть так:
***Тестовая строка+++
Что это дает? Можно тестировать читабельность и проверять вся ли строка
(сообщение) будет помещаться и отображаться на контроле и будет ли
псевдолокализироваться в принципе, будет ли правильно масштабироваться
интерфейс при изменении размера шрифта, например.
Подобным образом может осуществляться псевдолокализация графики,
аудио, анимации. На первый взгляд забавно звучит: псевдолокализация
графики, аудио, анимации. Не так уж странно, если задуматься над этим
вопросом. Зачастую в качестве графики может использоваться картинки,
которые в большей степени понятны, очевидны именно для жителей
определенной страны. Например, герой из мультика «Ну, погоди!» известен
каждому в нашей стране, мы все помним эти замечательные серии. Если в
приложении будет иллюстрация из этого мультика, мы сразу поймем
контекст данного изображения. Но, если показать это же изображение,
например, американцу, не стоит ждать, что он проникнется нежными
3
4. воспоминаниями о детстве. Для него это будет просто забавная картинка. Как
же будет выглядеть локализация такой графики?
Тоже касается аудио и других медиафайлов. Т.к. локализация – это адаптация
для жителей других стран носителей других культур, то следует обратить
пристальное внимание на то, действительно ли графическое медийное
сопровождение усиливает понимание продукта, а не вводит в заблуждение
пользователей.
Но на этапе псевдолокализации картинка может меняться так:
Обозначение Ru-ru на картинке указывает на то, что впоследствии картинка
изменится на русскую версию.
После завершения этого подготовительного этапа начинается, что
называется, проверка в полевых условиях. Время приступать к настоящему
сражению за локализацию или против локализации - это как пойдет.
Какие важные моменты стоит здесь учесть?
Системные настройки, которые являются маркерными при выборе
языка вашего приложения.
Работая с разными проектами, могу сказать, что спектр велик. Приступая к
работе с проектом, не лишним будет интерес: Почему именно так работает
локализация? Итак, список в студию:
1. Browser (в случае вэб-приложения) Tools → Language preference.
Выбранный в этой настройке язык и будет определять язык UI. Но
коварство этих настроек проявляется тогда, когда в списке языков
4
5. первым значится неподдерживаемый язык. Как корректно
обрабатывать такой случай? Возможно, искать в списке первый
поддерживаемый язык, а если такового нет, то считать выбранным
языком базовый (в общем случае, английский).
2. System locale, user's locale (Control Panel → Region and Language). Здесь
возможны вариации. Настройки System locale, user's locale могут
трактоваться приложением как независимые настройки, а может
использоваться "жесткая сцепка".
2.1. User's locale (Control Panel → Format tab → Region and Language).
Важным поинтом является то, что после выбора страны становится
доступной опция расширенного форматирования таких параметров как
числа, валюта, дата, время. Неспособность корректно обработать такие
настройки часто губит приложение. Так же нужно помнить о том, что
данная настройка может быть выставлена для каждого пользователя.
Исходя из этого, не вредно проверить работу системы под разными
пользователями разными user's locale.
2.2. System locale (Administrative tab → Change system locale.) Эта
настройка для всей системы в целом, т.е. в отличие от user's locale, она
будет едина для всех пользователей.
2.3. Жесткая сцепка User's locale & System locale. "Так не бывает! Это
неправильно!" - скажите вы. "Бывает и так", - отвечу я со слезами на
глазах.
Так же отдельным пунктом стоит рассмотреть клиент-серверные приложения
и требования к настройкам локали сервера и клиента. Возможные варианты
ограничиваются фантазией архитектора разработчика.
Оставляя локали (locales) позади, переходим к следующему этапу.
На что обратить внимание при тестировании локализации и интернализации
UI & functional?
• Текст должен отображаться полностью. Строка (предложение) не
должна быть составной, т.к. использование составных строк
приспособлено к определенному языку и не может гарантировать
корректность при переводе.
5
6. • Списки и меню – если размер списка или меню жестко прописан и не
появляется скролбара, например, некоторые пункты списка или меню
могут просто безмолвно изчезнуть.
• Если в локализации присутствует Китайский язык, важно помнить, что
направление текста может быть как слева направо, так и сверху вниз.
При написании текста сверху вниз неприменимы правила переноса,
привычные при письме слева-направо. (Это просто перелом мозга)
• Сортировка. Сложно, не владея, к примеру, Китайским языком,
оценить правильность сортировки. Предлагаю применить хитрость,
иначе говоря – костыль. Для сортировки, если это возможно, задать 3
значения. Таким образом, при сортировке (ascending, descending) 1
значение должно все время вторым в списке, а первое и третье
значение должны меняться местами. Такой метод позволит выявить
мертвую сортировку.
• Печать. Печать на листах разных форматов, с разными единицами
измерения листа.
• Форматы и данные.
o Дата
o Время
o Валюта
o Числа (разделение целойдробной части, разделитель тысяч)
Какие возможны варианты настройки и тестирования?
Самое простое – когда эти форматы настраиваются внутри приложения
и не требуют взаимодействия с операционной системой.
Второй вариант, когда настройки берутся из Control Panel → Format tab
→ Region and Language как упоминалось выше, но при этом не
допускается расширенная настройка.
6
7. И последний, самый мучительный вариант, когда настройки берутся из
Control Panel → Format tab → Region and Language и при этом
разрешается расширенная настройка этих параметров.
Здесь самые коварные баги могут крыться в динамическом изменении
этих настроек. Приложение должно определять, можно ли динамически
во время работы тестируемого приложения менять эти настройки или
необходимо переоткрыть ПО после этого. Возможно, придется даже
перезапустить сервисы. Важно, чтобы эта информация не затерялась и
нашла отражение в Help или другом документе.
Очень важный момент в локализации при работе с финансовым ПО.
Некоторые данные – такие как валюта, в финансовой проводке, должны
быть сохранены как есть. Очень нехорошо получится, если на счет
поступят 10 000 рублей вместо 10 000€.
С другой стороны, возможно, при распределенной структуре обработка
временных данных производится путем перерасчета в GMT время и
перевод в формат 24H. На это тоже стоит обратить внимание и
перепроверить преобразование текущего времени приложения в GMT и
обратно – результаты операции со временем должны корректно
преобразовываться во время приложения.
Это, конечно же, не полный список тех тонкостей, которые могут
встретиться на Вашем пути. В заключении хотелось бы напомнить, что
при распределении ответственности, при наличии возможности, стоит
заложить основу для взаимодействия с командами тех. писателей,
локализаторов и время на это взаимодействие. Ведь в конечном итоге,
именно отдел тестирования отвечает за качество продукта.
7
8. Спасибо за внимание!
Если у Вас возникли вопросы
или Вы хотели бы со мной
связаться:
http://lilia-gorbachik.com
info@lilia-gorbachik.com
8