Привет, Хабр! Мы команда из отдела разработки ПО для банкоматов Т-Банка: Александр, Владислав, Иван и Денис.

Расскажем о необычном, но интересном опыте автоматизации и роботизации тестирования банкоматного ПО в Т-Банке, для которого мы использовали коллаборативного робота.

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

Поиск решения

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

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

Минусы промышленных роботов, которые нас оттолкнули:

1. Высокая стоимость. Закупка, установка и интеграция робота в существующие процессы требуют больших инвестиций.

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

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

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

5. Отсутствие масштабируемости. Нельзя быстро перенести робота от одного банкомата к другому.

Отдельные устройства-накладки: «тыкалка» тачскрина, «вставлятель» карт, «прикладыватель» карт, устройство внесения и изъятия купюр. 

Минусы, которые нас оттолкнули:

1. Нет единого решения и нет готового решения. Под каждый АТМ нужно делать что-то свое. У банкоматов разная компоновка устройств, расположение элементов, разные шаттеры и пинпады. Невозможно создать решение, подходящее для всех. А все готовые решения требовали доработок.

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

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

Аренда робота у компании. Могло бы сработать, но в краткосрочной истории, нам же нужен был робот на долгий срок.

Минусы, которые нас оттолкнули:

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

2. Нет готового решения и сценария. Основные готовые сценарии связаны только с индустрией развлечений: использование в шоу-программе, рисование портретов, бариста и тому подобное.

3. Долгий процесс интеграции, при которой нужно будет перевести робота с текущих процессов на процессы тестирования. А еще нужно адаптировать периферию: лотки, захваты, стилусы.

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

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

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

Проблемы пилотного запуска

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

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

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

На пилотных запусках выявился ряд проблем:

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

• Медленные тест-кейсы, так как стилусы для нажатия на пинпад и экран были разделены и стояли в отдельных стаканах.

• Захват купюр не подходил для некоторых типов АТМ из-за различного позиционирования шаттера.

• Робот ходил только по прописанным траекториям. Для некоторых сценариев он не мог сделать переход из одной позиции в другую из-за конструктивных особенностей и выдавал ошибку.

• Нужны лотки для купюр, чтобы они выравнивались под собственным весом, так как АТМ не всегда выдает пачку ровным прямоугольником.

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

Причины, по которым мы решили переходить с прямого взаимодействия с SDK на полноценный фреймворк для робототехники:

Отсутствие консистентности между прогонами. ПО контроллера манипулятора использует неизвестный способ расчета IK-позы и построения траектории к этой точке. SDK было способно найти только одно IK-решение для позы в декартовых координатах и строило траекторию напрямую к этой точке. В условиях сцены с множеством объектов такое поведение приводило к необходимости ручного подбора промежуточных точек для избежаний коллизий.

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

Проблемы с координатной системой. Так как манипулятор расположен на передвижном стенде, стоял вопрос «калибровки» системы координат относительно АТМ после подготовки стенда к работе.

Хоть SDK Jaka и поддерживает пользовательские фреймы, но не позволяет строить дерево фреймов, где позиция фрейма рассчитывается относительно позиции другого фрейма. Все фреймы в SDK привязаны к нулевой координате — основанию манипулятора. 

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

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

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

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

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

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

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

Переход с SDK на ROS2

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

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

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

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

Мы форкнули и переработали механизм обработки запросов на выполнение траекторий с учетом того, что адаптер использовал вызовы методов JAKA SDK. Для поддержки обработки ошибок внесли мелкие улучшения в виде опроса статуса получения joint’ов манипулятора в background-потоке.

Нужно было сделать URDF-описание гриппера для интеграции захвата. Оно включало mesh’ы, описание «суставов» (joints) и реализацию драйвера для коммуникации ROS2 с гриппером. Готового пакета ROS2 для нашего гриппера DH95 не было, но была open-source-реализация для AG135, на ее основе создали пакет для поддержки нашего гриппера.

Главной целью переезда было использование MoveIt2 в качестве системы для взаимодействия манипулятора со средой. Movelt2 — это открытая платформа для планирования движений в робототехнике, в основном используется с ROS2 (Robot Operating System 2). Она предоставляет инструменты для разработки сложных робототехнических приложений, включая планирование движений, кинематику, управление и восприятие.

С MoveIt появилась возможность расставить 3D-модели на сцене — Planning scene, которая представляет окружение вокруг манипулятора. С ее помощью можно учитывать 3D-модели для обработки коллизий, выбора необходимого планера для построения траекторий, интеграции с сенсорами и так далее.

Мы использовали MoveIt Task Constructor, чтобы построить максимально оптимальные траектории движения. Он позволяет дробить сложные сценарии на мелкие части и перепланировать на каждом шаге. Например: подъехать → захватить → переместить → отпустить. 

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

Планировщики в Movelt2 используют расчет n-количества IK-поз для каждой необходимой позы захвата, чтобы получить оптимальную траекторию. Потом рассчитывается траектория для перемещения из одной IK-позы в другую. После расчета всех возможных траекторий для всех возможных поз выбирается комбинация траекторий с минимальной стоимостью перемещения. Это можно представить как дерево, где листья — разные IK-позы для одной позиции в пространстве, а ветви — стоимость пути.

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

MTC позволяет удобно задавать разные планеры для расчета разных траекторий. Для траекторий с малым количеством возможных коллизий мы используем RRTConnect, а для движения в рамках стесненного пространства — BiTRRTk.

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

Преимущества Movelt2

Перед выбором MoveIt2 мы оценили другие фреймворки для робототехнического планирования: cuRobo и Drake, которые активно развиваются и предлагают продвинутые возможности.

Сейчас мы используем cuMotion (часть экосистемы NVIDIA), который частично пересекается с cuRobo по технологиям, но MoveIt2 остается верхним уровнем управления.

Несмотря на технологические преимущества cuRobo и Drake, MoveIt2 оказался наиболее сбалансированным решением:

• Готовые интеграции с ROS2 и манипуляторами.

• MoveIt Task Constructor незаменим для построения сложных сценариев.

• Большое комьюнити, множество гайдов, примеров и поддержка.

• Гибкость: можно подключать кастомные планировщики (включая GPU-ускоренные, как TrajOpt + cuMotion).

MoveIt2 стал фундаментом, на котором мы строим систему. А такие технологии, как cuMotion, — ускоряющими модулями поверх него, а не заменой.

Процесс автокалибровки

Прошлый процесс калибровки вызывал боль и страдания у участников. Нужно было вручную направлять манипулятор на калибровочные точки на АТМ — в режиме free-mode, когда можно задать позу манипулятору руками. Приходилось использовать дополнительную программу для расчета плоскости банкомата, после чего валидировать все движения манипулятора, так как при неточной калибровке манипулятор мог не до конца вставить карту в картридер или не нажать на кнопку пинпада. Если калибровка была недостаточно точной, процесс приходилось повторять.

Новый процесс калибровки требует минимума ручных действий, все происходит программно, с помощью 3D-камеры Intel RealSense D435, ArUco-маркеров и обработки ивентов тачскрина ATM.

После установки стенда перед АТМ и запуска процесса калибровки начинается поиск ArUco-маркера. Если камера не видит перед собой маркера, манипулятор поворачивает камеру в разные стороны, чтобы его найти. Когда маркер обнаружен, манипулятор пытается выставить frame камеры перпендикулярно маркеру для уменьшения оптического искажения из-за непрямого угла камеры. 

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

К сожалению, используемая нами 3D-камера по документации обладает 2% отклонением от реального расстояния, хотя на практике это значение доходило до 4%. Получалось до 4 мм отклонения при «сканировании» с минимального расстояния, при котором возможно получение данных о глубине в 20 см. 

Казалось бы, 4 мм — это мелочь, но с учетом длины хода клавиши пинпада в 5 мм или максимальной дальности возврата карты картридером это отклонение критично для нас. Поэтому вторым этапом калибровки стала калибровка через тачскрин. 

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

Полностью отказаться от конфигурационных файлов не получилось, но удалось переработать их: вместо траекторий движения до каждой точки интереса АТМ теперь хранится только дерево фреймов этих точек относительно модели АТМ. То есть для интеграции новой модели корпуса АТМ не требуется проводить ручную работу по поиску необходимых траекторий — только разметить точками 3D-модель АТМ. Для определения модели АТМ используется ID, зашитый из ArUco-маркера.

Итоговая инфраструктура робота

Итоговая инфраструктура относится к роботу, а не ко всему тестовому стенду. Взаимодействие с манипулятором для внешнего потребителя происходит в виде методов API. Каждый метод отвечает за определенное действие, которое нужно сделать с АТМ: вставить карту, внести деньги, забрать деньги, нажать на тачскрин или пинпад, запустить калибровку.

API хостится на системном блоке тестового АТМ и взаимодействует с ROS2 через WebSocket'ы. Также API реализует сервис коллбэков о событиях нажатия на тачскрин, которые передаются в ROS2 с помощью топиков.

Благодаря модульной структуре ROS2 получилось разбить систему на отдельные ноды. 

task_runner рассчитывает траектории через MTC, реализует Action Server для запуска сценариев взаимодействия с АТМ.

robot_calibration калибрует позиции АТМ относительно манипулятора, размещает модели АТМ-объектов стенда на планировочной сцене.

move_group/moveit — основная нода MoveIt2. Запускает RViz2 для просмотра сгенерированных траекторий и ручного управления манипулятором.

jaka_planner реализует action server для прямого управления сервоприводами манипулятора и для взаимодействия с гриппером.

Хотя переезд на ROS2 + MoveIt2 решил все наши проблемы, не обошлось без технических особенностей.

Мы заменили ПК для управления манипулятором. Изначальное решение не было требовательным к мощности ПК, никаких сложных расчетов и CV. С текущим решением пришлось использовать производительную платформу, чтобы уменьшить время первоначальных расчетов всех траекторий. А с учетом интеграции cuMotion пришлось добавить и дискретную видеокарту.

Расширили кодовую базу. Раньше весь код был написан на C#, на «родном» языке нашей команды, а теперь кодовая база состоит: 

• из C++ — взаимодействие с MoveIt2, драйвера для грипера, манипулятора; 

• Python — определение ArUco-маркера, launch-файлы ROS2;

• C# — верхнеуровневое API для взаимодействия с сервисами, action client'ами ROS2 через WebSocket bridge.

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

Мы реализовали расчет IK через cuRobo в виде плагина для kinematics_solver и синхронизацию прикрепленных объектов в MoveIt и cuMotion для верного расчета коллизий с учетом захваченной грипером карты или купюр.

Полная интеграция еще не готова из-за особенностей взаимодействия со стадией Connect в MTC между MoveIt и cuMotion: разные алгоритмы планирования для цели в виде декартовой позы и цели в виде углов суставов. В cuMotion и cuRobo для декартовых поз используется MoveGen.plan_(single/batch) и TrajOpt на всем этапе расчета траектории. 

А для MoveGen.plan_(single/batch)_js TrajOpt используется только для fine-tuning получившейся траектории, а начальная траектория строится через линейную интерполяцию. Все суставы совершают синхронное движение до заданного положения, и при обнаружении коллизии на траектории планирование провалится.

Для правильной работы этапа stages::Connect в MoveIt планировщик должен использовать планирование для позы в виде состояний суставов. Тогда в cuRobo нужно использовать plan_single_js, что накладывает описанные ограничения. Из-за этого приходится применять комбинированный подход между plan_single_js для области, где невозможна коллизия, и plan_single для областей с возможными коллизиями (вблизи АТМ, около контейнеров) в нашем форке для оптимального планирования траекторий.

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

Список планируемых улучшений:

• Добавить CV для определения начального состояния стенда: есть ли в стенде купюры и карты.

• Создать механизм для выдачи необходимого количества купюр. Сейчас поддерживаются только заготовленные пачки или полученные в рамках подготовки кейса купюры из АТМ.

• Настроить удаленное управление манипулятором для проведения операций с АТМ, не предусмотренных тест-кейсами.

Как мы интегрировали роборуку в процессы тестирования

Наш робот умеет:

• Брать карту из лотка.

• Вставлять карту в картридер и забирать ее оттуда. 

• Прикладывать карту к NFC. 

• Возвращать карту в лоток.

• Нажимать на экран. 

• Переходить между UI. 

• Вводить сумму выдачи или номер договора для зачисления.

• Вводить пинкод на пинпаде.

• Класть деньги из определенного лотка в шаттер банкомата. 

• Забирать деньги из шаттера и возвращать в лоток.

Этих действий достаточно, чтобы составить все необходимые тест-кейсы для регрессов разного рода.

На одном из этапов развития нашего продукта мы столкнулись с проблемой. Это случилось, когда появились новые версии UI, операционные системы Windows и Linux и различные версии управляющего ПО банкомата (Core). 

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

Тестраннер — это слой адаптации, написанный на JavaScript. А еще на JavaScript написан сам UI банкомата и внедренный в UI тестраннер как модуль с программным интерфейсом. Тестраннер понимает формат теста и «переводит» команды в вызовы в коде, что позволяет запускать одни и те же тесты в разных окружениях: как при взаимодействии с человеком, так и с участием роборуки. Тестраннер живет в отдельном репозитории и запускает UI банкомата, обеспечивая гибкость при смене окружений. 

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

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

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

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

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

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

Внедрение робота позволило повысить эффективность QA-процессов и высвободить ресурсы инженеров. Вот ключевые метрики и эффекты:

• Общее количество тест-кейсов для роборуки: 203 тест-кейса.

• Поддержка банкоматов: 5 моделей. 

• Переход на новую модель и калибровка менее чем за 5 минут.

Экономия времени QA на один регресс:

• Команда управляющего ПО до 15 ч/ч.

• Команда банкоматного UI до 18 ч/ч.

• Общая экономия ресурсов QA с учетом 3 регрессов в месяц и 5 моделей банкоматов: 110 ч/ч в месяц.

Позитивный эффект на процесс тестирования:

• Полная автоматизация рутинного тестирования.

• Снижение нагрузки на QA более чем на 100 ч/ч.

• Повышение регулярности и качества тестирования.

• Сокращение риска человеческой ошибки.

• Возможность перераспределения QA-ресурсов на более сложные и креативные задачи.

Планы

Мы хотим развивать робота с фокусом на автономность и интеграцию с системами банка:

• Компьютерное зрение — для автоматического определения наличия карт и купюр на стенде. Это позволит роботу самостоятельно оценивать результаты операций и принимать решения без участия человека.

• Интеграция контроллера моков в тест-раннер — на базе WireMock будет реализован встроенный контроль моков внешних систем. Это повысит стабильность тестов, снизит зависимость от реальных сервисов и упростит настройку сценариев с ошибками, таймаутами и другими состояниями.

• Автоматизация перемещения между банкоматами — робот сможет тестировать несколько устройств подряд без ручного переключения.

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

• Демосценарий — будет подготовлен отдельный наглядный сценарий для демонстрации возможностей робота. Это ответ на высокий интерес со стороны команд и руководства к процессу автоматизированного тестирования.

Наша цель — построить стабильную, автономную и масштабируемую систему, способную заменить ручные процессы и интегрироваться в цепочку процессов QA. Все это позволит перейти из RnD в полноценный продуктовый проект, который приносит пользу в тестировании 😈

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

20 октября на Heisenbug расскажем о нашем опыте с роборукой. А на стенде Т-Технологий можно будет вживую увидеть, как она работает.