Введите фразу для поиска нужной статьи:

Проблема облака SaaS

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

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

Важным здесь является то, что, как правило, такие пользовательские версии программного обеспечения, используемые разными арендаторами, все равно будут очень похожи. Иногда будет разница в паре таблиц базы данных или даже полей. Этот факт делает идею создания практически идентичных копий еще более иррациональной. Что, если бы мы могли просто хранить эти пользовательские требования для каждого арендатора и применять их при необходимости к основной базе данных для сеанса конкретного арендатора? Такой механизм привел бы к большой экономии. Итак, мы внедрили ее в 1С:Предприятие.

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

Вот как это работает в реальной жизни. В 1С:ERP около пятнадцати тысяч таблиц, которые обычно содержат пару десятков полей. Доступ к каталогу служб осуществляется несколькими клиентами (арендаторами). Их бизнес-процессы и даже отрасли могут различаться. Например, инструмент можно использовать для контроля складских запасов, обработки заказов поставщикам товаров и т.д.

В таком случае важно выделить информацию о возможных задержках доставки. Эти знания помогают контролировать запас и избегать ситуаций, когда бизнес либо имеет слишком значительное количество конкретного продукта, либо не может удовлетворить спрос. С помощью инструмента Extensions можно добавить новое поле “Normal shipping delay”, в котором можно зафиксировать допустимый период задержки.

При этом другие клиенты увидят начальный UX каталога и будут работать с ним как обычно: Если 1С: ERP поставляется в комплекте с веб-сайтом, который служит инструментом сбора лидов, собранные запросы могут быть загружены в базу данных в виде счетов-фактур. Такой клиент может захотеть использовать решение для доступа к ROI рекламной кампании. Для решения этой задачи необходимо знать, какой канал привлек лида, т.е. добавить соответствующее поле “Кампания” в каталог “Клиенты”.

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

КШаг № 1: Понимание ручных и автоматизированных тестов; лучшие варианты использования

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

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

Иногда существуют конфигурации программного обеспечения, которые не могут быть протестированы автоматически или используются и тестируются очень редко (т. е. Раз в квартал), поэтому нет необходимости тратить ресурсы на автоматизацию. Также может быть обратная ситуация, когда конфигурация используется и изменяется так часто, что невозможно постоянно обновлять тесты. В таких случаях гораздо проще и дешевле потратить некоторое время на ручное тестирование.

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

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

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

КШаг №2: определение инструментария тестирования пользовательского интерфейса

Чтобы успешно объединить ручное и автоматическое тестирование, вам нужно продумать свой инструментарий тестирования. Правило номер один здесь - попытаться сохранить его простым и экономически эффективным. Например, гораздо лучше, когда есть способ создавать ручные тесты без навыков программирования — это ускорит общий процесс, так как простые тесты могут быть созданы аналитиками программного обеспечения и младшими членами команды тестирования.

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

При разработке программного обеспечения на основе определенной платформы, такой как 1С: Предприятие, рекомендуется использовать встроенные функции тестирования. Это позволяет избежать траты ресурсов на интеграцию со сторонними приложениями для тестирования. Например, мы используем встроенные в платформу инструменты 1С:Vanessa Automation и 1С:Scenario testing tools.

Шаг №3: расчет ROI

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

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

Борьба с необходимостью ненужной работы

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

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

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

Важным улучшением, позволившим нам значительно снизить затраты на локализацию, стало изменение подхода к переводу контента для разных типов пользователей. В 1Ci мы работаем над 1С: корпоративной платформой, которую можно использовать для создания бизнес-приложений. В прошлом мы пытались локализовать контент как для конечных пользователей, так и для разработчиков приложений, включая такие разделы, как Справка и FAQ. Объем контента для перевода на несколько языков был огромен.

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

Экономьте на процессе найма по-умному

Еще одна вещь, которую мы смогли исправить, - это процесс найма. Когда у вас есть продукт для перевода на несколько языков, возникает проблема мошенничества с переводом. Скажем, если вам нужен польский перевод, но никто в вашей команде не говорит по-польски, какой-то злонамеренный переводчик может попытаться обмануть вас и отправить переведенный текст Google и получить за это деньги. Статистика показывает, что каждая шестая заявка на работу по переводу является мошеннической.

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

Например, он содержит названия наших продуктов, которые, если они написаны с ошибками, показывают отсутствие усилий, приложенных к выполнению задачи. Например, у наших наименований товаров есть определенный формат 1С: Наименование товара — без пробела. Программное обеспечение автоматического перевода также добавляет пробел после двоеточия. Кроме того, мы можем включить в тест неправильно написанные названия сторонних продуктов, таких как Gogle или CQL Server - если переводчик не сможет выявить такие ошибки, то весьма вероятно, что мы не сможем с ним работать.

Только если этот первоначальный тест будет пройден, мы покажем результат нашим носителям языка или партнерам в целевой стране, которые предоставят нам окончательную обратную связь. И, конечно же, мы внедрили автоматическую проверку того, был ли текст сгенерирован автоматически. В среднем мы получаем 70-80 заявок на каждое задание перевода — по 10 из них обычно копируются и вставляются в выходные данные Google Translate.

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