Что за программа робот

Чат-боты — один из самых востребованных и перспективных сегментов рынка ИТ-технологий за последние несколько лет, в некоторых сферах их уже используют больше 70% компаний. Глава пресс-службы платформы todoo.ru Сима Мусатова разбирается, чем полезны боты, как их использовать и смогут ли роботы в итоге заменить человека.

Читайте «Хайтек» в

Что такое чат-боты и зачем они нужны

• Сокращают расходы на отдел продаж до 50%.

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

• Позволяют 24/7 быть на связи с аудиторией. Они выполняют операции быстро и могут обработать тысячи клиентов.

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

Как показывают исследования, сегодня происходит настоящий бум чат-ботов — программы для общения с клиентами стали одним из важнейших инструментов продвижения бизнеса. Как отмечает издание CNBC, уже в этом году 80% запросов от пользователей будут обрабатываться без участия человека.

1 урок. КуМир. Первая программа для исполнителя Робот

Кто такой менеджер чат-ботов

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

В его функционал входит:

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

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

• Оценка эффективности бота. Проработка багов и устранение неполадок, повторный запуск и тестирование.

• Масштабирование положительного результата.

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

Чего ждать в будущем

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

Читать далее:

Источник: hightech.fm

Robot Framework для автоматизации тестирования: ограничения и плюшки

В автоматизации тестирования я уже более 11 лет. Скажу сразу, что являюсь поклонником старомодного тестирования на Java и очень настороженно отношусь к различным готовым фреймворкам. Если вы придерживаетесь такого же мнения или только задумываетесь об использовании Robot Framework, в этой статье я постараюсь рассказать вам о его ограничениях и, конечно же, опишу все его достоинства.

Работа в КуМир с использованием робота

Я столкнулся с Robot Framework около года назад. Перед нами стояла задача силами двух инженеров автоматизировать довольно большой объем тестов в сжатые сроки, т.к. ручная регрессия перестала влезать в разумные рамки. Сам проект связан с пожарной безопасностью. Тестировать предстояло Web-часть в трех браузерах и Mobile-часть на множестве iOS и Android телефонов и планшетов.

Помимо этого, в наличии были тесты, которые взаимодействовали и с Web, и с Mobile. Конечно, это не ракету построить, но и не совсем тривиально. Честно скажу, я сопротивлялся, мы долго думали и в итоге, по совокупности внутренних и внешних факторов, выбрали Robot Framework.

Пара слов и картиночек для знакомства с Robot Framework

Прежде чем разбирать плюсы и минусы, давайте очень коротко поговорим о том, что же такое Robot Framework. Возможно, кто-то впервые видит это название.

Robot Framework – это keyword-driven фреймворк, разработанный специально для автоматизации тестирования. Он написан на Python, но для написания тестов обычно достаточно использовать готовые ключевые слова (кейворды), заложенные в этом фреймворке, не прибегая к программированию на Python. Нужно лишь загрузить необходимые библиотеки, например, SeleniumLibrary, и можно писать тест. В этой статье я дам общее представление о Robot Framework, но если после прочтения вы захотите углубиться в тему, то советую обратиться к официальной документации. В конце статьи также приведены ссылки на популярные библиотеки.

Что ж, перейдем к «картиночкам». Вот так может выглядеть простой проект в IDE (на примере всеми любимой Википедии):

• Синий и зеленый – папки с файлами для описания страниц и тестов соответственно. Так можно реализовать page object паттерн.
• Коричневый – драйвера для различных браузеров.
• Красный – тело теста.
• Желтый – консоль, из которой можно запускать тесты и видеть консольные сообщения (полноценные логи не тут, но об этом позже).

Как видно, в тесте сплошные «обертки» в стиле BDD (можно не применять такой синтаксис, но лично мне он тут кажется удобным). Имплементация находится в объектах страниц, например:

В стандартной секции Settings мы видим подгрузку библиотеки для работы с Selenium, а в другой стандартной секции Keywords находятся имплементации наших самописных ключевых слов.

Думаю, для получения общего представления этого достаточно. Детальное описание работы с Robot Framework лежит за рамками моего поста

Плюсы и минусы

В этой части я расскажу о плюсах и минусах Robot Framework, с которыми столкнулась наша команда. Учитывая специфику задач на проекте, наверняка у вас будут и свои «подводные камни». Я буду перечислять, двигаясь, на мой взгляд, от более значимого достоинства/недостатка к менее значимому.

Плюшки

Низкий порог входа

Как я уже писал выше, Robot Framework является keyword-driven фреймворком, а не языком программирования. Хоть синтаксис и схож с Python, знаний программирования требуется несколько меньше или, скажем так, их применение не обязательно там, где это позволяет сложность самой задачи. Однако, при необходимости можно пользоваться переменными, циклами, функциями, возвращающими значения, и т.п. Ближайшими альтернативами могут показаться Pytest и Selenide, но они требуют большей подготовки пользователя, нежели Robot Framework. Например, одной из встроенных стандартных библиотек является BuiltIn. Там вы можете найти такие кейворды как Sleep, Log, Run Keyword If, Should Be Equal As Strings и т.п. и написать что-то вроде:

Run Keyword If ‘$’ == ‘PASS’ SomeAction

Поддержка Web и Mobile

Robot Framework неплохо работает в связке Mobile+Web (как end-to-end, так и атомарные тесты).

Наши Web тесты работают с Chrome, FF и IE. Мобильная часть работает как с локальными реальными устройствами на Android и iOS, так и с устройствами с фермы SauceLabs. Ограничение – реальное локальное iOS-устройство можно тестировать только с Mac. И вообще iOS требует гораздо больше внимания, ведь тот же веб-драйвер для него надо пересобирать самостоятельно. (Тестирование iOS – это отдельная большая тема, и если интересно, дайте знать в комментариях, мне есть о чем рассказать)

Тэги

Есть возможность задавать тестам тэги. Тэгами может быть любая информация, которая пригодится нам для идентификации теста: ID теста, список компонент, к которым относится тест, и т.п. Этим мы обеспечиваем связь тестов с тестами или требованиями (traceability) и задаем необходимую информацию для конфигурирования запуска тестов. Указав в запускалке один тэг, мы можем запустить все тесты, которые относятся к определенному компоненту, или же можем при запуске явным образом перечислить тест-кейсы, которые надо запустить (удобно при регрессионном тестировании). Подробнее про тэги по ссылке.

Хорошие отчеты из «коробки»

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

• Output.xml – результаты тестов в формате XML. Пригодятся для мерджа результатов командой rebot. Пример:

• Log.html – подробные результаты в HTML-формате. Полезны больше для разработчиков тестов. Пример:

• Report.html – высокоуровневые результаты без подробной детализации. Полезны для демонстрации людям «со стороны» и менеджменту. Пример:

BDD из «коробки»

Синтаксис Gherkin языка с его нотациями Given, When, Then и And включен по умолчанию, и любой шаг может быть записан как в этой нотации, так и без нее. Можно использовать нотации или нет – тесты просто игнорируют их. К примеру, эти два кейворда с точки зрения фреймворка идентичны:

Welcome page should be open

And welcome page should be open

Page Object паттерн

Robot Framework позволяет реализовать Page Object паттерн не при помощи ООП, а при помощи синтаксиса ключевых слов. Смысл в том, чтобы последовательно в кейворде указывать, с какой страницей мы работаем -> с какой областью внутри нее мы работаем -> с каким контролом работаем и что мы с ним делаем. Пример:

On Main page on Users tab I click Create user icon

где кейворд “On Main page on Users tab I click Create user icon” хранится в отдельном робот файлике, скажем, с названием mainPage.robot. Этот файлик мы подгружаем в наш файл с тестами по необходимости.

См. также пример из секции «Пара слов и картиночек для знакомства с Robot Framework».

Параллельный запуск

Параллельный запуск становится возможным благодаря альтернативной запускалке тестов под названием Pabot. Стандартным предустановленным способом является команда robot. Естественно, тесты должны быть на это рассчитаны и не должны влиять друг на друга

Грабли

Отсутствует возможность отладки встроенными средствами

Имеется ввиду классическая расстановка брейкпоинтов. Приходится либо выводить что-то дополнительное в лог, либо ставить временные слипы и так обходить эту проблему. В сети описаны некоторые способы прикрутить дебаг, но для уровня целевой аудитории Robot Framework это сложновато.

Не поддерживается AWS

AWS (Amazon Web Services – коммерческое публичное облако, ферма мобильных устройств) не поддерживает тесты на Robot Framework. AWS работает таким образом, что код исполняется на стороне Amazon, и тесты в формате Robot Framework не допустимы. Зато другая ферма, SauceLabs, устроена по другому принципу и прекрасно работает с Robot Framework (есть проблемы с администрированием их сервиса из России, но они решаются общением со службой поддержки или работой под VPN).

IDE сложности

RIDE (Robot IDE), специальная IDE для Robot Framework, мягко говоря, сырая. Режим работы в табличном виде (как раз для воплощения идеи keyword-driven фреймворка) выглядит так:

Режим работы в редакторе текста:

Ни в одном из двух предлагаемых режимов работать невозможно. Приложение периодически «падает» (хотя на других проектах такого нет). В режиме текста нет элементарного Go to Definition. В режиме таблиц Go to Definition есть, но сам этот режим крайне неудобен для средних и больших проектов.

PyCharm работает лучше, но, к сожалению, существующие плагины не справляются с автокомплитом некоторых библиотек (например, SeleniumLibrary)

Плохая поддержка сторонних библиотек

Готовые, уже существующие в сети библиотеки зачастую не поддерживаются. Пользователей мало, и они переходят в разряд зомби. Например, работа с почтой, сравнение скриншотов и т.п. Можно, конечно, написать свои библиотеки на чистом Python (и Robot Framework это позволяет), но смысла в такой схеме остается мало.

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

Выводы

Выбор инструмента Robot Framework для нашего проекта был абсолютно верным и позволил выполнить наши обязательства в срок и с надлежащим качеством. Однако, надо понимать, что это, конечно же, не «серебряная пуля», есть много «но», которые надо иметь в виду.

Инструмент – это всего лишь средство для достижения поставленной цели, и не всегда надо микроскопом забивать гвозди, даже если это выглядит эффектно. Ругать или нахваливать Robot Framework я не берусь. Скажу лишь, что это хороший инструмент для своих целей

• Robot Framework User Guide
• SeleniumLibrary
• BuiltIn
• AppiumLibrary
• Collections

Источник: habr.com

Что за программа робот

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

Комплексно оцените целесообразность внедрения. Оценка должна включать четыре параметра:

• FTE – число задействованных в процессе сотрудников (full time employee)
• ST – число сотрудников, поддерживающих RPA-процесс (support team)
• CF – фактор сложности процесса (complexity factor)
• VF – фактор волатильности (изменчивости) процесса (volatility factor)

Измерив каждый показатель, можно разместить любой процесс на системе координат, где по оси ординат будет сложность и волатильность, а по оси абсцисс – число персонала (FTE). Систему координат с проставленными на ней процессами можно разделить на четыре квадранта критериев-рейтингов:

• Р1 – безусловно целесообразно
• Р2 – скорее целесообразно
• Р3 – скорее нецелесообразно
• Р4 – нецелесообразно

RB рекомендует лучших поставщиков цифровых решений для вашего бизнеса — по ссылке

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

• Финансовый сектор и банки
• Фармацевтика
• Складское хозяйство
• Ритейл
• Страхование
• Металлургия
• E-commerce

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

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

Как рассчитать затраты по внедрению

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

Для более точных расчетов следует отбирать процессы с минимальной волатильностью. В противном случае процесс поддержки по стоимости может превысить трудозатраты по разработке.

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

Это обходится организации в 7 648 000 рублей в год (зарплата, рабочие места и прочее). Так называемая рабочая группа людей в течение года с учетом праздников и отпусков отводит приблизительно 5 448 полезных человеко-часов.

Перейдем к расчетам по RPA. Траты на робота делятся на лицензии в год, разработку и поддержку. Под эту задачу нужно приобрести пакет лицензий UiPath стоимостью примерно 280 000 рублей в год. Оценка трудозатрат: 950 000 рублей и четыре месяца по срокам.

В итоге срок окупаемости за первый год составит 7 месяцев. Следует учесть, что в первые месяцы рабочая группа все так же будет сопровождать процесс вручную пока разрабатывается алгоритм для робота. Поддержка может быть оказана как внутренним центром компетенции, так и внешним по контракту. На этот процесс закладывается 450 000 рублей в год.

Итого за первый год экономия составляет 39,1% (2 993 334 рубля), а за второй, где уже тратиться нужно лишь на лицензии и поддержку , – 90,9% (6 955 000 рублей).

Как внедрить робота

Подход к внедрению стоит делить на 3 главных этапа:

Первый этап – детализация и пилот. В этом процессе главное – правильно определить «подопечного», ведь от успешности внедрения RPA на нем зависит многое. На первом этапе происходит классический ряд действий:

• Анализ процесса «как есть» и «как будет»
• Определение целевой архитектуры
• Концептуальное проектирование, тестирование «хваткости робота»
• Разработка, тестирование и отладка
• Демонстрация

После реализации пилота RPA лидер (он же, вероятно, спонсор) принимает решение о масштабируемости, и команда RPA переходит на следующий этап.

Второй этап – оценка влияния на операционную модель:

• Описание процесса «как есть» и «как будет»
• Расчет экономического эффекта
• Анализ текущих и целевых показателей
• Приобретение ПО
• Подготовка к тестовой/промышленной эксплуатации

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

Третий этап – внедрение и/или масштабирование:

• Разработка алгоритма по методу гибких методик
• Настройка робота
• Его интеграция в систему управления
• Внедрение и промышленная эксплуатация
• Донастройка робота по результатам тестирования
• Оценка эффективности его работы

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

Тестируем робота на «хваткость»

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

Например, чтобы кликнуть на элемент на сайте мы можем попробовать следующие способы:

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

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

Такой подготовительный анализ «хваткости» робота позволяет спрогнозировать реальные трудозатраты, увидеть «подводные камни» и в конце концов принять решение о старте проекта RPA. В самом пессимистичном варианте – изменить бизнес-процесс или отказаться от его роботизации в целом. Порой такие «трудности автоматизации» подталкивают на улучшение организационной структуры процесса, что впоследствии может дать большую выгоду, чем просто роботизация.

Разработка MVP робота: почему заказчику важно участвовать

Аббревиатуру MVP ввел Фрэнк Робинсон еще в 2001 году, но популярность она получила благодаря гибким методологиям, где продукт разрабатывается инкрементально и итеративно. MVP – это минимально жизнеспособный продукт, он же – прототип RPA. Прототип содержит в себе самые основные функции, которые мог бы выполнять робот, для того, чтобы выполнить задачу по заданному процессу. Он характеризуется:

• Заранее известными входными данными
• Отсутствием ошибок (прототип не подразумевает реагирование на исключения)
• Самым коротким исходом
• Отсутствием цикличности или работы с массивами/списками (опционально)

Почему так? Реализация прототипа показывает две вещи:

• Робот успешно прошел испытание «хваткости», и он способен работать со всеми элементами по своим задачам
• Команда разработки RPA правильно поняла поставленную задачу

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

Выбираем стратегию внедрения робота

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

На помощь приходит методология Scrum, которая гласит, что разработка должна идти при полном участии заказчика и небольшими спринтами. Их завершение шаг за шагом демонстрирует увеличение функциональности RPA-процесса. Плюсом будет снижение рисков по неудовлетворительному завершению проекта в целом.

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

Остановиться на одном процессе или роботизировать бизнес дальше?

Увидев прирост по бюджету и скорости, компании редко останавливаются на роботизации одного процесса. Также приняв тот факт, что в основном пилоты загружают робота не более чем на 25%, можно спокойно «вешать» на того же виртуального работника другие процессы, которые он будет выполнять. Следовательно, под них не нужно будет закупать лицензии.

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

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

Материалы по теме:

Источник: rb.ru